Главное правило DAC построения безопасной ОС.

Каждому регистрату на ЛОРе с нуля все азы безопасности Юникс объяснять? Ладно, только для тебя, как пятизвездочного двоечника, еще раз объясняю.

Претензия к обеспечению требований дискретного контроля доступа (DAC) в Linux с systemd и elogind!

DAC в Linux реализован с помощью флагов: R-чтение, W-изменение, Х-исполнение.

Главное правило построения безопасной OS в модели безопасности DAC - гарантировано обеспечить, чтобы все, что исполняется не изменялось (RX), а все что изменяется не исполнялось (RW). Выделение ЛЮБОЙ памяти в режиме для исполнения и изменения одновременно (WX) - категорически запрещено!!!

systemd и elogind написаны так, что монтируют постоянную память в режиме RXW - создают области доступные одновременно для исполнения и изменения. Это противоречит главному правилу безопасности в модели DAC.

Аргумент мы всю безопасность контролируем мандатным контролем доступа (MAC) неприемлем. Инструкция DoD US от 1983г., разсекречена в 1986г. как «Оранжевая книга» обязательно требует соблюдения ВСЕХ требований DAC (уровень C) перед внедрением MAC (уровень B).

Для проверки дыры в вашей системе выполните:

[code] mount |grep rw |grep -v noexec [/code]

Выведет список файловых систем доступных для изменения и исполнения одновременно. Согласно главного правила построения безопасных OS этот список должен быть пуст! А в системах с systemd, elogind он не пуст!!!

ты выше написал хрень…

так как если ты в арчике захолдить свою системдю, то получшить при обновлении в итоге тыкву, если захолдишь правленный инит скрипт - все будет работать…

Выделение ЛЮБОЙ памяти в режиме для исполнения и изменения одновременно (WX) - категорически запрещено!!!

Категорически запрещено кем?

systemd и elogind написаны так, что монтируют постоянную память в режиме RXW - создают области доступные одновременно для исполнения и изменения. Это противоречит главному правилу безопасности в модели DAC.

Любой современный серверный дистрибутив Linux по умолчанию ведёт себя именно так. В том числе те, которые не основаны на systemd.

Выведет список файловых систем доступных для изменения и исполнения одновременно. Согласно главного правила построения безопасных OS этот список должен быть пуст! А в системах с systemd, elogind он не пуст!!!

Ни systemd, ни logind не мешают тебе поправить fstab и сделать так, чтобы этого не происходило.

Следовательно, systemd не мешает соблюдению этого правила, а в том, что оно не соблюдается по умолчанию, вины systemd нет (в популярных серверных дистрибутивах оно не соблюдалось никогда, в т. ч. до systemd).

получшить при обновлении в итоге тыкву

Нет, конечно.

Я неоднократно так делал, когда дописывал systemd и у меня не было времени портировать свои патчи на новую версию.

целую неделю?

ну тогда конечно…

а ты годик отсиди…

а ты годик отсиди

А ты не боишься, что я вот сейчас возьму и проверю твой бред?

У нас тут в арче есть такая прикольная штука, как ALA. Я только что откатился на systemd 239.370-1 ровно годовой давности (2018-12-29 в репах арча была именно эта версия). Ничего не отвалилось. ЧЯДНТ?

ЧЯДНТ?

CVE-2019-6454

CVE-2018-16864

CVE-2018-16865

CVE-2018-15688

CVE-2018-15687

Мальчик тебе уже все разжевали. Запрещено при создании безопасной ОС.

Современная Gentoo так себя не ведет.

Без fstab не работает systemd? Это очень печально, но всякие System V дистрибутивы держат настройка в текстовом виде, а Systemd должна значит все хранить в бинарном виде и не обращать внимания на всякие fstab.

Ну я ещё раз повторю: аналогией IPsec в нашем вопросе будет написание init-системы с нуля. Я не спорю с тем, что линуксовый IPsec-стек гораздо гибче и OpenVPN, и SoftEther, и чего угодно ещё.

В чем отличие OpenRC от Systemd? (комментарий)

Мальчик тебе уже все разжевали.

Хамить будешь своим родителям.

Запрещено при создании безопасной ОС.

Запрещено что? Править fstab? :D

Без fstab не работает systemd?

Работает. И без fstab, и с fstab.

Systemd должна значит все хранить в бинарном виде и не обращать внимания на всякие fstab.

Как ни странно, это не так. Хватит гнать пургу.

Хватит прикидываться будто не понял. Дальше разговаривать с тобой никто не будет.

Очередной анонимус бесславно слился. Следующий!

Соседняя тема про softether

С каких пор стало модным сравнивать юзерспейс-творение джапа-шизоида с системой инициализации? Там абсолютно неадекватный код был с самого начал, еще и заточен под винду.

l2tp+isec

Рамки твоего познания сети не позволяют тебе что-либо решить легко. Я тебя умоляю, не начинай нам тут задвигать про L2TP поверх IPSec. Это показывает то насколько ты хорошо понимаешь и IPsec и сеть в целом.

Твоё сравнение некорректно трижды.

Если ты думаешь, что кто-то слился то ты ошибся. Никому не интересно общаться со «взрослым», который прикидывается, что не понял и ищет повод зацепиться за якобы оскорбления, когда все знают, что взрослые мужчины себя так не ведут. Слился тут как раз ты. Никому не хочется объяснять тем, кто застрял в 13-летнем возрасте очевидные вещи.

Найди себе работу

администратором системд?

Стадия первая: отрицание.

Блин точно. Правда же все равно сильнее и когда ею напирают надо же как-то хитро действовать и отрицать.

Рамки твоего познания сети не позволяют тебе что-либо решить легко.

Ну и ладно, трам-пам-пам. Буду решать «тяжело» на уровне моих «познаний».
PS Не подскажите что почитать, что бы мне стало решать «легко»?

intelfx снова удалил сообщение довольно большое. Есть надежда, что мозг все же включается, хоть его и плющит до того, что он с пеной у рта защищал поделие, служащее только интересам корпораций.

да он же проговорился - топит на системд, потому как хочет чтоб ему было где работать администратором системд….

Возможно вы меня не до конца поняли или я не правильно описал, простите.
Рассмотрим простой вариант. В наличии:
1. ovpn
2. ipsec + l2tp
Переходим к вопросу ТС той темы. Можно ли решить его задачу используя отдельно запущенные демоны? Ещё как можно. Несмотря на то, что ovpn так вообще userspace и однопоточный. Теперь смотрим на комбайн softether. Вроде все тоже самое, но решения видимо не предусмотрено из каробки.
Вот так же и с systemd, вроде все тоже самое, но что-то поправить в комбайне не всегда возможно.
Я это к чему, «хочу получить функционал который был у меня ранее, пусть и с изменениями конфигов и так далее» а мне говорят «извини, но вот не все можно сделать».
И ещё раз повторюсь, давно не «набрасываюсь» на системд, более или менее оно стало рабочим. Однако до идеала старых вариантов ещё далеко, поэтому не люблю.

Стадия первая: отрицание.

Отрицание, например, вот здесь: В чем отличие OpenRC от Systemd? (комментарий)

Так вот. Наглядная демонстрация того, что ugoday балабол.

$ systemctl --version
systemd 244 (244.1-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

$ /bin/du -b /usr/lib/systemd/* | sort -n | tail -n5
399312  /usr/lib/systemd/systemd-resolved
411488  /usr/lib/systemd/systemd-udevd
845720  /usr/lib/systemd/systemd-networkd
1546088 /usr/lib/systemd/systemd
2298088 /usr/lib/systemd/libsystemd-shared-244.so

Возьмём для примера самый жирный бинарник, не являющийся init’ом. Ведь если он самый жирный, то и вероятность того, что там затесалась какая-нибудь зависимость, тоже самая высокая?

$ sudo docker run -it --rm --privileged archlinux
Trying to pull docker.io/library/archlinux...
Getting image source signatures
Copying blob 94012c774717 done
Copying blob bb303f4daf31 done
Copying blob 611e91f2fbf8 done
Copying blob d71957b4d7f7 done
Copying blob c003ccab720b done
Copying config b389db977f done
Writing manifest to image destination
Storing signatures
[root@e0fcdf3b3973 /]# pgrep systemd
[root@e0fcdf3b3973 /]# mkdir /run/systemd
[root@e0fcdf3b3973 /]# /usr/lib/systemd/systemd-udevd --daemon
Starting version 243.51-1-arch
[root@e0fcdf3b3973 /]# udevadm trigger --action=add
[root@e0fcdf3b3973 /]# /usr/lib/systemd/systemd-networkd &
[1] 52
[root@e0fcdf3b3973 /]# eth0: Gained IPv6LL
Enumeration completed

[root@e0fcdf3b3973 /]# networkctl
IDX LINK TYPE     OPERATIONAL SETUP
  1 lo   loopback carrier     unmanaged
  3 eth0 ether    routable    unmanaged

2 links listed.

И о чудо, всё в порядке.

Так что, покажешь, где там бинарники, которые «без systemd не работают и systemd без них не работает»?

Также я бы хотел увидеть доказательство того, что таких гипотетических бинарников — большинство, ведь исходное заявление намекало именно на это. В любом случае одним или двумя бинарниками с взаимными зависимостями никого не удивишь, ведь это будет наоборот означать, что systemd (даже те его части, которые составляют единое целое) раздроблён по разным процессам и грамотно спроектирован, уменьшая риск падения всего сразу.

Это что? Демон работы с сетью? У нас такого нет, значит он ненужен. Резолвед тоже убрать надо. Удев заменить на evdev.

The open source input driver (x11-drivers/xf86-input-evdev) for many input devices like keyboards, mice, joysticks and more.

The short name of the Linux kernel’s event interface (CONFIG_INPUT_EVDEV), needed for libinput.

The input_devices_evdev USE flag.

Мне без разницы, что там нужно очередной анонимной тявкалке. Мы тут обсуждаем systemd.

Мы тут обсуждаем разницу в работе OpenRC и Systemd. Хватит бухать.

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

Я повторюсь ещё раз, надеюсь, в последний раз. Во-первых, задача из той темы решается в OVPN только потому, что разработчики OVPN предусмотрели соответствующую крутилку. Поэтому сравнение с OVPN некорректно (точнее, не некорректно, но бессмысленно). Во-вторых, я уверен, есть десятки кейсов, которые точно так же не решаются в IPsec, но решаются специализированным софтом (например, ядерными модулями), написанным для решения конкретно данной задачи.

А всё это я ровно к одному. При рассмотрении с «правильного» угла любой софт оказывается «комбайном» с кучей ограничений в самых неожиданных местах. У абсолютно любого софта есть ограничения, выше которых не прыгнешь.

Вернусь от аналогии с туннелями к нашей теме. Я ни разу не спорил с тем, что у systemd есть ограничения, открытые/нерешённые баги, WONTFIX’ы и так далее. Я спорю вот с этим:

1. Мне надо сделать A в sysV/bsdinit есть решение в любом случае.
2. Мне надо сделать A в systemd бывает что решения и нет. Ждите ответа.

Во-вторых, я уверен, есть десятки кейсов, которые точно так же не решаются в IPsec

Да ладно? Вы сегодня systemd что ли «перекурили»?

Комбайн это то, что делает несколько вещей одновременно. Но Система инициализации может заниматься именно инициализацией системы, а не рулить работой принтеров к примеру. Если человек выбрал OpenVPN это его выбор и он абсолютно правильно ждет, что программа сможет работать как ему хочется. Не так как этого хотят разработчики системд. Ручка чтобы писать и не важно шариковая или перьевая. И тут сторонники шариковых ручек доказывают, что шрифты, доступные только перьевым ручкам ненужны. А еще они считают, что ручкой можно консервы открывать и ручка должна уметь это делать. Но вместо того, чтобы показать зачем им именно шариковая ручка, которая по сути всего лишь форма для удерживания чернил они начинают рассказывать теорию материалов, ссылаться на сопротивление металлов. Показывают как лучше ручкой открывать консервы. Нам не нужны консервы. Нам нужна только инит система, которую можно ограничить только этим самым инитом и не дать ей ни во что вмешиваться. А ваши скрещивания ручки с швейцарским ножом никому не нужны.

Опять какая-то демагогия от анонимуса. Твои умозрительные рассуждения никому не интересны, ведь systemd (как система инициализации) занимается именно инициализацией системы, в то время как всё остальное сугубо опционально.

А что-то более внятное услышать можно?

А что-то более внятное услышать можно?

Скорее от Вас хотелось бы услышать на тему десятки кейсов

я уверен, есть десятки кейсов, которые точно так же не решаются в IPsec

Вы пишите, что я уверен ну накиньте хоть что-то для «уверенности».

хотелось бы услышать, каким вообще боком openvpn и softether относятся к сравнению systemd и openrc.

Вот мне кажется, что никаким, и заикнувшийся об этом просто льет воду, потому что у него нет других аргументов.

Хорошее сравнение.

хотелось бы услышать, каким вообще боком openvpn и softether относятся к сравнению systemd и openrc.

Поднимитесь по ссылкам вверх, а не выдергивайте последнии комментарии «и сразу отвечай», тогда поймете.

Ты действительно настолько уверен, что IPsec бесконечно гибкий и позволяет решить вот просто любой юзкейс? :)

Нет, серьёзно. Да далеко ходить не надо.

Как насчёт rekeying по заданным кастомным условиям? И вот мы уже пишем плагин к strongswan.

Как насчёт выборочной маршрутизации между клиентами на основании сложных правил? И вот мы пишем ядерный модуль к netfilter.

И так далее.

Но, как я уже сказал, IPsec действительно очень гибкий. Сравнивать IPsec с sysvinit некорректно.

Абсолютно идиотское сравнение, к тому же ещё и фактически неверное.

Как насчёт rekeying по заданным кастомным условиям? И вот мы уже пишем плагин к strongswan.

Он единственный?

Как насчёт выборочной маршрутизации между клиентами на основании сложных правил? И вот мы пишем ядерный модуль к netfilter.

Давно пишем?

Но, как я уже сказал, IPsec действительно очень гибкий. Сравнивать IPsec с sysvinit некорректно.

Сколько раз повторять? Я не сравниваю ipsec с sysV. Я сравнил два комбайна softether и systemd оба являются комбайнами в отдельных областях, но оба так же могут не позволить выполнить то, что можно было выполнить без их «присутствия».

технических аргументов там нет, только аналогии и философские рассуждения, то есть - балабольство.

А потом кто-то удивляется, что все дистры без systemd на данный момент - галимая маргинальщина. Не считая разве что Alpine, но ЧСХ никто в этой теме его не упомянул.

Сколько раз повторять? Я не сравниваю ipsec с sysV. Я сравнил два комбайна softether и systemd оба являются комбайнами в отдельных областях, но оба так же могут не позволить выполнить то, что можно было выполнить без их «присутствия».

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

технических аргументов там нет, только аналогии и философские рассуждения, то есть - балабольство

+1

Ну вот. Мы пришли «к общему знаменателю». А то вы чего-то сильно только за ненужнод тут писали. Ведь у каждого топора есть свое «держало» и «ударяло». :)

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

Бога не трогай.

Не считая разве что Alpine, но ЧСХ никто в этой теме его не упомянул.

Православная уже была упомянута.

Я для особо одаренных объяснял что нужно от инит системы. Если системд не вмешивается, значит не тянет свой дбас и прочий мусор. Ведь можно запустить систему используя OpenRC и обеспечить работу, то есть подъем сервиса после падения силами runit. Сделать подобное силами системд нельзя. Значит системд хуже. Рассуждения филосовского уровня простым технарям непосильны, а потому максимум что вы можете это бежать. Потому что принципы Unix систем просты и понятны, но тоже относятся к философии. То, что вас двое доказывает лишь то, что вы оба не справились с ответом по существу зачем вам системд.

Дык Alpine, в отличие ото всяких диванов, шлакварей и прочих антиксов с артиксами, служит вполне определённым техническим целям, а не идеологическим. Задача была сделать дистр с малым футпринтом - настолько малым, что даже выбор libc стал иметь значение. И выбор пал на musl. Всё остальное - следствие, в том числе и отсутствие systemd в поставке.

Ну вот. Мы пришли «к общему знаменателю».

Правда? Непохоже.

А то вы чего-то сильно только за ненужнод тут писали.

Да, и продолжаю. Я всё ещё не согласен с твоим исходным заявлением, и никогда не буду согласен. Несмотря на то, что у systemd есть свои ограничения (а у кого их нет?), он всё равно во много раз мощнее sysvinit и любых других своих аналогов и предшественников. И аргумент «а вот есть кейс, который не решается в systemd, значит, systemd заведомо хуже» — ничтожен.

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

ты уже придумал как будешь CVE закрывать в захолденом пакете, где ты накостылял прямо в код?

Обновлюсь и солью свои правки с новой версией, конечно же.

В конце концов, в systemd есть множество других способов сделать даже то, что systemd действительно не умеет, без необходимости залезать в код ядра systemd. Написать drop-in, написать генератор, заменить конкретный модуль, обкостылить в скрипте, написать слушатель dbus…

А вот в sysvinit/openrc так нельзя: если у тебя возникла проблема, ты в 100% случаев полезешь в код. Потому что инитскрипты — это код. И ничего, кроме кода, там в принципе нет. И тебе потом придётся его мержить. Так что и здесь sysvinit (или openrc) начисто сливает systemd.

т.е. по факту ты предлагаешь админу патчить systemd при каждом обновлении :)