Изолируем демоны с systemd или «вам не нужен Docker для этого!»

[tyderh]

К сожалению, systemd (пока) не умеет работать с PID namespace, так что наш root-демон может убивать остальные программы, выполняющиеся из-под root.

Недавно открыл для себя классную штуку — firejail. Умеет не только это, но и все остальное, перечисленное в статье + сетевые ограничения.

[ValdikSS]

Да, про firejail я хочу написать следующую статью. Он очень мощный и отлично подходит, в том числе, для изоляции десктопных приложений.

[snp]

Осваиваю firejail, но что он творит с сетевыми неймспейсами?

Например запускаю для теста что-нибудь:

firejail --net=eth0 bash

Всё ок, сеть отдельно, IP адрес назначает отдельный. При этом:

# ip netns list
# ip netns identify 26957
#

Пусто!

[ValdikSS]

ip netns identify [PID] — Report network namespaces names for process

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.

Никто не говорил, что информацию о namespace нужно обязательно писать в /var/run/netns. Это, в общем-то, только ip так и делает, больше никто.

[snp]

Так как посмотреть-то извне контейнера? Пока нужна, в общем-то фича — посмотреть/поменять iptables изолированного процесса (внутри все пермишны порезаны).

[ValdikSS]

# ln -s /proc/PID/net/ns /var/run/netns/firejail
# ip netns exec firejail ip a

[ValdikSS]

Есть еще nsenter:

# nsenter -t PID -n

[snp]

Чуть иначе:

ln -s /proc/PID/ns/net /var/run/netns/firejail

но это то, что надо! Спасибо.

[rudenkovk]

Штука прекрасная, но скорее для admin-like или infrastructure-like процессов.

Тот же docker дает прекрасные и управляемые среды для публикации приложений, клонирования.

[ValdikSS]

Ну, если уж на то пошло, то в systemd есть свои средства для управления контейнерами, когда вам нужны именно контейнеры — systemd-run и machinectl.

[rudenkovk]

Само собой. Скорее тут вопрос, что будет менее затратно.

[ValdikSS]

systemd-nspawn*

[MrFrizzy]

Для не пользующих systemd есть готовые альтернативы. Упоминаемый выше firejail действительно хорош, но не единственный.
И большой тред в тему на hacker news.

[ValdikSS]

Ну, на самом деле, подобных вещей прямо дохрена. В этой статье я хотел использовать именно стандартные средства systemd, вторая, если кого-то заинтересует развитие темы, будет более общая.

Есть еще такая классная страничка-сборник всего, подобная той, ссылку на которую вы предоставили: doger.io

[MrFrizzy]

За ссылочку спасибо.
Если я не ошибаюсь, я с ее автором немного общался на реддите по поводу namespaces и python.
Он уже 3 проект переписывает с нуля…

[Disen]

Я очень удивляюсь, когда говоря о плюсах systemd забывают упомянуть его возможности изоляции демонов. А что самое интересное — очень многие админы просто не знают о такой полезной фиче.

[ValdikSS]

Спасибо, посмотрю.

[Botkin]

Проблема знаете в чём? В том, что большинство разработчиков заявляют: «Это надо разбираться, документацию читать / админов просить. А там раз раз и готово».

[evnuh]

Вопрос только — чья это проблема? Я всё же думаю, что systemd. За это многие и не любят его, что он такой сложный и многогранный. Но что делать, зато сколько возможностей)

[Botkin]

Проблема того, кто потом всё разгребает

[ValdikSS]

Ну, так-то демоны можно запускать и от имени пользователя, используя systemctl --user, и храня юниты в ~/.config/systemd/user/. Но, в целом, вы правы, тут горе от ума и нежелания читать документацию и осваивать новое. systemd очень многогранен, это и хорошо, и плохо, но я считаю, что это лучшее, что случалось с линуксом.

[JC_Piligrim]

Просто с докером методология «xy*k-xy*k и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.

> нежелания читать документацию и осваивать новое
А тут, думаю, информационная интоксикация. Когда этот монструозный systemd осваивать, когда каждую неделю — новый фреймворк, который обещает помочь ещё быстрее «xy*k-xy*k и в продакшн»? :)

[ValdikSS]

Так и каждый фреймворк нужно осваивать, а чтобы вообще дойти до его освоения, еще и выбрать нужно, что конкретно использовать!
Вон, полюбуйтесь, сколько средств для управления докером уже понаделали!
github.com/veggiemonk/awesome-docker#dev-tools
stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production

Для меня в этом разобраться заметно сложнее, чем в systemd, а я из systemd использую далеко не только саму init-систему.

[SirEdvin]

Просто с докером методология «xyk-xyk и в продакшн» намного проще реализуется и позволяет экономить на админах. В этом и для руководства и для разработчиков не first-class проектов есть серьёзное преимущество.

Просто у докера порог входа для разработчиков сводится в docker-compose up -d, например.

[mirrr]

Для большинства приложений и такого хватит с головой:

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 # добавляем в автозагрузку

[ValdikSS]

Нет, не хватит. Представьте, что у вас взломали такой сервис и получили возможность выполнения кода от пользователя user. Самое простое — они могут быстро, эффективно и достаточно долго (до тех пор, пока этого не заметят) перебирать пароль root, используя su, дампить памяти других процессов, запущенных от этого же пользователя (если приложение, например, использует fork, а взломать удалось только один из форков). Если вдруг у вас используется ядро с уязвимостью, позволяющее поднять привилегии, то их с большой вероятностью успешно поднимут.
Различные namespaces и ограничения capabilities, как минимум, сильно усложнят задачу.

В общем, если у вас сервис, который особо никому не нужен, то и так сойдет, но если у вас какой-нибудь Tor, который интересен и спецслужбам тоже, то этого явно недостаточно.

[mirrr]

В общем, если у вас сервис, который особо никому не нужен, то и так сойдет

Ну я же и написал — в большинстве случаев.

[Balek]

Разве эти задачи не должны решаться с помощью selinux? Буду очень признателен, если кто-нибудь объяснит, в чем разница между этими механизмами.

[ValdikSS]

Эти задачи можно решить и с помощью selinux тоже, я думаю, но, вероятно, сложнее (я его ни разу всерьез не использовал).

[Balek]

Меня просто смутило, что мы даем приложению возможность открывать любой порт, а не только тот, который ему нужен. Мне кажется, что selinux гибче, но я им не пользовался вообще.

[MrFrizzy]

Я apparmor для ограничения skype использовал — в целом, интересная штука.
Но нюанс в том, что selinux\apparmor\etc нужно понимать и настраивать по типу «что не разрешено — запрещено». А это значит, что нужно хорошо понимать ту программу, которую запускаешь.
Контейнер же создать гораздо проще — прописал ограничения и используй себе…
В идеале нужно использовать и то, и то. И большинство песочниц используют как ограничения cgroups & namespaces, так и capabilities & apparmor\selinux

[Disen]

Вы правы — SELinux создавался как раз именно для этих целей. SELinux — это FLASK. FLASK — это крупный проект, к которому очень плотно приложились специалисты одной небезызвестной организации. Он изначально разрабатывался с оглядкой на требования TCSEC, поэтому на выходе получился хоть и очень гибкий и секьюрный инструмент, но достаточно запутанный для неподготовленного админа. Конечно, над его юзабилити непрерывно работают и настроить его под типовое применение с targerted policy не сложнее AppArmor или того же systemd (я про возможности изоляции), однако, если Вам вдруг захочется MLS\MCS — добро пожаловать в чудный мир SELinux. Мир, в котором без бутылки не разберешься :)

А вообще штука хорошая, да. И с ним стоит подружиться.

[nagibat0r]

Довольно интересная статья, спасибо. Попробую завтра реализовать