Pull to refresh

Comments 20

«Обилие» комментариев может говорить о двух вещах:
— Эта тема никому не интересна
— Из материала все настолько ясно, что и добавить нечего.

Я планировал написать еще несколько статей на эту тему, поправьте меня, если я зря это делаю :)

Тема selinux интересна (хотя мне пока более интересна ваша прошлая статья), материала на русском по selinux довольно мало, так что пишите дальше.


Для меня пока может оказаться актуальным завернуть некоторые сервисы, но полноценный rbac мне пока не нужен.


А какие ещё темы вы собирались осветить?

— Настройка базовой refpolicy на примере LAMP ( booleans, contexts, etc )
— Читшит по макросам refpolicy ( самому надо :) )
— Возможно — внедрение MLS/MCS, но это уже больше для банков и прочих военных.
Хотелось бы про — внедрение 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 и курим что он делал и что из этого ему реально надо.

Для этого надо иметь тесты, которые покроют полную функциональность, чтоб в продакшене не стрельнуло. Отыскать список необходимых сошников для apache и положить их в контейнер несколько проще.

Помимо подчас ненужного оверхеда и сложных конфигураций, есть простой вопрос: зачем?
Зачем тот-же LAMP засовывать в контейнеры ( причем еще каждый компонент в свой ), когда можно просто настроить контексты за 10 минут и спать спокойно?

Это проще и легко повторимо (через сборку контейнеров), в отличии от контекстов.

Если мы говорим про повторимость — то все вообще делает паппет/ансибл/чиф.

Ой, нет. Не делают они это. Как раз папет и ансибл моя прямая обязанность нынче. Поверть мне, если вы начали использовать такие вещи, то значит вы уперлись в некую безнадегу. Если есть возможность запакетировать в rpm, docker или ещё какой-нибудь статический вид, то без сомнения делайте это. Если ваша программа может использовать некую онлайн базу конфигурации (etcd, ldap, mysql), то делайте это, не используйте паппет с хиерой. Вообще никогда не используйте паппет. Не при каких обстоятельствах, а ансибл там где без него никак не обойтись (например обновление, оркестрирование некими переходными процессами ну и прочие процедуры без внутренних состояний).

Зависит от маштабов. Тот-же селинукс я прекрасно заворачиваю в паппет и раскидываю по тысячам серверов. И все отлично работает :)

Да ладно отлично. Никогда не сталкивались с проблемой обеспечения идемпотентонсти в папет модулях? Или проблематике переходного процесса с разными состояниями одного объекта, когда нельзя задать цепочку service stop -> package update -> service start (обходные пути есть, это самый популярный вопрос по папет на стаковерфлоу)? Или проблема многократного запуска, когда невозможно в один проход получить все факты о системе (софт А генерирует уникальные ID, которые надо отдать софту B на другом сервере). А логирование ошибок как вам, особенно когда она где-то глубоко в ruby коде, который написан третьей стороной?


Короче мне тут на любимую мазоль наступили, которая на целую статью потянет наверное, но писать её боюсь (срача много, толку мало).

Сталкивались. Приходите к нам работать — научим :)

"Ой! Ну вас, Василий Иваныч! Всё-то вы только обещаете." Я никогда не видел хорошего специалиста по паппет. Видел много людей, которые думают, что они хорошие специалисты, но это не так.

И да, часть этих проблем решает puppet4 :)
А статью кстати напишите. Дискуссия поможет найти истину :)
Очень интересно и нужно. IMHO это реально хороший how-to, даже на английском я не видел такого качественного руководства, где нет лишнего и всё понятно.
Я только сегодня получил вашу статью в рассылке
Sign up to leave a comment.

Articles