Комментарии 34
К сожалению, systemd (пока) не умеет работать с PID namespace, так что наш root-демон может убивать остальные программы, выполняющиеся из-под root.
Недавно открыл для себя классную штуку — firejail. Умеет не только это, но и все остальное, перечисленное в статье + сетевые ограничения.
Да, про firejail я хочу написать следующую статью. Он очень мощный и отлично подходит, в том числе, для изоляции десктопных приложений.
Осваиваю firejail, но что он творит с сетевыми неймспейсами?
Например запускаю для теста что-нибудь:
Всё ок, сеть отдельно, IP адрес назначает отдельный. При этом:
Пусто!
Например запускаю для теста что-нибудь:
firejail --net=eth0 bashВсё ок, сеть отдельно, IP адрес назначает отдельный. При этом:
# ip netns list
# ip netns identify 26957
#
Пусто!
ip netns identify [PID] — Report network namespaces names for processНикто не говорил, что информацию о namespace нужно обязательно писать в /var/run/netns. Это, в общем-то, только ip так и делает, больше никто.
This command walks through /var/run/netns and finds all the network namespace names for network namespace of the specified
process, if PID is not specified then the current process will be used.
Штука прекрасная, но скорее для admin-like или infrastructure-like процессов.
Тот же docker дает прекрасные и управляемые среды для публикации приложений, клонирования.
Тот же docker дает прекрасные и управляемые среды для публикации приложений, клонирования.
Для не пользующих systemd есть готовые альтернативы. Упоминаемый выше firejail действительно хорош, но не единственный.
И большой тред в тему на hacker news.
И большой тред в тему на hacker news.
Ну, на самом деле, подобных вещей прямо дохрена. В этой статье я хотел использовать именно стандартные средства systemd, вторая, если кого-то заинтересует развитие темы, будет более общая.
Есть еще такая классная страничка-сборник всего, подобная той, ссылку на которую вы предоставили: doger.io
Есть еще такая классная страничка-сборник всего, подобная той, ссылку на которую вы предоставили: doger.io
Я очень удивляюсь, когда говоря о плюсах systemd забывают упомянуть его возможности изоляции демонов. А что самое интересное — очень многие админы просто не знают о такой полезной фиче.
НЛО прилетело и опубликовало эту надпись здесь
Проблема знаете в чём? В том, что большинство разработчиков заявляют: «Это надо разбираться, документацию читать / админов просить. А там раз раз и готово».
Вопрос только — чья это проблема? Я всё же думаю, что systemd. За это многие и не любят его, что он такой сложный и многогранный. Но что делать, зато сколько возможностей)
Ну, так-то демоны можно запускать и от имени пользователя, используя systemctl --user, и храня юниты в ~/.config/systemd/user/. Но, в целом, вы правы, тут горе от ума и нежелания читать документацию и осваивать новое. systemd очень многогранен, это и хорошо, и плохо, но я считаю, что это лучшее, что случалось с линуксом.
Просто с докером методология «xy*k-xy*k и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.
> нежелания читать документацию и осваивать новое
А тут, думаю, информационная интоксикация. Когда этот монструозный systemd осваивать, когда каждую неделю — новый фреймворк, который обещает помочь ещё быстрее «xy*k-xy*k и в продакшн»? :)
> нежелания читать документацию и осваивать новое
А тут, думаю, информационная интоксикация. Когда этот монструозный systemd осваивать, когда каждую неделю — новый фреймворк, который обещает помочь ещё быстрее «xy*k-xy*k и в продакшн»? :)
Так и каждый фреймворк нужно осваивать, а чтобы вообще дойти до его освоения, еще и выбрать нужно, что конкретно использовать!
Вон, полюбуйтесь, сколько средств для управления докером уже понаделали!
github.com/veggiemonk/awesome-docker#dev-tools
stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production
Для меня в этом разобраться заметно сложнее, чем в systemd, а я из systemd использую далеко не только саму init-систему.
Вон, полюбуйтесь, сколько средств для управления докером уже понаделали!
github.com/veggiemonk/awesome-docker#dev-tools
stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production
Для меня в этом разобраться заметно сложнее, чем в systemd, а я из systemd использую далеко не только саму init-систему.
Просто с докером методология «xyk-xyk и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.
Просто у докера порог входа для разработчиков сводится в docker-compose up -d, например.
Для большинства приложений и такого хватит с головой:
/usr/lib/systemd/system/my-app.service:
Это практически все, можно управлять этим сервисом:
useradd -s /bin/bash user
passwd user
/usr/lib/systemd/system/my-app.service:
[Unit]
Description=<Описание>
[Service]
Restart=always
EnvironmentFile=-/home/user/env.txt
WorkingDirectory=/home/user/app
ExecStart=/home/user/app/myexe
LimitNOFILE=131072
LimitNPROC=131072
User=user
Group=user
[Install]
WantedBy=multi-user.target
Это практически все, можно управлять этим сервисом:
systemctl start my-app
systemctl enable my-app # добавляем в автозагрузку
Нет, не хватит. Представьте, что у вас взломали такой сервис и получили возможность выполнения кода от пользователя user. Самое простое — они могут быстро, эффективно и достаточно долго (до тех пор, пока этого не заметят) перебирать пароль root, используя su, дампить памяти других процессов, запущенных от этого же пользователя (если приложение, например, использует fork, а взломать удалось только один из форков). Если вдруг у вас используется ядро с уязвимостью, позволяющее поднять привилегии, то их с большой вероятностью успешно поднимут.
Различные namespaces и ограничения capabilities, как минимум, сильно усложнят задачу.
В общем, если у вас сервис, который особо никому не нужен, то и так сойдет, но если у вас какой-нибудь Tor, который интересен и спецслужбам тоже, то этого явно недостаточно.
Различные namespaces и ограничения capabilities, как минимум, сильно усложнят задачу.
В общем, если у вас сервис, который особо никому не нужен, то и так сойдет, но если у вас какой-нибудь Tor, который интересен и спецслужбам тоже, то этого явно недостаточно.
Разве эти задачи не должны решаться с помощью selinux? Буду очень признателен, если кто-нибудь объяснит, в чем разница между этими механизмами.
Эти задачи можно решить и с помощью selinux тоже, я думаю, но, вероятно, сложнее (я его ни разу всерьез не использовал).
Я apparmor для ограничения skype использовал — в целом, интересная штука.
Но нюанс в том, что selinux\apparmor\etc нужно понимать и настраивать по типу «что не разрешено — запрещено». А это значит, что нужно хорошо понимать ту программу, которую запускаешь.
Контейнер же создать гораздо проще — прописал ограничения и используй себе…
В идеале нужно использовать и то, и то. И большинство песочниц используют как ограничения cgroups & namespaces, так и capabilities & apparmor\selinux
Но нюанс в том, что selinux\apparmor\etc нужно понимать и настраивать по типу «что не разрешено — запрещено». А это значит, что нужно хорошо понимать ту программу, которую запускаешь.
Контейнер же создать гораздо проще — прописал ограничения и используй себе…
В идеале нужно использовать и то, и то. И большинство песочниц используют как ограничения cgroups & namespaces, так и capabilities & apparmor\selinux
Вы правы — SELinux создавался как раз именно для этих целей. SELinux — это FLASK. FLASK — это крупный проект, к которому очень плотно приложились специалисты одной небезызвестной организации. Он изначально разрабатывался с оглядкой на требования TCSEC, поэтому на выходе получился хоть и очень гибкий и секьюрный инструмент, но достаточно запутанный для неподготовленного админа. Конечно, над его юзабилити непрерывно работают и настроить его под типовое применение с targerted policy не сложнее AppArmor или того же systemd (я про возможности изоляции), однако, если Вам вдруг захочется MLS\MCS — добро пожаловать в чудный мир SELinux. Мир, в котором без бутылки не разберешься :)
А вообще штука хорошая, да. И с ним стоит подружиться.
А вообще штука хорошая, да. И с ним стоит подружиться.
Довольно интересная статья, спасибо. Попробую завтра реализовать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изолируем демоны с systemd или «вам не нужен Docker для этого!»