Comments 34
Да, про firejail я хочу написать следующую статью. Он очень мощный и отлично подходит, в том числе, для изоляции десктопных приложений.
+1
Осваиваю firejail, но что он творит с сетевыми неймспейсами?
Например запускаю для теста что-нибудь:
Всё ок, сеть отдельно, IP адрес назначает отдельный. При этом:
Пусто!
Например запускаю для теста что-нибудь:
firejail --net=eth0 bash
Всё ок, сеть отдельно, IP адрес назначает отдельный. При этом:
# ip netns list
# ip netns identify 26957
#
Пусто!
0
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.
0
Штука прекрасная, но скорее для admin-like или infrastructure-like процессов.
Тот же docker дает прекрасные и управляемые среды для публикации приложений, клонирования.
Тот же docker дает прекрасные и управляемые среды для публикации приложений, клонирования.
+1
Для не пользующих systemd есть готовые альтернативы. Упоминаемый выше firejail действительно хорош, но не единственный.
И большой тред в тему на hacker news.
И большой тред в тему на hacker news.
+2
Ну, на самом деле, подобных вещей прямо дохрена. В этой статье я хотел использовать именно стандартные средства systemd, вторая, если кого-то заинтересует развитие темы, будет более общая.
Есть еще такая классная страничка-сборник всего, подобная той, ссылку на которую вы предоставили: doger.io
Есть еще такая классная страничка-сборник всего, подобная той, ссылку на которую вы предоставили: doger.io
+5
Я очень удивляюсь, когда говоря о плюсах systemd забывают упомянуть его возможности изоляции демонов. А что самое интересное — очень многие админы просто не знают о такой полезной фиче.
+2
UFO just landed and posted this here
Проблема знаете в чём? В том, что большинство разработчиков заявляют: «Это надо разбираться, документацию читать / админов просить. А там раз раз и готово».
0
Вопрос только — чья это проблема? Я всё же думаю, что systemd. За это многие и не любят его, что он такой сложный и многогранный. Но что делать, зато сколько возможностей)
+1
Ну, так-то демоны можно запускать и от имени пользователя, используя systemctl --user, и храня юниты в ~/.config/systemd/user/. Но, в целом, вы правы, тут горе от ума и нежелания читать документацию и осваивать новое. systemd очень многогранен, это и хорошо, и плохо, но я считаю, что это лучшее, что случалось с линуксом.
+3
Просто с докером методология «xy*k-xy*k и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.
> нежелания читать документацию и осваивать новое
А тут, думаю, информационная интоксикация. Когда этот монструозный systemd осваивать, когда каждую неделю — новый фреймворк, который обещает помочь ещё быстрее «xy*k-xy*k и в продакшн»? :)
> нежелания читать документацию и осваивать новое
А тут, думаю, информационная интоксикация. Когда этот монструозный systemd осваивать, когда каждую неделю — новый фреймворк, который обещает помочь ещё быстрее «xy*k-xy*k и в продакшн»? :)
0
Так и каждый фреймворк нужно осваивать, а чтобы вообще дойти до его освоения, еще и выбрать нужно, что конкретно использовать!
Вон, полюбуйтесь, сколько средств для управления докером уже понаделали!
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-систему.
+1
Просто с докером методология «xyk-xyk и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.
Просто у докера порог входа для разработчиков сводится в docker-compose up -d
, например.
0
Для большинства приложений и такого хватит с головой:
/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 # добавляем в автозагрузку
+1
Нет, не хватит. Представьте, что у вас взломали такой сервис и получили возможность выполнения кода от пользователя user. Самое простое — они могут быстро, эффективно и достаточно долго (до тех пор, пока этого не заметят) перебирать пароль root, используя su, дампить памяти других процессов, запущенных от этого же пользователя (если приложение, например, использует fork, а взломать удалось только один из форков). Если вдруг у вас используется ядро с уязвимостью, позволяющее поднять привилегии, то их с большой вероятностью успешно поднимут.
Различные namespaces и ограничения capabilities, как минимум, сильно усложнят задачу.
В общем, если у вас сервис, который особо никому не нужен, то и так сойдет, но если у вас какой-нибудь Tor, который интересен и спецслужбам тоже, то этого явно недостаточно.
Различные namespaces и ограничения capabilities, как минимум, сильно усложнят задачу.
В общем, если у вас сервис, который особо никому не нужен, то и так сойдет, но если у вас какой-нибудь Tor, который интересен и спецслужбам тоже, то этого явно недостаточно.
+3
Разве эти задачи не должны решаться с помощью selinux? Буду очень признателен, если кто-нибудь объяснит, в чем разница между этими механизмами.
0
Эти задачи можно решить и с помощью selinux тоже, я думаю, но, вероятно, сложнее (я его ни разу всерьез не использовал).
0
Я apparmor для ограничения skype использовал — в целом, интересная штука.
Но нюанс в том, что selinux\apparmor\etc нужно понимать и настраивать по типу «что не разрешено — запрещено». А это значит, что нужно хорошо понимать ту программу, которую запускаешь.
Контейнер же создать гораздо проще — прописал ограничения и используй себе…
В идеале нужно использовать и то, и то. И большинство песочниц используют как ограничения cgroups & namespaces, так и capabilities & apparmor\selinux
Но нюанс в том, что selinux\apparmor\etc нужно понимать и настраивать по типу «что не разрешено — запрещено». А это значит, что нужно хорошо понимать ту программу, которую запускаешь.
Контейнер же создать гораздо проще — прописал ограничения и используй себе…
В идеале нужно использовать и то, и то. И большинство песочниц используют как ограничения cgroups & namespaces, так и capabilities & apparmor\selinux
+2
Вы правы — SELinux создавался как раз именно для этих целей. SELinux — это FLASK. FLASK — это крупный проект, к которому очень плотно приложились специалисты одной небезызвестной организации. Он изначально разрабатывался с оглядкой на требования TCSEC, поэтому на выходе получился хоть и очень гибкий и секьюрный инструмент, но достаточно запутанный для неподготовленного админа. Конечно, над его юзабилити непрерывно работают и настроить его под типовое применение с targerted policy не сложнее AppArmor или того же systemd (я про возможности изоляции), однако, если Вам вдруг захочется MLS\MCS — добро пожаловать в чудный мир SELinux. Мир, в котором без бутылки не разберешься :)
А вообще штука хорошая, да. И с ним стоит подружиться.
А вообще штука хорошая, да. И с ним стоит подружиться.
+2
Довольно интересная статья, спасибо. Попробую завтра реализовать
0
Sign up to leave a comment.
Изолируем демоны с systemd или «вам не нужен Docker для этого!»