>>> При наличии локального Shell разные дополнительные надстройки типа
>>> SELinux и AppArrmor мало помогают
>> Про апп-армор не скажу, а про СЕ советую его для начала поманить
>> ...
> Во первых, на kernel.org была Fedora с SELinux. Во вторых, покажите
> мне хоть один дистрибутив с залоченным SELinux shell-ом. В том то
> и проблема, что какой-нибудь Firefox зажмут, а войдя по ssh можно
> что угодно делать.Огораживать ФФ есть очень большой смысл. 1) ФФ (и вообще -- браузер) -- довольно сложная программа, безошибочность которой сложно гарантировать 2) причём, если, например, ошибки/уязвимости в ядре касаются всей системы, и поэтому тщательно выискиваются и устраняются (да и то, как мы видим, лишь с относительным успехом), то ошибки/уязвимости браузера касаются только конкретного бесправного юзера и устраняются не столь ревностно; частично устранение ошибок заменяется носкриптами и заклинаниями типа: "нефик по порносайтам лазить" 3) ФФ по определению должен работать с кодом, который пользователь не контролирует; этот код не должен получить доступ к данным пользователя, даже если он вырвется из контекста браузера 4) в то же время ФФ незачем иметь доступ к данным пользователя (кроме сохранения файлов и доступа к своим настройкам) и тогда, когда ФФ нормально функционирует и исполняет легитимный код 5) поэтому, с одной стороны, ФФ легко огородить, не нанося ущерба его нормальному функционированию, с другой стороны, такое огораживание полезно на случай наличия уязвимости в ФФ, а с третьей стороны, оно легко и эффективно реализуется тем же селинуксом (если система в целом не взломана).
Огораживание шелла бессмысленно по определению. Точнее, шелл исполняется в контексте пользователя и уже этим огорожен по отношению к системе в целом. Внутри же контекста пользователя шелл по определению должен быть полноправным.
Но даже если огородить шелл селинуксом, проблему это не решило бы. Проблема в том, что иногда программы, запущенные в контексте пользователя (унаследовав этот контекст от шелла), меняют контекст на рутовый. Это уязвимость в чистом виде, в ядре, или в какой-то из сетуидных программ, или ещё где-то, пока что господа с кернел.орг ничего нам об этом не рассказали. Как этому может помешать селинукс? Селинукс, следуя своим политикам, запретит шеллу/программе-эксплойту перейти в контекст рута? Так это и без селинукса должно быть запрещено. Классическая юниксовая система контроля доступа принимает решение раньше, чем происходит обращение к селинуксу. Если решение отрицательное, то обращения к селинуксу просто не будет. Так что у селинукса просто не будет случая встать на защиту системы.
