Re: Невозможно изменить document root

[Alex Domoradov]

> selinux хорошо для "compliance". типа у вас какое-то госучреждение или
типа того, есть политика безопасности, регулярный аудит, и есть
"соответствие требованиям" в
виде включенной галочки selinux
т.е. если ломанут ком-кий проект и уведут у вас базу данных, это нормально?
:) SELinux включают не для галочки, и да конечно же он не гарантирует 100%
безопасности в случае взлома, но он гарантирует, что взломщикам будет на
порядок сложнее получить необходимый результат

> а во всех нормальных случаях - selinux просто мешает жить
вы не любите кошек? Да вы просто не умеете их готовить!

2015-02-03 4:53 GMT+02:00 Илья Шипицин <chipitsine at gmail.com>:

> если вы специально делаете так, что у вас промышленные сервера и
> тестовые настроены по-разному - да, у вас проблема.
>
> 2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
> <eugene.peregudov at gmail.com> написал:
> > Коллега Juriy Strashnov опередил :)
> >
> > В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> > запрещающее действие SELinux не пройдет мимо audit.log, также можно
> > поставить setroubleshoot-server, который будет писать все происходящее в
> > messages.
> >
> > Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> > машинах:
> >
> > Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> > вырабатывается набор разрешающих правил еще на машине разработчика. На
> этом
> > этапе уже становится ясно в деталях какие дополнительные разрешения (с
> > поправкой на пути) необходимо применить администратору при деплое
> > приложения.
> >
> > Напротив, если разработка ведется без включенного селинукс, после деплоя
> > начинается многократный рефрен:
> > "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> > написание правил\установка правильных меток"
> > Причем, делать это приходится администратору порой без знания матчасти
> > самого приложения, что добавляет трудностей.
> >
> > Juriy Strashnov <juriy.foboss at gmail.com> писал(а) в своём письме Mon,
> 02 Feb
> > 2015 18:24:39 +0600:
> >
> > SELinux умеет объяснять, что делает. Однако получение этой информации
> > требует некоторых усилий. Например для вышеописанного случая с
> блокировкой
> > SSH диагностику можно провести так:
> >
> > grep sshd  /var/log/audit/audit.log | audit2why
> >
> > Получим сообщение:
> >
> > type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for
> pid=26463
> > comm="sshd" name="authorized_keys2" dev=dm-0 ino=1441809
> > scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> > tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> >
> > 2015-02-02 14:33 GMT+03:00 denis <denis at webmaster.spb.ru>:
> >>
> >> 28.01.2015 10:26, Eugene Peregudov пишет:
> >>>
> >>>
> >>> ИМХО, очень зря решается выключением. В первую очередь разработчик
> >>> приложения и мэйнтейнер должны знать и предоставить информацию о том,
> какие
> >>> разрешения необходимы приложению для корректного выполнения, а в
> идеале еще
> >>> и написать policy-файл.
> >>>
> >>> Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh
> >>> (http://stopdisablingselinux.com/)
> >>>
> >> До тех пор, пока оно будет включено по умолчанию - все инструкции будут
> >> начинаться с "выключите selinux", потому что обычно настройка делается
> так -
> >> селинух выкл или в permissive, нормальная настройка всего что запускаем
> и
> >> разворачиваем, а потом уже смотрим по результату, какие права нужны.
> >> Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",
> >> первым шагом диагностики всегда будет его отключение. Это как при
> сетевой
> >> мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу
> >> становится понятно, кто виноват.
> >> До кучи - рабочим и тестовым машинам selinux больше мешает чем
> помогает, и
> >> там выключить совсем - нормальное действие.
> >>
> >> Из самого банального: ssh, авторизация по ключам, .ssh создан, права
> 0700,
> >> authorized_keys создан, права 0600, все владельцы правильные. Ключ не
> >> принимало, пока не выключили selinux (!). В логах ничего про то, что
> >> выполнена блокировка селинухом. Итог: я тоже приучился первым делом
> >> выключать это зло, пока оно не научится само и внятно говорить, что не
> так.
> >>
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> >
> > --
> > Best regards, Juriy Strashnov
> >
> > Mob. +7 (953) 742-1550
> > E-mail: j.strashnov at me.com
> >
> > Please consider the environment before printing this email.
> >
> >
> >
> >
> > --
> > With best regards, Eugene JONIK Peregudov
> > mailto: eugene.peregudov at gmail.com
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150203/c6303a79/attachment-0001.html>