systemd local DoS

монолитность надёжнее, т. к. она уменьшает количество стыков и «движущихся частей».

Если бы последователи Поттеринга делали корабли, то они, по всей видимости, приваривали бы спасательные шлюпки к корпусу.

Я ожидал услышать всё что угодно, но не такое.

замедляет выполнение

На сколько долей процента?

Повторяю вопрос в шестой раз: детально опиши архитектуру, которая уменьшит attack surface с сохранением возможностей, и укажи конкретные места, в которых она уменьшится.

Молодец, смешно (нет).

уменьшит attack surface с сохранением возможностей

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

Перечитай еще раз то, что я писал ранее:

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

Простой пример. Мне необходимы функции X, Y, Z. В случае хорошо написанных программ, которые делают только одно, и делают это хорошо, я просто составлю себе из этого набора программ то, что мне нужно F1 = { X, Y, Z }.

В случае с systemd я получу F2 = { X, Z, S, Y, S, T, E, M, D, I, S, C, R, A, P, W, A, R, E }.

Как ты думаешь, в каком случае поверхность атаки будет выше? F1 или F2?

S, Y, S, T, E, M, D, I, S, C, R, A, P, W, A, R, E

У тебя так мило припекает, продолжай.

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

А если я использую все (или почти все) возможности? Почему я должен увеличивать свою «поверхность атаки» за счёт того, что какому-то хейтеру захотелось труъ юниксъ модульности, и к совокупной сложности кода PID 1 systemd добавилась ещё сложность точек сопряжения?

И теперь ответь на вопрос: кому, кроме трёх с половиной лоровских теоретиков, потребуется выкидывать что-то из функциональности PID 1 systemd (которой там не так много)?

А причем тут PID 1 вообще? Речь идет о systemd в целом.

добавилась ещё сложность точек сопряжения?

И какая точка сопряжения добавится между демоном синхронизации времени и демоном инициализации?

кому потребуется выкидывать что-то из функциональности systemd

Скорее всего никому, потому что systemd проще не устанавливать. Как я, собственно, на hardened серверах и делаю.

Нет, на протяжении всего треда речь идёт только о PID 1, потому что всё остальное работает без рута и удовлетворяет названным тобой требованиям.

И какая точка сопряжения добавится

Никакой, потому что это две независимые программы (полностью).

Скорее всего никому, потому что systemd проще не устанавливать. Как я, собственно, на hardened серверах и делаю.

Как ты ухитряешься не устанавливать systemd в RHEL 7?

потому что всё остальное работает без рута

И это автоматически решает все проблемы безопасности? Так считать очень наивно.

Как ты ухитряешься не устанавливать systemd в RHEL 7?

Очень просто — там, где очень важна безопасность, использую Gentoo.

всё остальное работает без рута

мне кажется это не совсем верно

ps aux | grep systemd | grep root
root       261  0.0  0.1  77644 37644 ?        Ss   сен08   0:10 /usr/lib/systemd/systemd-journald
root       295  0.0  0.0  36088  3720 ?        Ss   сен08   0:02 /usr/lib/systemd/systemd-udevd
root       501  0.0  0.0  38516  3764 ?        Ss   сен08   0:02 /usr/lib/systemd/systemd-logind

systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

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

Gentoo

Security by obscurity? Эксперты говорят, что это отличный подход :)

Security by obscurity?

Нет. А почему ты так решил?

Я ожидал услышать всё что угодно, но не такое.

А вам, таким красивым, религия не позволяет проверить все ОДИН раз нормально и далее передавать всем желающим что-то типа «struct valid_unitname»? Заодно сразу с плюшками типа длины, позиций @, extension и т.д (что там еще нужно), вместо четырех-пятикратных повторных разборов этого несчастного имени-выражения.
А ведь еще можно забацать какой нибудь «unitname_modificator» тип, в котором (т.е. в одном месте) держать литералы и прочее нужное для работы. Но нет, конечно же лучше гордо кидаться указателями на char, проверять и парсить одно и то же по дюжине раз, используя куски копипасты …

Твоя правда. Есть бинарники, которые работают от рута. Но они не перестают быть опциональными.

Не договаривай за меня. Ты протестовал против отсутствия модульности в systemd, которое якобы заставляет тебя выполнять в своей системе ненужный код и таким образом увеличивать поверхность атаки. Я ответил, что это не так, поскольку почти (кроме udev) все компоненты systemd (по границам бинарников) отключаемы и взаимозаменяемы, а дробить на модули дальше (например, разбивать PID 1 на куски) нецелесообразно.

Слова про «не от рута» — не более чем примечание на полях (к тому же ещё и не совсем верное, см. выше).

Никакой, потому что это две независимые программы (полностью).

Тогда почему они вообще находятся в одном дереве исходников? Это же не ls и cat.

почти (кроме udev) все компоненты systemd (по границам бинарников) отключаемы и взаимозаменяемы

ШТО. udev вроде никто раньше не заставлял использовать. Это journald нельзя убрать совсем, не?

Тогда почему они вообще находятся в одном дереве исходников?

А почему stty, chown и tr находятся в одном дереве?

А почему stty, chown и tr находятся в одном дереве?

И ведь действительно, в чем причина того, что столь разнородные утилиты находятся в одном дереве?

Тогда почему они вообще находятся в одном дереве исходников?

Because we can.

With some greetings, Lennart Pottering.

Нет, поскольку systemd даже на момент своего создания умел больше и делал это лучше, чем любой аналог sysvinit. Так что появление systemd было оправданным.

Шли годы, а ученики из Хогвартса все еще повторяют как мантру то, что systemd был кому-то нужен, кроме red hat.

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

Обычный способ ведения бизнеса для капиталистов.

А почему ls и cat можно, а этим нельзя?

journald убрать можно (замаскировать сервис и сокет), хоть и говорят, что нельзя. Просто потеряешь все логи. А между systemd и udev сейчас внутренний интерфейс (не libudev), и я не уверен, что systemd перенесёт отсутствие udev.

Да, ещё systemd нужен как минимум мне.

Да, ещё systemd нужен как минимум мне.

Был, котенок, я говорил о том, что был. Сейчас он ясно кому-то нужен, ибо любая технология собирает фанбоев. Это не зависит от того, хорошая она или плохая.

Но политика остается политикой. Раньше мелкомягкий баловался eee (хотя он и сейчас этим занимается), а теперь и красношапка подобным же дерьмом начала.

Обида, первый дистриб как никак.

Тут такое дело: я баловался апстартом и OpenRC, ещё когда systemd не было. И мне не понравилось. А systemd понравился, и я им пользуюсь с каких-то там двадцатых релизов. Так что мимо. И не думаю, что я один такой.

Котенок, а в чем проблема то? Я тебя задел тем, что ты не был «у самых истоков systemd»? Так это ты зря! Я и не об этом говорил совсем. Совсем совсем не о тебе. Нет.

Во-первых, свою фамильярность можешь куда-нибудь убрать, от неё ни тепло ни холодно. Во-вторых, ты утверждал, что «systemd был нужен только Red Hat», что неверно, т. к. необходимость ощущалась (например, мне). Ну такой себе формальный контрпример.

На сколько долей процента?

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

Если бы последователи Поттеринга делали корабли, то они, по всей видимости, приваривали бы спасательные шлюпки к корпусу.

:))) Причем резак/болгарка/etc находились бы в трюме

Сильно зависит от реализации проверок, что проверяем, и частоты их использования, «при остром желании» и «пароход» остановить можно

Ну вот сначала нужно показать, что повторные проверки как-то мешают, а потом уже возмущаться. Сейчас там всё сделано по уму: проверки в начале каждой функции, кроме вспомогательных статиков, которые вызываются из одного места.

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

А давай не сравнивать hard realtime и линуксовый юзерспейс?

Любая лишняя проверка это работа железа, т.е. дополнительное время. Да и выше вам уже ответили.
PS " линуксовый юзерспейс" афигеть «юзерспейс» в pid1

А давай не сравнивать hard realtime и линуксовый юзерспейс?

Я кстати про «пароход» не случайно написал, несколько месяцев назад тут пролетало про завод в тайване и «параход» где заменили старые спарки на qemu. Так что чем вам не realtime ?

Любая лишняя проверка это работа железа, т.е. дополнительное время.

Я повторяю вопрос: сколько этого лишнего времени будет? В процентах.

Да и выше вам уже ответили.

С анонимусом согласен. С тобой — нет.

афигеть «юзерспейс» в pid1

Посмотри в словаре значение слова «юзерспейс», почитай про реалтайм в линуксе (точнее, про отсутствие оного) и больше не приплетай сюда промышленные контроллеры и станки с ЧПУ.

Я повторяю вопрос: сколько этого лишнего времени будет? В процентах.

Сколько «средняя температура по больнице включая гнойное и морг»(ц) ?
Вы реальный знаток сабжа, и я уважаю вас за то что помогаете здесь с возникающими вопросами!
Но выполнение любой команды есть процессорное время, копирование данных из/в память, передача по конвейеру, и т.д. все занимает время. А мы все удивляемся чей-то современные компы тормозят в ДЕ/браузерах и т.п. хотя все тоже самое раньше работало на мощностях в разы ниже.
Отвечая на ваш вопрос, да хз сколько процентов... 100500 раз проверить вхождение символа в char* 512k или два раза /0

Отвечая на ваш вопрос, да хз сколько процентов...

В таком случае какие могут быть разговоры?

100500 раз проверить вхождение символа в char* 512k или два раза /0

Предъяви, пожалуйста, в коде systemd пример избыточно многократного поиска символа по строке, размер которой может достигать 512k.