Comments 20
— Эта тема никому не интересна
— Из материала все настолько ясно, что и добавить нечего.
Я планировал написать еще несколько статей на эту тему, поправьте меня, если я зря это делаю :)
Тема selinux интересна (хотя мне пока более интересна ваша прошлая статья), материала на русском по selinux довольно мало, так что пишите дальше.
Для меня пока может оказаться актуальным завернуть некоторые сервисы, но полноценный rbac мне пока не нужен.
А какие ещё темы вы собирались осветить?
— Читшит по макросам refpolicy ( самому надо :) )
— Возможно — внедрение MLS/MCS, но это уже больше для банков и прочих военных.
"Некоторые сервисы" гораздо проще оборачивать в правильно собранные контейнеры. Это даст довольно высокую защиту от эксплуатации удаленных уязвимостей (банально запрет изменения fs контейнера, отсутствие лишних исполнимых файлов и т.д.)
SELinux это впервую очередь rbac, который нужен очень мало кому и широко он распространнен не на серверах, а на телефонах с Android.
"Некоторые сервисы" гораздо проще оборачивать в правильно собранные контейнеры. Это даст довольно высокую защиту от эксплуатации удаленных уязвимостей (банально запрет изменения fs контейнера, отсутствие лишних исполнимых файлов и т.д.)
Если приложение не легкий сервис на golang, то правильно его упаковать в контейнер не оставив лишних бинарников может быть крайне нетривиальной задачей. Хотя базово сейчас можно соблюдать элементарную гигиену типа запуска сервиса под пользователем, private tmp, явного определение rw/ro/inaccessible путей (соответственно используется filesystem ns) декларативно при использовании systemd. Всякие вещи типа зарезания capabilities и seccomp вполне доступны через тот systemd, но требует уже гораздо количества геморроя, если сервису надо стартовать не под непривилегерованным пользователем.
Если приложение не легкий сервис на golang, то правильно его упаковать в контейнер не оставив лишних бинарников может быть крайне нетривиальной задачей.
Да это так. Но мне кажется, что эта проблема сопоставима со сложностью написания качественных конфигов SELinux.
В не-идеальном — semanage permissive -a, sleep 86400, audit2allow -b -t software_t и курим что он делал и что из этого ему реально надо.
Зачем тот-же LAMP засовывать в контейнеры ( причем еще каждый компонент в свой ), когда можно просто настроить контексты за 10 минут и спать спокойно?
Это проще и легко повторимо (через сборку контейнеров), в отличии от контекстов.
Ой, нет. Не делают они это. Как раз папет и ансибл моя прямая обязанность нынче. Поверть мне, если вы начали использовать такие вещи, то значит вы уперлись в некую безнадегу. Если есть возможность запакетировать в rpm, docker или ещё какой-нибудь статический вид, то без сомнения делайте это. Если ваша программа может использовать некую онлайн базу конфигурации (etcd, ldap, mysql), то делайте это, не используйте паппет с хиерой. Вообще никогда не используйте паппет. Не при каких обстоятельствах, а ансибл там где без него никак не обойтись (например обновление, оркестрирование некими переходными процессами ну и прочие процедуры без внутренних состояний).
Да ладно отлично. Никогда не сталкивались с проблемой обеспечения идемпотентонсти в папет модулях? Или проблематике переходного процесса с разными состояниями одного объекта, когда нельзя задать цепочку service stop -> package update -> service start (обходные пути есть, это самый популярный вопрос по папет на стаковерфлоу)? Или проблема многократного запуска, когда невозможно в один проход получить все факты о системе (софт А генерирует уникальные ID, которые надо отдать софту B на другом сервере). А логирование ошибок как вам, особенно когда она где-то глубоко в ruby коде, который написан третьей стороной?
Короче мне тут на любимую мазоль наступили, которая на целую статью потянет наверное, но писать её боюсь (срача много, толку мало).
Я только сегодня получил вашу статью в рассылке
Разработка SELinux-модуля для пользователя