Журнал 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

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)


(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.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF158:%D0%A0%D1%83%D0%B1%C2%AD%D1%80%D0%B8%C2%AD%D0%BA%D0%B0_%D1%81%D0%B8%C2%AD%D1%81%D0%B0%D0%B4%C2%AD%D0%BC%D0%B8%C2%AD%D0%BD%D0%B0:_%D0%97%D0%BD%D0%B0%D1%82%D1%8C_%D1%81%D0%B2%D0%BE%D0%B8_%D1%81%D0%BB%D0%B0%C2%AD%D0%B1%D0%BE%C2%AD%D1%81%D1%82%D0%B8&oldid=17763»
Персональные инструменты
купить
подписаться
Яндекс.Метрика