Идет инициализация! Разбираем плюсы и минусы init-систем для Linux

Сис­тема ини­циали­зации — это про­цесс с PID 1, который запус­кает все осталь­ное в Linux. Если она нас­тро­ена неп­равиль­но, это может открыть две­ри для атак или усложнить вос­ста­нов­ление пос­ле сбоя. Нап­ример, в 2018 году уяз­вимость CVE-2018-15686 в systemd поз­воляла зло­умыш­ленни­ку с локаль­ным дос­тупом получить root-пра­ва через ошиб­ку в обра­бот­ке сооб­щений D-Bus. Такие проб­лемы показы­вают, что выбор и нас­трой­ка init-сис­темы нап­рямую вли­яют на безопас­ность. Понима­ние того, как раз­ные сис­темы работа­ют и защища­ются, помога­ет миними­зиро­вать рис­ки и упростить аудит.

Systemd: возможности и риски

Systemd — эко­сис­тема, исполь­зуемая в Ubuntu, RHEL, Debian. Она управля­ет мно­жес­твом внут­ренних механиз­мов в этих сис­темах. Под­дер­жка cgroups v2, namespaces и resolved поз­воля­ет изо­лиро­вать про­цес­сы и ресур­сы, что дела­ет systemd популяр­ным инс­тру­мен­том для DevSecOps, но слож­ность это­го инс­тру­мен­та уве­личи­вает повер­хность ата­ки. Слож­ность всег­да соз­дает допол­нитель­ные рис­ки!

Да­вай раз­берем, что уме­ет systemd и как ее обе­зопа­сить.

Безопасность

Systemd — это не прос­то механизм ини­циали­зации, а целая эко­сис­тема, которая управля­ет служ­бами, сетью, логиро­вани­ем и даже кон­тей­нерами. Она сто­ит по умол­чанию в Ubuntu, RHEL, Debian и дру­гих популяр­ных дис­три­бути­вах, но ее слож­ность вызыва­ет спо­ры. Давай раз­берем, что она уме­ет и как ее обе­зопа­сить.

Systemd работа­ет с юни­тами — кон­фигура­цион­ными фай­лами, которые зада­ют, как запус­кать служ­бы (.service), сокеты (.socket), тай­меры (.timer) или точ­ки мон­тирова­ния (.mount). Нап­ример, файл nginx.service опре­деля­ет, как под­нять веб‑сер­вер, его зависи­мос­ти и огра­ниче­ния. Сре­ди ком­понен­тов — systemd-journald для бинар­ного логиро­вания (аль­тер­натива rsyslog), systemd-networkd и resolved для управле­ния сетью и DNS, logind для кон­тро­ля поль­зователь­ских сес­сий и systemd-nspawn для лег­кой кон­тей­нериза­ции.

Для безопас­ности systemd пред­лага­ет механиз­мы огра­ниче­ния при­виле­гий, которые про­ще, чем нас­трой­ка seccomp или POSIX-капаби­лити.

• NoNewPrivileges=yes бло­киру­ет повыше­ние при­виле­гий, даже при экс­плу­ата­ции уяз­вимос­тей.
• PrivateTmp=yes изо­лиру­ет /tmp, что­бы служ­ба не читала чужие фай­лы.
• ProtectSystem=full дела­ет катало­ги /usr, /boot и /etc дос­тупны­ми толь­ко для чте­ния.
• ReadWritePaths раз­реша­ет запись толь­ко в ука­зан­ные дирек­тории, нап­ример /var/log/nginx.
• CapabilityBoundingSet огра­ничи­вает capabilities — воз­можнос­ти про­цес­сов выпол­нять те или иные дей­ствия.
• RestrictAddressFamilies раз­реша­ет толь­ко нуж­ные про­токо­лы, такие как AF_INET и AF_INET6.
• MemoryDenyWriteExecute=yes защища­ет от инъ­екции кода в про­цес­сы.
• PrivateDevices=yes огра­ничи­вает дос­туп к /dev.

Вот при­мер безопас­ной кон­фигура­ции для Nginx в /etc/systemd/system/secure-nginx.service:

Эта кон­фигура­ция запус­кает nginx от име­ни неп­ривиле­гиро­ван­ного поль­зовате­ля, огра­ничи­вает его воз­можнос­ти, изо­лиру­ет /tmp, /home и сис­темные дирек­тории, раз­реша­ет толь­ко IPv4/IPv6 и бло­киру­ет выпол­нение кода из памяти. Коман­да systemd-analyze security secure-nginx.service покажет оцен­ку уяз­вимос­тей и пред­ложит улуч­шения.

Но у systemd есть и рис­ки. Уяз­вимос­ти, такие как CVE-2018-15686, показы­вают, что слож­ность сис­темы соз­дает потен­циаль­ные век­торы атак. Бинар­ные логи journald слож­нее ана­лизи­ровать без journalctl, что может зат­руднить аудит.