>Поэтому не могли бы вы пояснить - чего все так про него орут в контексте новости о
>повышении прав из-за дырки в ядре? Есть какая-то уверенность что с selinux дырку с
>повышением прав поюзать не удастся? А откуда она проистекает?Пояснять не вижу смысла, так как я уже говорил что в ситуации когда получен root, selinux не поможет. Но почему-то Вы мне упорно пытаетесь навязать беседу в этом контексте. Корректно настроенная политика SELinux на системе должна обеспечивать выполнение программы в ее рамках, не давая приложению выполнить больше дозволенного. На этом все. Надеюсь Вы обдумаете сказанное и не будете навязывать искусственный разговор с противопоставлением SELinux и дырок с недостаточной фильтрацией входных параметров в сисколлах, которые позволяют овладеть uid=0.
>Хм... человек, который любому ИИ фору даст - и то вон ошибается. Как-то пока не видно
>прорыва, тем более что математику так просто не обманешь. Как максимум - придумали
>пилить одну большую задачу на независимые модули, уйдя хотя-бы от квадратичной сложности
>отладки (местами). Ну ядро и попилено на кучу относительно независимых частей.И то не
>все так просто - возникают проблемы на границе стыковки оных, etc. Полная валидация
>всего этого перебором всех параметров невозможна по причине дикого количества комбинаций.
Сегодня человек ИИ фору даст, а завтра - нет. Математику обманывать и не пондобится, так как случиться примерно то же самое что и ситуация с СТО и превышением скорости света. А полная валидация (брутфорс) параметров в принципе не нужна - а нужны нормальные методы разработки (существующие методы, как например объектная концепция, схожи с недоделанными свистелками).
>Если честно - я не вижу как SELinux может эффективно защитить в рассматриваемой ситуации
>(повышение прав из-за ошибки в ядре).
Вы опять про ситуацию с ошибками в ядре. SELinux не для этого создавался. Зачем только Вы смешиваете все время SELinux и ошибки в ядре? Вы пишете как будто я говорил про то что SELinux защищает от ошибок в ядре. Я такое не писал а писал лишь только то что SELinux и его политика снижает потенциальные риски (и только в рамках своего контекста безопасности - тогда как вы мне приводите все время случай с эскалацией привелегии).
>[оверквотинг удален]
>систему на хосте, только саму песочницу (что несколько отличается от SELinux в лучшую
>сторону, пожалуй). Потенциальная проблема которая остается в этом случае - это если
>атака на сискол позволяет выполнить код в ядре. Так хакер может прорваться и из
>контейнера в хост-систему. Если и от такого надо защититься - логично смотреть на полные
>виртуализаторы. Тем более что KVM в ядро встроен (что впрочем как достоинство так и
>недостаток одновременно, xen для параноиков получше будет). Кстати а чему противоречит
>запуск контейнера/виртуалки которые на хосте еще до кучи огорожены и SELinux'ом так или
>иначе? Тот же LXC - по сути вызов обычного clone() с хитрыми параметрами, указывающими
>ему что мы хотим отдельные неймспейсы и свой загончик. А почему SELinux перестанет
>действовать на это? И перестанет ли, собственно?
Еще раз пишу что контейнеры/виртуалки и SELinux/AppArmor как бы разного уровня решения. SELinux/AppArmor может работать внутри контейнера/виртуалки но не наоборот, поэтому их сравнивать несколько неуместно. Обдумайте еще раз написанное.
>Удобство выходит боком когда встает вопрос о безопасности. Иногда ну вот натурально надо
>секурный туннель и ничего больше. А оно тут такой швейцарский нож с 120 лезвиями. Да
>блин! В секурити хорошо когда все просто и понятно, а такой пепелац обкусить до
>состояния только секурного туннеля - надо _сильно_ попотеть. Хотя по идее должно бы быть
>наоборот.
Для это и существуют стандартные политики.
