<div dir="ltr"><div>> selinux хорошо для "compliance". типа у вас какое-то госучреждение или типа того, есть политика безопасности, регулярный аудит, и есть "соответствие требованиям" в<br>
виде включенной галочки selinux<br></div><div>т.е. если ломанут ком-кий проект и уведут у вас базу данных, это нормально? :) SELinux включают не для галочки, и да конечно же он не гарантирует 100% безопасности в случае взлома, но он гарантирует, что взломщикам будет на порядок сложнее получить необходимый результат<br></div><div><br>> а во всех нормальных случаях - selinux просто мешает жить<br></div>вы не любите кошек? Да вы просто не умеете их готовить!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-03 4:53 GMT+02:00 Илья Шипицин <span dir="ltr"><<a href="mailto:chipitsine@gmail.com" target="_blank">chipitsine@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">если вы специально делаете так, что у вас промышленные сервера и<br>
тестовые настроены по-разному - да, у вас проблема.<br>
<br>
2 февраля 2015 г., 18:10 пользователь Eugene Peregudov<br>
<<a href="mailto:eugene.peregudov@gmail.com">eugene.peregudov@gmail.com</a>> написал:<br>
<div class="HOEnZb"><div class="h5">> Коллега Juriy Strashnov опередил :)<br>
><br>
> В любой непонятной ситуации - смотрите логи, там все есть. Ни одно<br>
> запрещающее действие SELinux не пройдет мимо audit.log, также можно<br>
> поставить setroubleshoot-server, который будет писать все происходящее в<br>
> messages.<br>
><br>
> Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских<br>
> машинах:<br>
><br>
> Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае<br>
> вырабатывается набор разрешающих правил еще на машине разработчика. На этом<br>
> этапе уже становится ясно в деталях какие дополнительные разрешения (с<br>
> поправкой на пути) необходимо применить администратору при деплое<br>
> приложения.<br>
><br>
> Напротив, если разработка ведется без включенного селинукс, после деплоя<br>
> начинается многократный рефрен:<br>
> "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс -><br>
> написание правил\установка правильных меток"<br>
> Причем, делать это приходится администратору порой без знания матчасти<br>
> самого приложения, что добавляет трудностей.<br>
><br>
> Juriy Strashnov <<a href="mailto:juriy.foboss@gmail.com">juriy.foboss@gmail.com</a>> писал(а) в своём письме Mon, 02 Feb<br>
> 2015 18:24:39 +0600:<br>
><br>
> SELinux умеет объяснять, что делает. Однако получение этой информации<br>
> требует некоторых усилий. Например для вышеописанного случая с блокировкой<br>
> SSH диагностику можно провести так:<br>
><br>
> grep sshd  /var/log/audit/audit.log | audit2why<br>
><br>
> Получим сообщение:<br>
><br>
> type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for pid=26463<br>
> comm="sshd" name="authorized_keys2" dev=dm-0 ino=1441809<br>
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023<br>
> tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file<br>
><br>
> 2015-02-02 14:33 GMT+03:00 denis <<a href="mailto:denis@webmaster.spb.ru">denis@webmaster.spb.ru</a>>:<br>
>><br>
>> 28.01.2015 10:26, Eugene Peregudov пишет:<br>
>>><br>
>>><br>
>>> ИМХО, очень зря решается выключением. В первую очередь разработчик<br>
>>> приложения и мэйнтейнер должны знать и предоставить информацию о том, какие<br>
>>> разрешения необходимы приложению для корректного выполнения, а в идеале еще<br>
>>> и написать policy-файл.<br>
>>><br>
>>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh<br>
>>> (<a href="http://stopdisablingselinux.com/" target="_blank">http://stopdisablingselinux.com/</a>)<br>
>>><br>
>> До тех пор, пока оно будет включено по умолчанию - все инструкции будут<br>
>> начинаться с "выключите selinux", потому что обычно настройка делается так -<br>
>> селинух выкл или в permissive, нормальная настройка всего что запускаем и<br>
>> разворачиваем, а потом уже смотрим по результату, какие права нужны.<br>
>> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",<br>
>> первым шагом диагностики всегда будет его отключение. Это как при сетевой<br>
>> мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу<br>
>> становится понятно, кто виноват.<br>
>> До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, и<br>
>> там выключить совсем - нормальное действие.<br>
>><br>
>> Из самого банального: ssh, авторизация по ключам, .ssh создан, права 0700,<br>
>> authorized_keys создан, права 0600, все владельцы правильные. Ключ не<br>
>> принимало, пока не выключили selinux (!). В логах ничего про то, что<br>
>> выполнена блокировка селинухом. Итог: я тоже приучился первым делом<br>
>> выключать это зло, пока оно не научится само и внятно говорить, что не так.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> nginx-ru mailing list<br>
>> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
>> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Best regards, Juriy Strashnov<br>
><br>
> Mob. <a href="tel:%2B7%20%28953%29%20742-1550" value="+79537421550">+7 (953) 742-1550</a><br>
> E-mail: <a href="mailto:j.strashnov@me.com">j.strashnov@me.com</a><br>
><br>
> Please consider the environment before printing this email.<br>
><br>
><br>
><br>
><br>
> --<br>
> With best regards, Eugene JONIK Peregudov<br>
> mailto: <a href="mailto:eugene.peregudov@gmail.com">eugene.peregudov@gmail.com</a><br>
><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div>