SELinux. За и против.

Выбирай:
sudo -i
sudo -s

Круто. Еще два способа сделать то, что я и так умею.

Есть нюансы. Запусти env в каждом случае и посмотри какие переменные окружения есть и чему они равны. Хотя, это и не принципиально в большинстве случаев.

В основном используется политика targeted - т.е. ограничиваются только те приложения, для которых разработчики написали модули SELinux. А если разработчик забил на SELinux, как ты говоришь, то его приложение будет работать в домене unconfined, в котором разрешено почти все. Пример - БД Oracle - работает в unconfined и не жужжит.

Докручивать правила SELinux придется только если ты используешь приложение не так, как задумал разработчик. Например, повесил демона на нестандартный порт, положил DocumentRoot в нестандартное место, хомяк у пользователя лежит не в /home, и т.д. И это все делается тривиально - повесить контекст на порт/директорию, или выставить переменную SELinux, которую предусматривает разработчик.

Роли в SELinux - это второстепенный механизм, основной - это TE (type enforcement). Как пользователь/админ ты можешь вообще никогда не столкнуться с ролями. Если только будешь писать свои политики, да и то не всегда. Роли используются как связующее звено, в какие домены (types) можно переходить процессам. Роли на файлах - насколько я понимаю, просто пустышка.

Зачем все это нужно в свете затрачиваемых усилий - пока не работал с RHEL, тоже также думал. Потом в RHEL жизнь заставила.

Но все-таки приятно, когда находят дырку в sshd, и все рвут волосы на жопе, а RedHat говорит: если у вас SELinux, сидите спокойно.

Но все-таки приятно, когда находят дырку в sshd, и все рвут волосы на жопе, а RedHat говорит: если у вас SELinux, сидите спокойно.

[сарказм]«и радуйтесь» (с)[/сарказм]

Надеюсь в книжке написано примерно так: «если хотите иметь меньше проблем удалите в системе /bin/mv, сделайте неисполняемым, или замените алиасом из cp+rm»?

Нет, но там написано как переносить файлы без xattr.

Нет