Журнал LinuxFormat - перейти на главную

LXF158:Руб­ри­ка си­сад­ми­на: Знать свои сла­бо­сти

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Не­во­об­ра­зи­мая слож­ность)
(Бур­ный ин­ци­дент)
 
(не показаны 20 промежуточных версий 1 участника)
Строка 8: Строка 8:
 
==Эзо­те­ри­че­ское сис­тем­ное ад­ми­ни­ст­ри­ро­ва­ние из при­чуд­ли­вых за­во­ро­тов ки­шок сер­вер­ной==
 
==Эзо­те­ри­че­ское сис­тем­ное ад­ми­ни­ст­ри­ро­ва­ние из при­чуд­ли­вых за­во­ро­тов ки­шок сер­вер­ной==
  
{{Врезка|left|Заголовок=На­звал­ся груз­дем |Ширина=10%|Содержание=  
+
{{Врезка|left|Заголовок=На­звал­ся груз­дем |Ширина=30%|Содержание=  
  
 
Моя же­на ­ве­дет кружок по по­ши­ву лоскут­ных по­кры­вал. По­отирав­шись око­ло их сбо­рищ, я на­у­чил­ся от­ли­чать узор «пле­тен­ка» от узо­ра «ле­стнич­ка», у­знал, что де­ше­вый ва­тин мох­рит­ся, и понял, как вы­ре­зать фес­то­ны для «ши­ро­ких квад­ра­тов». Нет, я не вы­ду­мы­вал эти тер­ми­ны.
 
Моя же­на ­ве­дет кружок по по­ши­ву лоскут­ных по­кры­вал. По­отирав­шись око­ло их сбо­рищ, я на­у­чил­ся от­ли­чать узор «пле­тен­ка» от узо­ра «ле­стнич­ка», у­знал, что де­ше­вый ва­тин мох­рит­ся, и понял, как вы­ре­зать фес­то­ны для «ши­ро­ких квад­ра­тов». Нет, я не вы­ду­мы­вал эти тер­ми­ны.
Строка 51: Строка 51:
  
 
Здесь тра­ди­ци­он­ная мо­дель безо­пас­но­сти в Linux ста­но­вит­ся бес­силь­ной, и управ­ление на се­бя бе­рет SELinux. Важ­но понимать, что ре­шения об ав­то­ри­за­ции, принимае­мые SELinux, до­пол­ня­ют, а не за­ме­ня­ют тра­ди­ци­он­ную мо­дель. Ес­ли пра­ва rwx не раз­ре­ша­ют досту­па – точ­ка. Но ес­ли они раз­ре­ша­ют, по­ли­ти­ки SELinux да­ют сис­те­ме до­полнитель­ную воз­мож­ность за­пре­тить его.
 
Здесь тра­ди­ци­он­ная мо­дель безо­пас­но­сти в Linux ста­но­вит­ся бес­силь­ной, и управ­ление на се­бя бе­рет SELinux. Важ­но понимать, что ре­шения об ав­то­ри­за­ции, принимае­мые SELinux, до­пол­ня­ют, а не за­ме­ня­ют тра­ди­ци­он­ную мо­дель. Ес­ли пра­ва rwx не раз­ре­ша­ют досту­па – точ­ка. Но ес­ли они раз­ре­ша­ют, по­ли­ти­ки SELinux да­ют сис­те­ме до­полнитель­ную воз­мож­ность за­пре­тить его.
 +
{{Врезка|left|Заголовок= Уяз­ви­мо­сти дня|Ширина=30%|Содержание= Уяз­ви­мость про­грам­мы – недоста­ток про­грам­мы, по­зво­ляю­щий зло­умыш­леннику за­ста­вить про­грам­му сде­лать нечто для нее нештат­ное. В иде­аль­ном ми­ре у про­грамм не бы­ло бы уяз­ви­мо­стей (во­об­ще-то в ис­тин­но иде­аль­ном ми­ре не бы­ло бы и зло­умыш­ленников, но это дру­гая ис­то­рия).
  
==Не­во­об­ра­зи­мая слож­ность==
+
В ре­аль­но­сти уяз­ви­мо­сти иногда об­на­ру­жи­ва­ют­ся. И тогда раз­ра­бот­чи­ки про­грамм долж­ны сроч­но взять­ся за про­бле­му и вы­пустить за­плат­ку или об­нов­ление, а сис­тем­ные ад­минист­ра­то­ры (это вы!) долж­ны уста­но­вить его.
  
Де­та­ли уст­рой­ст­ва SELinux, мяг­ко го­во­ря, непро­сты. Но да­вай­те окунем­ся в них и уз­на­ем, смо­жем ли мы хо­тя бы по­чув­ст­во­вать их аро­мат. Ес­ли на­чи­нать с са­мо­го на­ча­ла, то у ка­ж­до­го фай­ла и ка­ж­до­го про­цес­са в сис­те­ме SELinux есть кон­текст безо­пас­но­сти, в ко­то­рый вхо­дят че­ты­ре со­став­ляю­щих:
+
Но как бы бы­ст­ро раз­ра­бот­чик ни соз­дал за­плат­ку и как бы бы­ст­ро ад­минист­ра­тор ни уста­но­вил бы ее, су­ще­ст­ву­ет про­ме­жу­ток вре­мени, в ко­то­рый уяз­ви­мость из­вест­на, но не ис­прав­ле­на. Это так на­зы­вае­мые уяз­ви­мо­сти ну­ле­во­го дня, из­вест­ные по­тен­ци­аль­ным зло­умыш­ленникам, но неиз­вест­ные раз­ра­бот­чи­кам ПО.
  
{| class="wikitable" style="float:right; margin-left:0.8em; clear:right"
+
Они-то и вы­зы­ва­ют у сис­тем­ных ад­минист­ра­то­ров при­сту­пы па­ра­нойи, и слу­жат дви­жи­те­лем раз­ра­бот­ки сис­тем управ­ления досту­пом вро­де SELinux.
 +
}}
 +
 
 +
==Не­во­об­ра­зи­мая слож­ность==
 +
{| class="wikitable" style="float:right; margin-left:0.8em; width:50%"
 
|-
 
|-
| Текст ячейки1
+
| ПОЛЬЗОВАТЕЛЬ [USER]
| Текст ячейки1
+
| Это поль­зо­ва­тель SELinux,
 +
|-
 +
|  РОЛЬ [ROLE]
 +
| ис­поль­зу­ет­ся для управ­ления досту­пом на осно­ве ро­лей (role-based access control – RBAC). Поль­зо­ва­те­ли ав­то­ри­зу­ют­ся для по­лу­чения оп­ре­де­лен­ных ро­лей, а ро­ли оп­ре­де­ля­ют, к ка­ким ре­сур­сам у поль­зо­ва­те­ля есть доступ. Ро­ли ис­поль­зу­ют­ся в управ­лении про­цес­са­ми, но фай­лы, ко­то­рые по су­ти пас­сив­ны, на са­мом де­ле не поль­зу­ют­ся ро­ля­ми, и для них ис­поль­зу­ет­ся «пустая роль» object_r.
 +
|-
 +
| ТИП [TYPE]
 +
| Это глав­ные ат­ри­бу­ты безо­пас­но­сти, ко­то­ры­ми SELinux ру­ко­во­дству­ет­ся при при­ня­тии ре­шения о досту­пе. При при­менении к про­цес­сам ти­пы так­же на­зы­ва­ют­ся до­ме­на­ми и по су­ти оп­ре­де­ля­ют име­но­ван­ную «пе­сочницу», в ко­то­рой вы­пол­ня­ет­ся про­цесс.
 +
|-
 +
|УРОВЕНЬ [LEVEL]
 +
|С по­мо­щью это­го ат­ри­бу­та реа­ли­зу­ет­ся много­уровневая сис­те­ма досту­па – в ее осно­ве ле­жит идея о том, что до­ку­мен­ты мо­гут быть «пуб­лич­ны­ми», «кон­фи­ден­ци­аль­ны­ми», «со­вер­шен­но сек­рет­ны­ми» и т. д.
 
|}
 
|}
 +
Де­та­ли уст­рой­ст­ва SELinux, мяг­ко го­во­ря, непро­сты. Но да­вай­те окунем­ся в них и уз­на­ем, смо­жем ли мы хо­тя бы по­чув­ст­во­вать их аро­мат. Ес­ли на­чи­нать с са­мо­го на­ча­ла, то у ка­ж­до­го фай­ла и ка­ж­до­го про­цес­са в сис­те­ме SELinux есть кон­текст безо­пас­но­сти, в ко­то­рый вхо­дят че­ты­ре со­став­ляю­щих:
 +
 +
 +
 +
При­вяз­ка кон­тек­стов безо­пас­но­сти к фай­лам на­зы­ва­ет­ся «по­мет­кой» фай­ло­вой сис­те­мы.
 +
 +
Кон­текст безо­пас­но­сти фай­ла мож­но про­смот­реть, ско­ман­довав ls -Z:
 +
 +
# ls -Z /usr/bin/ssh
 +
 +
-rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh
 +
 +
Здесь мы ви­дим, что у фай­ла есть соб­ст­вен­ный тип ssh_exec_t.
 +
 +
Обыч­ный файл поль­зо­ва­те­ля в до­маш­нем ка­та­ло­ге мо­жет вы­гля­деть так:
 +
 +
$ ls -lZ sample
 +
 +
-rw-r--r--. chris chris unconfined_u:object_r:user_home_t:s0 sample
 +
 +
Об­ра­ти­те вни­ма­ние, что в ка­че­ст­ве вла­дель­ца SELinux ото­бра­жа­ет­ся unconfined_u, как мы упо­ми­на­ли ра­нее.
 +
 +
Кон­текст безо­пас­но­сти про­цес­са мож­но про­смот­реть ко­ман­дой ps -Z:
 +
 +
# ps -eZ | grep sshd
 +
 +
system_u:system_r:sshd_t:s0-s0:c0.c1023 1508 ? 00:00:00 sshd
 +
 +
Здесь мы опять же ви­дим, что у де­мо­на ssh есть соб­ст­вен­ный до­мен (sandbox, пе­сочница) по имени sshd_t.
 +
 +
Вся эта но­вая ин­фор­ма­ция, свя­зы­вае­мая с фай­ла­ми и про­цес­са­ми, тре­бу­ет из­менения ря­да стан­дарт­ных ути­лит, что­бы они «зна­ли» о SELinux. На­при­мер, ls, ps и id рас­ши­ря­ют­ся с це­лью ото­бра­жения кон­тек­ста безо­пас­но­сти фай­лов, про­цес­сов и поль­зо­ва­те­лей со­от­вет­ст­вен­но. Ути­ли­ты управ­ления фай­ла­ми, ти­па cp и mv, из­ме­ня­ют­ся так, что­бы со­хра­нять кон­текст безо­пас­но­сти для соз­да­вае­мых ими фай­лов. Да­же у tar по­яв­ля­ет­ся воз­мож­ность со­хра­нять кон­тек­сты безо­пас­но­сти фай­лов в ар­хив (и восста­нав­ли­вать их). Кро­ме то­го, есть несколь­ко ути­лит SELinux для управ­ления кон­тек­ста­ми безо­пас­но­сти – к ним от­но­сят­ся restorecon, secon, chcon, findcon и setfiles. Бы­ст­рый по­иск с по­мо­щью apropos на­шел в об­щей слож­но­сти не менее 41 ко­ман­ды, имею­щей от­но­шение к SELinux.
 +
 +
==Не на­ша это по­ли­ти­ка…==
 +
 +
Все это вме­сте свя­зы­ва­ет SELinux Policy [по­ли­ти­ка SELinux], ко­то­рая по су­ти пред­став­ля­ет со­бой на­бор пра­вил ви­да «про­цесс, вы­пол­няю­щий­ся в до­мене X, мо­жет по­лу­чить доступ к фай­лам ти­па Y». Ес­ли вам нра­вит­ся ме­та­фо­ра с пе­сочницей, то по­ли­ти­ки оп­ре­де­ля­ют границы пе­сочницы. Вся сис­те­ма чрез­вы­чай­но де­та­ли­зи­ро­ва­на. Что­бы дать вам пред­ставление о ее мас­шта­бе, ска­жу, что в па­кете RHEL6 selinux-policy («об­ра­зец по­ли­ти­ки») поч­ти 400 фай­лов по­ли­тик, а чис­ло строк в них пре­вы­ша­ет 350 000. По­ли­ти­ка для од­но­го только Apache со­сто­ит из 1400 строк. Впро­чем, знай­те, что пе­ред за­груз­кой в яд­ро эти по­ли­ти­ки ком­пи­ли­ру­ют­ся в дво­ич­ную фор­му.
 +
 +
Планируя эту ста­тью, я на­ив­но по­ла­гал, что су­мею объ­яснить, как пи­шет­ся по­ли­ти­ка. Но по ме­ре мое­го про­дви­жения ста­ло яс­но, что ес­ли наш глав­ред не от­даст мне льви­ную до­лю это­го но­ме­ра, ниче­го не по­лу­чит­ся. Да­же 82-странич­ное ру­ко­во­дство поль­зо­ва­те­ля по SELinux в RedHat и близ­ко не под­хо­дит к на­пи­санию по­ли­тик. Там да­же не приведено при­ме­ра. Су­ще­ст­ву­ют про­грам­мы, ко­то­рые по­мо­га­ют в ана­ли­зе и раз­ра­бот­ке по­ли­тик (на­при­мер, apol и SLIDE, обе от Tresys), но это уже выходит за ра­мки дан­ной ста­тьи. Боль­шин­ст­во ад­минист­ра­то­ров бу­дут рас­ценивать по­ли­ти­ки SELinux так же, как ис­ход­ные ко­ды яд­ра – тео­ре­ти­че­­ски их при необ­хо­ди­мо­сти мож­но из­менить, но на прак­ти­ке вы вряд ли бу­де­те этим заниматься. (Вы знае­те разницу ме­ж­ду тео­ри­ей и прак­ти­кой? Так вот, в тео­рии нет разницы, а на прак­тике она есть...)
 +
 +
Red Hat и Fedora (по-мо­ему, един­ст­вен­ные ди­ст­ри­бу­ти­вы, соз­даю­щие что-то ре­аль­но по­лез­ное с SELinux), про­во­дят так на­зы­вае­мую «це­ле­вую» по­ли­ти­ку. То есть, они в основ­ном ог­раничи­ва­ют сер­ви­сы, ко­то­рые слу­ша­ют сеть, а так­же несколь­ко про­грамм, ко­то­рые из­ме­ня­ют setuid на root, та­ких как /usr/bin/passwd. Они не ог­раничи­ва­ют дея­тель­ность, ска­жем, во­шед­ше­го в сис­те­му поль­зо­ва­те­ля. Так, на­при­мер, кон­текст безо­пас­но­сти обыч­ного поль­зо­ва­те­ля вы­гля­дит так:
 +
 +
$ id -Z
 +
 +
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
 +
 +
Пре­ж­де чем панико­вать при мыс­ли о поль­зо­ва­те­лях с «неог­раничен­ны­ми [unconfined]» пра­ва­ми, вспомните, что тра­ди­ци­он­ную мо­дель прав досту­па в Linux никто не от­ме­нял, про­сто SELinux по­ка не на­стро­ен на дальней­шее ог­раничение досту­па.
 +
 +
==На­строй­ка==
 +
 +
SELinux по­зво­ля­ет в неко­то­рой сте­пени из­менить на­строй­ки без необ­хо­ди­мо­сти пе­ре­пи­сы­вать по­ли­ти­ки. На са­мом об­щем уровне мож­но из­ме­нять зна­чение па­ра­мет­ра SELINUX в /etc/selinux/config на Disabled [Отключен], Permissive [Толерантный] или Enforcing [Усиленный]. На­зна­чение пер­во­го и третье­го ре­жи­мов понятно по на­званиям, а вто­рой, по­жа­луй, тре­бу­ет по­яснения. В этом ре­жи­ме доступ, за­пре­щае­мый по­ли­ти­кой, раз­ре­ша­ет­ся, но со­от­вет­ст­вую­щие дей­ст­вия за­пи­сы­ва­ют­ся в файл жур­на­ла. С по­мо­щью это­го ре­жи­ма удоб­но убе­дить­ся, что ва­ши на­строй­ки не вы­ве­дут сис­те­му из строя по­сле пе­ре­клю­чения в ре­жим Уси­лен­ный. Есть да­же ути­ли­та audit2allow, ко­то­рая сгенери­ру­ет пра­ви­ла по­ли­ти­ки SELinux по лог-фай­лам опе­ра­ций, ко­то­рым бы­ло от­ка­за­но в досту­пе.
 +
 +
Оп­ре­де­лить, в ка­ком ре­жи­ме вы на­хо­ди­тесь сей­час, мож­но ко­ман­дой sestatus:
 +
 +
# sestatus
 +
 +
SELinux status: enabled
 +
 +
SELinuxfs mount: /selinux
 +
 +
Current mode: enforcing
 +
 +
Mode from config file: enforcing
 +
 +
Policy version: 24
 +
 +
Policy from config file: targeted
 +
 +
Бо­лее тон­кий кон­троль обес­пе­чи­ва­ет­ся ло­ги­че­­ски­­ми пра­ви­ла­ми SELinux. С их по­мо­щью ад­минист­ра­тор мо­жет раз­ре­шить или за­пре­тить оп­ре­де­лен­ный доступ локаль­но без необ­хо­ди­мо­сти пе­ре­за­груз­ки или пе­ре­ком­пи­ля­ции по­ли­ти­ки SELinux. При­ме­ры ло­ги­че­­ских пра­вил та­ко­вы: «Раз­ре­шить https доступ к фай­ло­вым сис­те­мам nfs», «Раз­ре­шить сис­те­ме за­пускать­ся с NIS», «Раз­ре­шить samba от­кры­вать до­машние ка­та­ло­ги поль­зо­ва­те­лей для об­ще­го досту­па». Ко­ман­да
 +
 +
getsebool -a
 +
 +
вы­ве­дет все ло­ги­че­ские пра­ви­ла. В мо­ей собственной тес­то­вой сис­те­ме RHEL6 их 168.
 +
 +
==Бур­ный ин­ци­дент==
 +
 +
Ес­ли вы иг­рае­те не по пра­ви­лам, SELinux за­про­сто под­прыгнет и уку­сит вас. В ка­че­­ст­ве та­ко­го при­ме­ра рас­ска­жу ис­то­рию, имев­шую ме­сто на од­ном из недавних за­ня­тий. Курс со­дер­жал уп­ражнение для сту­ден­тов – восста­но­вить уте­рян­ный па­роль поль­зо­ва­те­ля root.
 +
[[Файл:LXF158.sysadmin.securit_opt.png | |thumb|410px|]]
 +
[[Файл:LXF158.sysadmin.apolsc_opt.jpeg |left |600px |thumb| Apol, од­на из гра­фи­че­ских ути­лит от Tresys, по­мо­га­ет ана­ли­зи­ро­вать по­ли­ти­ки SELinux.]]
 +
Что­бы «по­те­рять» па­роль, сту­ден­ты за­пуска­ли скрипт, ко­то­рый (тай­но) мо­ди­фи­ци­ро­вал файл /etc/shadow, при­мер­но та­кой:
 +
 +
sed s/foo/bar /etc/shadow > /tmp/newshadow
 +
 +
mv /tmp/newshadow /etc/shadow
 +
 +
chmod 400 /etc/shadow
 +
 +
Скрипт соз­да­вал но­вый, из­менен­ный файл с нера­бо­таю­щим па­ро­лем root и пе­ре­име­но­вал его об­рат­но в /etc/shadow. И сту­ден­там при­шлось сде­лать спа­са­тель­ную пе­ре­за­груз­ку сис­те­мы и сбро­сить па­роль root. В сис­те­ме без SELinux у них бы все по­лу­чи­лось.
 +
 +
Что же про­изош­ло? Им во­об­ще не уда­лось вой­ти в сис­те­му – ни от имени root, ни от имени лю­бо­го дру­го­го поль­зо­ва­те­ля. Про­бле­ма в том, что у фай­ла shadow осо­бый кон­текст безо­пас­но­сти SELinux. А у вновь соз­дан­ной ко­пии фай­ла был дру­гой кон­текст безо­пас­но­сти. Как след­ст­вие, по­сле пе­ре­за­груз­ки сис­те­мы да­же про­грам­ма login (ко­то­рая за­пуска­ет­ся от имени root) не смог­ла про­чи­тать файл shadow. Ре­зуль­тат? Вхо­да нет! Хо­тя это пре­крас­но ил­лю­ст­ри­ру­ет мощь SELinux, имен­но в та­кие ситуации пре­по­да­ва­тель мень­ше все­го жа­ж­дет попасть на уро­ках; впро­чем, у нас не бы­ло вы­бо­ра.
 +
 +
==Неуси­лен­ный ре­жим==
 +
 +
Нам уда­лось восста­но­вить сис­те­му, пре­рвав за­груз­ку и до­ба­вив enforcing=0 к спи­ску па­ра­мет­ров, ко­то­рые Grub пе­ре­да­ет яд­ру. Тогда яд­ро за­пуска­ет­ся с неуси­лен­ным ре­жи­мом SELinux, в ко­то­ром мы по крайней ме­ре смог­ли вой­ти в сис­те­му. Что­бы пол­но­стью восста­но­вить сис­те­му, мы вы­полнили ко­ман­ду:
 +
 +
# restorecon /etc/shadow
 +
 +
ко­то­рая вер­ну­ла преж­ний кон­текст безо­пас­но­сти фай­ла.
 +
 +
В чем мо­раль сей басни? Конеч­но, не сто­ит ме­нять файл shadow так, как это сде­ла­ли мы. Нуж­но поль­зо­вать­ся ко­ман­дой passwd, ко­то­рая со­хранит вер­ный кон­текст безо­пас­но­сти SELinux. Но мы сде­ла­ли та­кое, от че­го не зна­ко­мый с SELinux ад­минист­ра­тор не ждал бы ниче­го пло­хо­го, вот и ог­реб­ли.
 +
 +
Про­ана­ли­зи­ру­ем про­изо­шед­шее под­робнее. У ис­ход­но­го фай­ла /etc/shadow бы­ла та­кая мет­ка:
 +
 +
# ls -lZ /etc/shadow
 +
 +
----------. root root system_u:object_r:shadow_t:s0 /etc/shadow
 +
 +
По­сле за­пус­ка скрип­та мет­ка ста­ла та­кой:
 +
 +
# ls -lZ /etc/shadow
 +
 +
----------. root root unconfined_u:object_r:user_tmp_t:s0 /etc/shadow
 +
 +
Из­ме­ни­лись и вла­де­лец фай­ла в SELinux, и «тип» мет­ки. По­сле воз­вра­ще­ния в нор­маль­ное со­стоя­ние болт­ли­вая за­пись в /var/log/audit/audit.log со­об­ща­ет нам, что про­изош­ло:
 +
 +
type=AVC msg=audit(1330372308.768:52621): avc: denied {
 +
 +
read } for pid=28670 comm=”unix_chkpwd”
 +
 +
name=”shadow” dev=dm-0 ino=815961
 +
 +
scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tconte
 +
 +
xt=unconfined_u:object_r:user_tmp_t:s0 tclass=file
  
 +
Взгля­нув на нее внима­тель­но, вы уви­ди­те, что про­цес­су в до­мене chkpwd_t был за­пре­щен доступ к фай­лу ти­па user_tmp_t, а это тип на­ше­го (ис­пор­чен­но­го) фай­ла shadow. Тип type=AVC, ко­то­рый вы здесь ви­ди­те – ссыл­ка на кэш век­то­ров досту­па (Access Vector Cache), хранили­ще недав­но при­ня­тых SELinux ре­шений о раз­ре­шении или за­пре­щении досту­па.
  
ПОЛЬЗОВАТЕЛЬ [USER]
+
Кста­ти, с по­мо­щью ко­ман­ды aureport мож­но из­влечь со­об­щения SELinux из лог-фай­ла в бо­лее удоб­ном для воспри­ятия фор­ма­те.
  
Это поль­зо­ва­тель SELinux, ко­то­ро­му «при­над­ле­жит» файл или про­цесс. Эти поль­зо­ва­те­ли на­пря­мую не со­от­вет­ст­­ву­ют учет­ным за­пи­сям в /etc/passwd; на са­мом де­ле, боль­шин­ст­­во обыч­ных учет­ных за­пи­сей в Linux свя­за­ны с поль­зо­ва­те­лем unconfined_u SELinux.
+
==И в за­клю­чение…==
  
РОЛЬ [ROLE]
+
Возможности SELinux об­шир­ны. При вер­ной на­строй­ке он мо­жет рез­ко снизить рис­ки взло­ма сер­ве­ра, а при невер­ной – пол­но­стью вы­вес­ти сис­те­му из строя. На мой взгляд, глав­ная пре­гра­да к ис­поль­зо­ванию SELinux – это его слож­ность. Сис­тем­ные ад­минист­ра­то­ры лю­бят слож­но­сти лишь до неко­то­рой сте­пени, а по­том сда­ют­ся и про­сто от­клю­ча­ют его.
  
Ис­поль­зу­ет­ся для управ­ления досту­пом на осно­ве ро­лей (role-based access control – RBAC). Поль­зо­ва­те­ли ав­то­ри­зу­ют­ся для по­лу­чения оп­ре­де­лен­ных ро­лей, а ро­ли оп­ре­де­ля­ют, к ка­ким ре­сур­сам у поль­зо­ва­те­ля есть доступ. Ро­ли ис­поль­зу­ют­ся в управ­лении про­цес­са­ми, но фай­лы, ко­то­рые по су­ти пас­сив­ны, на са­мом де­ле не поль­зу­ют­ся ро­ля­ми, и для них ис­поль­зу­ет­ся «пустая роль» object_r.
+
Ес­ли у вас есть опыт ра­бо­ты с SELinux (удач­ный или не очень), черкните мне па­ру строк на chris.linuxformat@gmail.com. Бы­ло бы осо­бен­но ин­те­рес­но услы­шать тех, ко­му SELinux по­мог от­ра­зить на­стоя­щую ата­ку на их сис­те­му. Ведь именно ради это­го мы и го­ро­дим ого­род. |
 +
 +
  
ТИП [TYPE]
+
==К ис­то­кам==
  
Это глав­ные ат­ри­бу­ты безо­пас­но­сти, ко­то­ры­ми SELinux ру­ко­во­дству­ет­ся при при­ня­тии ре­шения о досту­пе. При при­менении к про­цес­сам ти­пы так­же на­зы­ва­ют­ся до­ме­на­ми и по су­ти оп­ре­де­ля­ют име­но­ван­ную «пе­сочницу», в ко­то­рой вы­пол­ня­ет­ся про­цесс.
+
SELinux из­на­чаль­но раз­ра­ба­ты­вал­ся в Агент­ст­ве на­цио­наль­ной безо­пас­но­сти США (в об­щих чер­тах – ана­лог Цен­тра пра­ви­тель­ст­вен­ной свя­зи Ве­ли­ко­бри­тании, см. http://www.nsa.gov/research/selinux). Боль­шин­ст­во дру­гих ути­лит так­же бы­ли раз­ра­бо­та­ны ком­панией Tresys (см. oss.tresys.com), ей при­над­ле­жит боль­шой на­бор ути­лит (как кон­соль­ных, так и гра­фи­че­­ских) для ана­ли­за и раз­ра­бот­ки по­ли­тик.
  
УРОВЕНЬ [LEVEL]
+
===Где уз­нать боль­ше===
  
С по­мо­щью это­го ат­ри­бу­та реа­ли­зу­ет­ся много­уровневая сис­те­ма досту­па – в ее осно­ве ле­жит идея о том, что до­ку­мен­ты мо­гут быть «пуб­лич­ны­ми», «кон­фи­ден­ци­аль­ны­ми», «со­вер­шен­но сек­рет­ны­ми» и т. д.
+
Книга Бил­ла Мак­кар­ти [Bill McCarty] по SELinux (опуб­ли­ко­ван­ная в из­да­тель­ст­ве «О’Рэйли») – в неко­то­ром смыс­ле наи­бо­лее пол­ная ра­бо­та, хо­тя она и вы­шла в 2004 г. и ее воз­раст неиз­беж­но ска­зы­ва­ет­ся. Ру­ко­во­дство поль­зо­ва­те­ля по SELinux в RedHat (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux) – бо­лее прак­тич­ное и совре­менное. Так­же мас­са ин­фор­ма­ции есть на сай­те selinuxproject.org.

Текущая версия на 16:27, 17 сентября 2018


(thumbnail)
Д-р Крис Браун. Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.

По рецептам доктора Брауна

Содержание

[править] Эзо­те­ри­че­ское сис­тем­ное ад­ми­ни­ст­ри­ро­ва­ние из при­чуд­ли­вых за­во­ро­тов ки­шок сер­вер­ной

[править] Знать свои сла­бо­сти

Что­бы за­щи­тить свои ком­пь­ю­те­ры от на­па­дения, нуж­но знать свои уяз­ви­мо­сти. Вам по­мо­жет OpenVAS.

Мож­но ли быть уве­рен­ным в том, что сис­те­ма за­щи­ще­на? Ну, на 100 % нель­зя никогда. Но мож­но су­ще­ст­вен­но по­вы­сить свою уве­рен­ность, за­пустив сканер уяз­ви­мо­стей, и во мно­гих ор­ганиза­ци­ях это де­ла­ет­ся на ре­гу­ляр­ной осно­ве.

OpenVAS – од­на из та­ких про­грамм. Это от­ветв­ление Nessus, по­пу­ляр­но­го сканера, ко­то­рый в 2005 го­ду пре­вра­тил­ся из от­кры­то­го в ком­мер­че­­ский. К мо­мен­ту чтения этой ста­тьи долж­на вый­ти OpenVAS 5. OpenVAS за­пуска­ет на глав­ном ком­пь­ю­те­ре сканирую­щий де­мон, ко­то­рый вы­пол­ня­ет се­рию про­ве­рок на уяз­ви­мость для за­дан­но­го на­бо­ра объ­ек­тов. Эти про­вер­ки на­зы­ва­ют­ся про­вер­ка­ми се­те­вой уяз­ви­мо­сти (NVT – network vulnerability tests) и пи­шут­ся на про­стом скрип­то­вом язы­ке (Nessus Attack Scripting Language – язык опи­сания атак Nessus).

[править] Ты­сяч­ное вой­ско

Сейчас та­ких тес­тов чуть менее 25 000, и ка­ж­дый день до­бав­ля­ют­ся но­вые в от­вет на но­вую ин­фор­ма­цию об уг­ро­зах безо­пас­но­сти, по­сту­паю­щую от про­из­во­ди­те­лей ПО и из от­че­тов ис­сле­до­ва­те­лей. Око­ло 16 000 из этих тес­тов осно­ва­ны на ин­фор­ма­ции от про­из­во­ди­те­лей ПО, обыч­но в та­кой фор­ме: «О, у вас вер­сия X при­ло­жения Y. Зна­чит, у вас есть уяз­ви­мость Z». Дру­гие тес­ты ре­аль­но взаи­мо­дей­ст­ву­ют с сис­те­мой, оп­ре­де­ляя уяз­ви­мо­сти. Ка­че­­ст­во ра­бо­ты OpenVAS, оче­вид­но, за­ви­сит от ка­че­­ст­ва тес­тов и свое­вре­мен­но­сти их соз­дания и рас­про­странения по ме­ре об­на­ру­жения но­вых уг­роз. OpenVAS обес­пе­чи­ва­ет бес­плат­ный при­ток тес­тов; есть так­же и ком­мер­че­­ский, от немец­кой ком­пании Greenbone, раз­ра­бот­чи­ка OpenVAS. Что­бы по-бы­ст­ро­му это по­про­бо­вать, ска­чай­те вир­ту­аль­ный эк­зем­п­ляр OpenVAS4 с сай­та openvas.org; он со­вмес­тим с VirtualBox и VMWare (сам я про­бо­вал толь­ко по­следнее) и пре­достав­ля­ет сер­вер OpenVAS – с ним мож­но ра­бо­тать через ути­литы команд­ной стро­ки или с по­мо­щью брау­зе­ра че­рез порт 9392. На­до ска­зать, что хо­тя его лег­ко за­гру­зить и уста­но­вить, кри­вая его изу­чения до­воль­но кру­та. Для прак­ти­че­­ско­­го ис­поль­зо­вания уста­но­ви­те са­ми па­ке­ты OpenVAS. Воз­мож­но, они есть в ре­по­зи­то­ри­ях ва­ше­го ди­ст­ри­бу­ти­ва.

На­конец, заост­рим, что за­пуск сканера уяз­ви­мо­стей сам по се­бе вол­шеб­ным об­ра­зом не по­вы­сит вам безо­пас­ность. Кто-то дол­жен его от­че­ты чи­тать и принимать ме­ры. И во мно­гих слу­ча­ях доста­точ­но про­сто об­но­вить уяз­ви­мое при­ло­жение до бо­лее поздней вер­сии.

[править] Linux уп­роч­ня­ет за­щи­ту

У SELinux ре­пу­та­ция не­ве­ро­ят­но слож­ной сис­те­мы, но он слиш­ком ва­жен, что­бы его иг­но­ри­ро­вать. Рас­смот­рим этот важ­ный ру­беж обо­ро­ны.

Дол­жен при­знать­ся, что при упо­ми­нании SELinux я ве­ду се­бя как страус – пря­чу го­ло­ву в пе­сок и на­де­юсь, что он ис­чезнет. Но RedHat принима­ет его все­рь­ез, и сис­тем­ным ад­мин­ст­ра­то­рам при­хо­дит­ся иметь с ним де­ло все ча­ще. И я ре­шил, что луч­ше рас­ска­зать об его осно­вах, хо­тя бы немно­го.

Пре­ж­де все­го, за­чем он ну­жен? В двух сло­вах – его на­зна­чение в том, что­бы ог­раничить ущерб сис­те­мы из-за ата­ки, восполь­зо­вав­шей­ся уяз­ви­мо­стью в про­грам­ме. Что­бы по­нять, как это ра­бо­та­ет, начнем с тра­ди­ци­он­ной мо­де­ли прав досту­па к фай­лам в Linux, под ко­то­рой я имею в ви­ду из­вест­ные раз­ре­шения rwx. В этой мо­де­ли ав­то­ри­за­ция про­ис­хо­дит ис­клю­чи­тель­но по UID и GID про­цес­са, вы­пол­няю­ще­го за­прос. Ес­ли про­цесс за­пуска­ет­ся от имени поль­зо­ва­те­ля chris, я ви­жу одни пра­ва досту­па, ес­ли от имени root – дру­гие, и т. д. На­при­мер, пусть я поль­зу­юсь Firefox. Ра­зу­ме­ет­ся, брау­зе­ру ну­жен доступ к неко­то­рым ка­та­ло­гам фай­ло­вой сис­те­мы – что­бы кэ­ши­ро­вать cookie, за­пи­сы­вать ис­то­рию и т. д., но все мои фай­лы ему ни к че­му. Од­на­ко ес­ли от­крыть в нем ак­тив­ное вре­до­носное со­дер­жи­мое, умею­щее ис­поль­зо­вать уяз­ви­мость в брау­зе­ре, зло­умыш­ленник по­тен­ци­аль­но по­лу­чит доступ к тем же фай­лам, что и я (как поль­зо­ва­тель chris).

С се­те­вы­ми сер­ви­са­ми про­бле­ма час­то и то­го ост­рее, ведь мно­гие из них за­пуска­ют­ся от имени суперпользователя-root, и восполь­зо­вав­шись уяз­ви­мо­стью в та­ких сер­ви­сах, ата­кую­щий мо­жет по­лу­чить доступ ко всей сис­те­ме.

Как на­пи­са­но в ру­ко­во­дстве поль­зо­ва­те­ля по SELinux в RedHat, «Мно­гие сис­тем­ные сер­ви­сы и про­грам­мы за­пуска­ют­ся со вчерне за­дан­ны­ми при­ви­ле­гия­ми, на­мно­го пре­восхо­дя­щи­ми их по­треб­но­сти, и ошиб­ка в лю­бой из этих про­грамм мо­жет быть ис­поль­зо­ва­на для по­лу­чения досту­па к сис­те­ме».

Здесь тра­ди­ци­он­ная мо­дель безо­пас­но­сти в Linux ста­но­вит­ся бес­силь­ной, и управ­ление на се­бя бе­рет SELinux. Важ­но понимать, что ре­шения об ав­то­ри­за­ции, принимае­мые SELinux, до­пол­ня­ют, а не за­ме­ня­ют тра­ди­ци­он­ную мо­дель. Ес­ли пра­ва rwx не раз­ре­ша­ют досту­па – точ­ка. Но ес­ли они раз­ре­ша­ют, по­ли­ти­ки SELinux да­ют сис­те­ме до­полнитель­ную воз­мож­ность за­пре­тить его.

[править] Не­во­об­ра­зи­мая слож­ность

ПОЛЬЗОВАТЕЛЬ [USER] Это поль­зо­ва­тель SELinux,
РОЛЬ [ROLE] ис­поль­зу­ет­ся для управ­ления досту­пом на осно­ве ро­лей (role-based access control – RBAC). Поль­зо­ва­те­ли ав­то­ри­зу­ют­ся для по­лу­чения оп­ре­де­лен­ных ро­лей, а ро­ли оп­ре­де­ля­ют, к ка­ким ре­сур­сам у поль­зо­ва­те­ля есть доступ. Ро­ли ис­поль­зу­ют­ся в управ­лении про­цес­са­ми, но фай­лы, ко­то­рые по су­ти пас­сив­ны, на са­мом де­ле не поль­зу­ют­ся ро­ля­ми, и для них ис­поль­зу­ет­ся «пустая роль» object_r.
ТИП [TYPE] Это глав­ные ат­ри­бу­ты безо­пас­но­сти, ко­то­ры­ми SELinux ру­ко­во­дству­ет­ся при при­ня­тии ре­шения о досту­пе. При при­менении к про­цес­сам ти­пы так­же на­зы­ва­ют­ся до­ме­на­ми и по су­ти оп­ре­де­ля­ют име­но­ван­ную «пе­сочницу», в ко­то­рой вы­пол­ня­ет­ся про­цесс.
УРОВЕНЬ [LEVEL] С по­мо­щью это­го ат­ри­бу­та реа­ли­зу­ет­ся много­уровневая сис­те­ма досту­па – в ее осно­ве ле­жит идея о том, что до­ку­мен­ты мо­гут быть «пуб­лич­ны­ми», «кон­фи­ден­ци­аль­ны­ми», «со­вер­шен­но сек­рет­ны­ми» и т. д.

Де­та­ли уст­рой­ст­ва SELinux, мяг­ко го­во­ря, непро­сты. Но да­вай­те окунем­ся в них и уз­на­ем, смо­жем ли мы хо­тя бы по­чув­ст­во­вать их аро­мат. Ес­ли на­чи­нать с са­мо­го на­ча­ла, то у ка­ж­до­го фай­ла и ка­ж­до­го про­цес­са в сис­те­ме SELinux есть кон­текст безо­пас­но­сти, в ко­то­рый вхо­дят че­ты­ре со­став­ляю­щих:


При­вяз­ка кон­тек­стов безо­пас­но­сти к фай­лам на­зы­ва­ет­ся «по­мет­кой» фай­ло­вой сис­те­мы.

Кон­текст безо­пас­но­сти фай­ла мож­но про­смот­реть, ско­ман­довав ls -Z:

# ls -Z /usr/bin/ssh
-rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Здесь мы ви­дим, что у фай­ла есть соб­ст­вен­ный тип ssh_exec_t.

Обыч­ный файл поль­зо­ва­те­ля в до­маш­нем ка­та­ло­ге мо­жет вы­гля­деть так:

$ ls -lZ sample

-rw-r--r--. chris chris unconfined_u:object_r:user_home_t:s0 sample

Об­ра­ти­те вни­ма­ние, что в ка­че­ст­ве вла­дель­ца SELinux ото­бра­жа­ет­ся unconfined_u, как мы упо­ми­на­ли ра­нее.

Кон­текст безо­пас­но­сти про­цес­са мож­но про­смот­реть ко­ман­дой ps -Z:

# ps -eZ | grep sshd
system_u:system_r:sshd_t:s0-s0:c0.c1023 1508 ? 00:00:00 sshd

Здесь мы опять же ви­дим, что у де­мо­на ssh есть соб­ст­вен­ный до­мен (sandbox, пе­сочница) по имени sshd_t.

Вся эта но­вая ин­фор­ма­ция, свя­зы­вае­мая с фай­ла­ми и про­цес­са­ми, тре­бу­ет из­менения ря­да стан­дарт­ных ути­лит, что­бы они «зна­ли» о SELinux. На­при­мер, ls, ps и id рас­ши­ря­ют­ся с це­лью ото­бра­жения кон­тек­ста безо­пас­но­сти фай­лов, про­цес­сов и поль­зо­ва­те­лей со­от­вет­ст­вен­но. Ути­ли­ты управ­ления фай­ла­ми, ти­па cp и mv, из­ме­ня­ют­ся так, что­бы со­хра­нять кон­текст безо­пас­но­сти для соз­да­вае­мых ими фай­лов. Да­же у tar по­яв­ля­ет­ся воз­мож­ность со­хра­нять кон­тек­сты безо­пас­но­сти фай­лов в ар­хив (и восста­нав­ли­вать их). Кро­ме то­го, есть несколь­ко ути­лит SELinux для управ­ления кон­тек­ста­ми безо­пас­но­сти – к ним от­но­сят­ся restorecon, secon, chcon, findcon и setfiles. Бы­ст­рый по­иск с по­мо­щью apropos на­шел в об­щей слож­но­сти не менее 41 ко­ман­ды, имею­щей от­но­шение к SELinux.

[править] Не на­ша это по­ли­ти­ка…

Все это вме­сте свя­зы­ва­ет SELinux Policy [по­ли­ти­ка SELinux], ко­то­рая по су­ти пред­став­ля­ет со­бой на­бор пра­вил ви­да «про­цесс, вы­пол­няю­щий­ся в до­мене X, мо­жет по­лу­чить доступ к фай­лам ти­па Y». Ес­ли вам нра­вит­ся ме­та­фо­ра с пе­сочницей, то по­ли­ти­ки оп­ре­де­ля­ют границы пе­сочницы. Вся сис­те­ма чрез­вы­чай­но де­та­ли­зи­ро­ва­на. Что­бы дать вам пред­ставление о ее мас­шта­бе, ска­жу, что в па­кете RHEL6 selinux-policy («об­ра­зец по­ли­ти­ки») поч­ти 400 фай­лов по­ли­тик, а чис­ло строк в них пре­вы­ша­ет 350 000. По­ли­ти­ка для од­но­го только Apache со­сто­ит из 1400 строк. Впро­чем, знай­те, что пе­ред за­груз­кой в яд­ро эти по­ли­ти­ки ком­пи­ли­ру­ют­ся в дво­ич­ную фор­му.

Планируя эту ста­тью, я на­ив­но по­ла­гал, что су­мею объ­яснить, как пи­шет­ся по­ли­ти­ка. Но по ме­ре мое­го про­дви­жения ста­ло яс­но, что ес­ли наш глав­ред не от­даст мне льви­ную до­лю это­го но­ме­ра, ниче­го не по­лу­чит­ся. Да­же 82-странич­ное ру­ко­во­дство поль­зо­ва­те­ля по SELinux в RedHat и близ­ко не под­хо­дит к на­пи­санию по­ли­тик. Там да­же не приведено при­ме­ра. Су­ще­ст­ву­ют про­грам­мы, ко­то­рые по­мо­га­ют в ана­ли­зе и раз­ра­бот­ке по­ли­тик (на­при­мер, apol и SLIDE, обе от Tresys), но это уже выходит за ра­мки дан­ной ста­тьи. Боль­шин­ст­во ад­минист­ра­то­ров бу­дут рас­ценивать по­ли­ти­ки SELinux так же, как ис­ход­ные ко­ды яд­ра – тео­ре­ти­че­­ски их при необ­хо­ди­мо­сти мож­но из­менить, но на прак­ти­ке вы вряд ли бу­де­те этим заниматься. (Вы знае­те разницу ме­ж­ду тео­ри­ей и прак­ти­кой? Так вот, в тео­рии нет разницы, а на прак­тике она есть...)

Red Hat и Fedora (по-мо­ему, един­ст­вен­ные ди­ст­ри­бу­ти­вы, соз­даю­щие что-то ре­аль­но по­лез­ное с SELinux), про­во­дят так на­зы­вае­мую «це­ле­вую» по­ли­ти­ку. То есть, они в основ­ном ог­раничи­ва­ют сер­ви­сы, ко­то­рые слу­ша­ют сеть, а так­же несколь­ко про­грамм, ко­то­рые из­ме­ня­ют setuid на root, та­ких как /usr/bin/passwd. Они не ог­раничи­ва­ют дея­тель­ность, ска­жем, во­шед­ше­го в сис­те­му поль­зо­ва­те­ля. Так, на­при­мер, кон­текст безо­пас­но­сти обыч­ного поль­зо­ва­те­ля вы­гля­дит так:

$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Пре­ж­де чем панико­вать при мыс­ли о поль­зо­ва­те­лях с «неог­раничен­ны­ми [unconfined]» пра­ва­ми, вспомните, что тра­ди­ци­он­ную мо­дель прав досту­па в Linux никто не от­ме­нял, про­сто SELinux по­ка не на­стро­ен на дальней­шее ог­раничение досту­па.

[править] На­строй­ка

SELinux по­зво­ля­ет в неко­то­рой сте­пени из­менить на­строй­ки без необ­хо­ди­мо­сти пе­ре­пи­сы­вать по­ли­ти­ки. На са­мом об­щем уровне мож­но из­ме­нять зна­чение па­ра­мет­ра SELINUX в /etc/selinux/config на Disabled [Отключен], Permissive [Толерантный] или Enforcing [Усиленный]. На­зна­чение пер­во­го и третье­го ре­жи­мов понятно по на­званиям, а вто­рой, по­жа­луй, тре­бу­ет по­яснения. В этом ре­жи­ме доступ, за­пре­щае­мый по­ли­ти­кой, раз­ре­ша­ет­ся, но со­от­вет­ст­вую­щие дей­ст­вия за­пи­сы­ва­ют­ся в файл жур­на­ла. С по­мо­щью это­го ре­жи­ма удоб­но убе­дить­ся, что ва­ши на­строй­ки не вы­ве­дут сис­те­му из строя по­сле пе­ре­клю­чения в ре­жим Уси­лен­ный. Есть да­же ути­ли­та audit2allow, ко­то­рая сгенери­ру­ет пра­ви­ла по­ли­ти­ки SELinux по лог-фай­лам опе­ра­ций, ко­то­рым бы­ло от­ка­за­но в досту­пе.

Оп­ре­де­лить, в ка­ком ре­жи­ме вы на­хо­ди­тесь сей­час, мож­но ко­ман­дой sestatus:

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted

Бо­лее тон­кий кон­троль обес­пе­чи­ва­ет­ся ло­ги­че­­ски­­ми пра­ви­ла­ми SELinux. С их по­мо­щью ад­минист­ра­тор мо­жет раз­ре­шить или за­пре­тить оп­ре­де­лен­ный доступ локаль­но без необ­хо­ди­мо­сти пе­ре­за­груз­ки или пе­ре­ком­пи­ля­ции по­ли­ти­ки SELinux. При­ме­ры ло­ги­че­­ских пра­вил та­ко­вы: «Раз­ре­шить https доступ к фай­ло­вым сис­те­мам nfs», «Раз­ре­шить сис­те­ме за­пускать­ся с NIS», «Раз­ре­шить samba от­кры­вать до­машние ка­та­ло­ги поль­зо­ва­те­лей для об­ще­го досту­па». Ко­ман­да

getsebool -a

вы­ве­дет все ло­ги­че­ские пра­ви­ла. В мо­ей собственной тес­то­вой сис­те­ме RHEL6 их 168.

[править] Бур­ный ин­ци­дент

Ес­ли вы иг­рае­те не по пра­ви­лам, SELinux за­про­сто под­прыгнет и уку­сит вас. В ка­че­­ст­ве та­ко­го при­ме­ра рас­ска­жу ис­то­рию, имев­шую ме­сто на од­ном из недавних за­ня­тий. Курс со­дер­жал уп­ражнение для сту­ден­тов – восста­но­вить уте­рян­ный па­роль поль­зо­ва­те­ля root.

LXF158.sysadmin.securit opt.png
(thumbnail)
Apol, од­на из гра­фи­че­ских ути­лит от Tresys, по­мо­га­ет ана­ли­зи­ро­вать по­ли­ти­ки SELinux.

Что­бы «по­те­рять» па­роль, сту­ден­ты за­пуска­ли скрипт, ко­то­рый (тай­но) мо­ди­фи­ци­ро­вал файл /etc/shadow, при­мер­но та­кой:

sed s/foo/bar /etc/shadow > /tmp/newshadow

mv /tmp/newshadow /etc/shadow

chmod 400 /etc/shadow

Скрипт соз­да­вал но­вый, из­менен­ный файл с нера­бо­таю­щим па­ро­лем root и пе­ре­име­но­вал его об­рат­но в /etc/shadow. И сту­ден­там при­шлось сде­лать спа­са­тель­ную пе­ре­за­груз­ку сис­те­мы и сбро­сить па­роль root. В сис­те­ме без SELinux у них бы все по­лу­чи­лось.

Что же про­изош­ло? Им во­об­ще не уда­лось вой­ти в сис­те­му – ни от имени root, ни от имени лю­бо­го дру­го­го поль­зо­ва­те­ля. Про­бле­ма в том, что у фай­ла shadow осо­бый кон­текст безо­пас­но­сти SELinux. А у вновь соз­дан­ной ко­пии фай­ла был дру­гой кон­текст безо­пас­но­сти. Как след­ст­вие, по­сле пе­ре­за­груз­ки сис­те­мы да­же про­грам­ма login (ко­то­рая за­пуска­ет­ся от имени root) не смог­ла про­чи­тать файл shadow. Ре­зуль­тат? Вхо­да нет! Хо­тя это пре­крас­но ил­лю­ст­ри­ру­ет мощь SELinux, имен­но в та­кие ситуации пре­по­да­ва­тель мень­ше все­го жа­ж­дет попасть на уро­ках; впро­чем, у нас не бы­ло вы­бо­ра.

[править] Неуси­лен­ный ре­жим

Нам уда­лось восста­но­вить сис­те­му, пре­рвав за­груз­ку и до­ба­вив enforcing=0 к спи­ску па­ра­мет­ров, ко­то­рые Grub пе­ре­да­ет яд­ру. Тогда яд­ро за­пуска­ет­ся с неуси­лен­ным ре­жи­мом SELinux, в ко­то­ром мы по крайней ме­ре смог­ли вой­ти в сис­те­му. Что­бы пол­но­стью восста­но­вить сис­те­му, мы вы­полнили ко­ман­ду:

# restorecon /etc/shadow

ко­то­рая вер­ну­ла преж­ний кон­текст безо­пас­но­сти фай­ла.

В чем мо­раль сей басни? Конеч­но, не сто­ит ме­нять файл shadow так, как это сде­ла­ли мы. Нуж­но поль­зо­вать­ся ко­ман­дой passwd, ко­то­рая со­хранит вер­ный кон­текст безо­пас­но­сти SELinux. Но мы сде­ла­ли та­кое, от че­го не зна­ко­мый с SELinux ад­минист­ра­тор не ждал бы ниче­го пло­хо­го, вот и ог­реб­ли.

Про­ана­ли­зи­ру­ем про­изо­шед­шее под­робнее. У ис­ход­но­го фай­ла /etc/shadow бы­ла та­кая мет­ка:

# ls -lZ /etc/shadow

. root root system_u:object_r:shadow_t:s0 /etc/shadow

По­сле за­пус­ка скрип­та мет­ка ста­ла та­кой:

# ls -lZ /etc/shadow
----------. root root unconfined_u:object_r:user_tmp_t:s0 /etc/shadow

Из­ме­ни­лись и вла­де­лец фай­ла в SELinux, и «тип» мет­ки. По­сле воз­вра­ще­ния в нор­маль­ное со­стоя­ние болт­ли­вая за­пись в /var/log/audit/audit.log со­об­ща­ет нам, что про­изош­ло:

type=AVC msg=audit(1330372308.768:52621): avc: denied {

read } for pid=28670 comm=”unix_chkpwd”

name=”shadow” dev=dm-0 ino=815961

scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tconte

xt=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Взгля­нув на нее внима­тель­но, вы уви­ди­те, что про­цес­су в до­мене chkpwd_t был за­пре­щен доступ к фай­лу ти­па user_tmp_t, а это тип на­ше­го (ис­пор­чен­но­го) фай­ла shadow. Тип type=AVC, ко­то­рый вы здесь ви­ди­те – ссыл­ка на кэш век­то­ров досту­па (Access Vector Cache), хранили­ще недав­но при­ня­тых SELinux ре­шений о раз­ре­шении или за­пре­щении досту­па.

Кста­ти, с по­мо­щью ко­ман­ды aureport мож­но из­влечь со­об­щения SELinux из лог-фай­ла в бо­лее удоб­ном для воспри­ятия фор­ма­те.

[править] И в за­клю­чение…

Возможности SELinux об­шир­ны. При вер­ной на­строй­ке он мо­жет рез­ко снизить рис­ки взло­ма сер­ве­ра, а при невер­ной – пол­но­стью вы­вес­ти сис­те­му из строя. На мой взгляд, глав­ная пре­гра­да к ис­поль­зо­ванию SELinux – это его слож­ность. Сис­тем­ные ад­минист­ра­то­ры лю­бят слож­но­сти лишь до неко­то­рой сте­пени, а по­том сда­ют­ся и про­сто от­клю­ча­ют его.

Ес­ли у вас есть опыт ра­бо­ты с SELinux (удач­ный или не очень), черкните мне па­ру строк на chris.linuxformat@gmail.com. Бы­ло бы осо­бен­но ин­те­рес­но услы­шать тех, ко­му SELinux по­мог от­ра­зить на­стоя­щую ата­ку на их сис­те­му. Ведь именно ради это­го мы и го­ро­дим ого­род. |


[править] К ис­то­кам

SELinux из­на­чаль­но раз­ра­ба­ты­вал­ся в Агент­ст­ве на­цио­наль­ной безо­пас­но­сти США (в об­щих чер­тах – ана­лог Цен­тра пра­ви­тель­ст­вен­ной свя­зи Ве­ли­ко­бри­тании, см. http://www.nsa.gov/research/selinux). Боль­шин­ст­во дру­гих ути­лит так­же бы­ли раз­ра­бо­та­ны ком­панией Tresys (см. oss.tresys.com), ей при­над­ле­жит боль­шой на­бор ути­лит (как кон­соль­ных, так и гра­фи­че­­ских) для ана­ли­за и раз­ра­бот­ки по­ли­тик.

[править] Где уз­нать боль­ше

Книга Бил­ла Мак­кар­ти [Bill McCarty] по SELinux (опуб­ли­ко­ван­ная в из­да­тель­ст­ве «О’Рэйли») – в неко­то­ром смыс­ле наи­бо­лее пол­ная ра­бо­та, хо­тя она и вы­шла в 2004 г. и ее воз­раст неиз­беж­но ска­зы­ва­ет­ся. Ру­ко­во­дство поль­зо­ва­те­ля по SELinux в RedHat (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux) – бо­лее прак­тич­ное и совре­менное. Так­же мас­са ин­фор­ма­ции есть на сай­те selinuxproject.org.

Персональные инструменты
купить
подписаться
Яндекс.Метрика