Переход Ubuntu на Systemd

[Rootlexx]

Так или иначе придётся платить - хотя бы в качестве бетатестеров. Просто я думал, что это в основном участь федоровцев. А оказывается никто даже дебиановцы от этого не избавлен.

Из крупных дистрибутивов Debian переходит на systemd одним из последних. Так что β-тест уже давно прошёл, и спешки в переходе поэтому я не вижу.

[Rootlexx]

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

Ну вот лично я не понимаю, что написано в первом приведённом примере, не залезая в man bash. Хотя писал и пишу довольно сложные скрипты.
Кроме того, я не знаю sed (ибо ни разу не понадобилось), и потому не понимаю эту строку (/etc/init.d/umountfs):

Код: Выделить всё

PROTECTED_MOUNTS="$(sed -n ':a;/^[^ ]* \/ /!{H;n;ba};{H;s/.*//;x;s/\n//;p}' /proc/mounts)"

Тем не менее, вот уже больше десяти лет как-то умудряюсь работать в GNU/Linux, хотя по-вашему это невозможно.

[serzh-z]

Тем не менее, вот уже больше десяти лет как-то умудряюсь работать в GNU/Linux, хотя по-вашему это невозможно.

Ты просто не настолько крут, как Эдди. Читаешь маны, как лошара, вместо того, чтобы читать код. =)

[Rootlexx]

переписать init на php/python/brainfuck

Есть и такой: https://github.com/pisilinux/mudur.

[Red Gremlin]

Забыли уточнить, что такие извращения используются для парсинга конфигурации. Что силами systemd невозможно в принципе.

Для многих скриптов достаточно будет EnviromentFile= и простейшего файла конфигурации. Если же нет, то это а) признак проблемы дизайна демона, если уж для его запуска приходится дублировать уже имеющийся функционал (парсинг конфига) внешними средствами, б) и это всё равно доступно в systemd через промежуточный скрипт в ExecStart. Т.е. в худшем случае systemd ничем не хуже, в лучшем гораздо лучше.

[Bizdelnick]

Т.е. в худшем случае systemd ничем не хуже, в лучшем гораздо лучше.

...чем армяне.

[drBatty]

Но поднятый там вопрос о безопасности смущает. Это реально потенциальная проблема, или опять "ааа, все умрём?"

ну я чуть выше именно об этом и говорил. See: Переход Ubuntu на Systemd (и выше)

Удивительно, что это не только мне в голову пришло.

[drBatty]

Кроме того, я не знаю sed (ибо ни разу не понадобилось), и потому не понимаю эту строку (/etc/init.d/umountfs)

как-то странно вы рассуждаете: если-бы эта строчка ХОТЬ РАЗ сломалась(у вас), то вы бы были вынужденны открыть info sed, и разбираться. Что доказывает лишь потрясающую НАДЁЖНОСТЬ sed-скриптов. Ну а если вы не желаете изучать sed, а желаете питон(или что-нить другое, не важно), то это ничего не доказывает. Это ваше право не знать. Пилот Ф1 тоже наверное не знает, из какой стали и как делается корд, который внутри покрышек его болида. Даже несмотря на то, что от этого корда напрямую его жизнь и здоровье зависит.

Есть и такой: https://github.com/pisilinux/mudur.

кто-бы сомневался. А его тоже во ВСЕ дистрибутивы пихают? А почему нет?

Для многих скриптов достаточно будет EnviromentFile= и простейшего файла конфигурации. Если же нет, то это а) признак проблемы дизайна демона, если уж для его запуска приходится дублировать уже имеющийся функционал (парсинг конфига) внешними средствами, б) и это всё равно доступно в systemd через промежуточный скрипт в ExecStart. Т.е. в худшем случае systemd ничем не хуже, в лучшем гораздо лучше.

проблема systemd вовсе не в том, что там "нет какой-то фичи". Всё там есть, никто с этим не спорит. Проблема в том, что новые фичи сложно туда вставлять. Это вам не пара строчек в скрипте.

Выше уже была ссылка доказывающая, что замена тривиальной init на некую ☣ — плохая идея.

[alv]

С systemd можно начать отлично работать, вообще не читая маны.

не, ребята, логика у вас явно не аристотелева
эти два взаимоисключающих аргумента - я слышу с первого дня появления systemd'а:
1) он такой замечательный, что верь на слово
2) ты не понял, какой он замечательный, потому что не читал документации
примерно как призыв изучить язык суахили, например
ну нету мотивации его учить - Чехов на суахили не писал, и даже Ленин им не разговаривал...

[Rootlexx]

Но поднятый там вопрос о безопасности смущает. Это реально потенциальная проблема, или опять "ааа, все умрём?"

Канал взаимодействия с непривилегированным пользователем, действительно, есть, через D-Bus. Но:

• Требуется локальный доступ.
• Непривилегированному пользователю можно запретить доступ к systemd через политики D-Bus.
• Канал взаимодействия узок, локализован, содержит небольшое количество кода и легко проверяем.
• Red Hat провёл аудит безопасности systemd перед включением его в RHEL.

Кроме того, заявляя о наличии лишь sshd как объекта атаки, автор забывает про такую мелочь как ядро, состоящее из миллионов строк кода и работающее в ring 0.

[eddy]

Да. И линукс превратится в унылое говнище - вторую мастдайку.

Мне казалось, копрофилия и истерики более свойственны юному возрасту.

Копрофилия == жрать говно. Говно == systemd. Ну и кто тут дерьмоед?

[drBatty]

Кроме того, заявляя о наличии лишь sshd как объекта атаки, автор забывает про такую мелочь как ядро

ЧЕРЕЗ ЧТО вы будете атаковать ядро? Через libastral.so? Есть некие "точки входа", такие как sshd, или http-сервер. Автор справедливо отмечает, что на обычном серевере кроме sshd ничего нет(обязательного). А вот в systemd -- много интересного. Например те самые коды возврата в init, о которых вы мне здесь рассказывали. Это очень хороший способ сделать демон, который запускается в тайне от администратора (администратор его убивает, а он всё равно как-то хитро подымается, этим вашим systemd).

И да, в самом ядре не так уж много кода. Там практически все строчки про разные девайсы. Которые подключать совсем не обязательно. Если обнаружится дыра, страдать будут не все, а исключительно юзеры какого-то девайса.

[yars]

Red Hat провёл аудит безопасности systemd

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

[drBatty]

Нужен независимый аудит кода systemd.

в такого класса программах это попросту невозможно. Там же версия каждый день меняется, как в FireFox'е. И из-за всяких QRcode и прочих http версия и БУДЕТ меняться впредь. Это вам не init.

Ладно, получим на выходе не Windows, а МСВС. Хрен редьки не слаще.

[Bizdelnick]

Копрофилия == жрать говно.

Копрофилия - это такое сексуальное извращение. Не путайте с копрофагией.

[eddy]

Копрофилия == жрать говно.

Копрофилия - это такое сексуальное извращение. Не путайте с копрофагией.

А, извиняюсь. Значит, человек имел в виду макосьников ☺

[Rootlexx]

ЧЕРЕЗ ЧТО вы будете атаковать ядро? Через libastral.so? Есть некие "точки входа", такие как sshd, или http-сервер. Автор справедливо отмечает, что на обычном серевере кроме sshd ничего нет(обязательного). А вот в systemd -- много интересного.

Учитывая, что ядро постоянно обрабатывает огромный массив внешних для него данных, путей для атаки великое множество, от сетевого стека до системных вызовов. При наличии локального доступа "точкой входа" может быть любое приложение, от существующего до написанного взломщиком. Поэтому приводить sshd как единственный вектор атаки абсурдно. Если же подразумевалась удалённая атака, то при чём здесь systemd, который не обрабатывает данные из сети?

[drBatty]

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

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

Если же подразумевалась удалённая атака, то при чём здесь systemd, который не обрабатывает данные из сети?

да ладно! А удалённые логи? А встроенный http сервер? Ваш Леннарт туда ещё php не встроил? Не? Уверены?

[Rootlexx]

А удалённые логи? А встроенный http сервер?

Удалённое журналирование journald пока не умеет.
http-сервер запускается отдельным процессом-сервисом от непривилегированного пользователя и по умолчанию вообще отключён.
Весьма вероятно, что и реализация удалённого журналирования, если будет реализована, будет отдельным сервисом, также работающим от непривилегированного пользователя.

[drBatty]

Удалённое журналирование journald пока не умеет.

ну мы же про потенциальные точки входа говорим. Они есть и очень близко и к init и к злоумышленнику. Эти ваши любимые коды возврата в инит -- ещё одна точка для атаки. Несложно завалить вашу систему уведомляя systemd "погоди, я сейчас буду готова" в течении недели (: Нет, я конечно понимаю, что вы костылик поставите, что "если «я буду готова» в течении минуты, то считать это атакой". Но это уже DoS, когда оно атаку считает атакой и закономерно уходит в даун. Да и костылики во все дырки ставить устанете. Без кодов возврата никаких дыр и быть не может, если враг что-то и завалит, то только тот сервис, который атакует. На остальной системе это заведомо не скажется. Т.е. в классической init сервисы работают как-бы "в вакууме". Да, init не может поднимать калеченные, это не очень хорошо. Зато рак одного сервиса не валит всю систему.

от непривилегированного пользователя.

и ещё одно усложнение. Какое по счёту? Удалённый лог я могу прямо сейчас прикрутить, если мне захочется. Зачем это в каждом ноуте?

[yars]

drBatty
ответ прост: в каждом андроиде есть функция удаленного управления, зарезервированная для вендоровских админов, чтобы типа юзер мог попросить помощи (но мы-то знаем, для чего на самом деле она там. Скорей бы рутануть свой e612, фирма лыжи - [censored by yars]. Но, к сожалению, пока никак не осилю - то интернета нет, то еще что). Так вот, RH от моды отставать неохота.

[Rootlexx]

Эти ваши любимые коды возврата в инит -- ещё одна точка для атаки. Несложно завалить вашу систему уведомляя systemd "погоди, я сейчас буду готова" в течении недели (:

Какое отношение код выхода процесса имеет к уведомлению о готовности?
Далее, каким образом это может завалить систему? Ну будет сервис в состоянии activating - что с того?
Кроме того, systemd следит за состоянием сервисов, определяемых соответствующими конфигурационными файлами, для установки/модификации которых "атакующий" уже должен обладать правами администратора, что, конечно же, абсурдно.

[drBatty]

Скорей бы рутануть свой e612

зачем? Что-бы красная лампочка на пульте у майора мигала?

[drBatty]

Какое отношение код выхода процесса имеет к уведомлению о готовности?

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

Каким образом это может завалить систему?

процесс поднятия демонов очень ресурсоёмкий. И длительный. Обычно ведь демоны почти ничего не потребляют, а только ждут событий для обработки. Если заставить систему подымать постоянно какой-то сервис, это может привести к перегрузке системы, и как к следствию -- к отказу в обслуживании основными сервисами.

Ну вот вам такой пример: LAMP, простой php скрипт. Администратору кристально ясно, как он работает при работающей СУБД. При не работающей -- тоже в общем-то понятно (503 или что-то подобное). А вот как поведёт себя скрипт при НАПОЛОВИНУ поднятой СУБД? Вы ТОЧНО уверенны, что перед каждой транзакцией ПОЛНОСТЬЮ работа проверяется? А если ДВА скрипта? И один решит, что СУБД работает, а второй -- не работает?

Очевидно результат будет непредсказуемым.

Сейчас это не страшно, админ ручками подымает, если что пофиксит. Да и подымать он может в нужном порядке, у него же голова на плечах, опыт и квалификация. А что с программы возьмёшь? Программа НЕ готова работать в НЕ СТАНДАРТНОЙ ситуации.

systemd следит за состоянием сервисов, определяемых соответствующими конфигурационными файлами, для установки/модификации которых "атакующий" должен уже обладать правами администратора - абсурд.

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

[yars]

зачем? Что-бы красная лампочка на пульте у майора мигала?

Нет, чтобы контролировать свой телефон, на котором полно проприетарщины, доверия которой нет.

[drBatty]

Нет, чтобы контролировать свой телефон, на котором полно проприетарщины, доверия которой нет.

для этого вы внедрите туда sudo полученное из ☣, да? А может ещё и антивирус с кряком оттуда-же?

Не понимаю. Почему вам не носить с собой телефон, который в кармане каждого из 95%, зачем выделяться из толпы?

[yars]

drBatty
потому что мне не нужен карманный шпион, да и постоянно напрягает, предлагая какую-то левую лицензию.

[drBatty]

потому что мне не нужен карманный шпион

а после порутанья он перестаёт шпионить, да?

[yars]

а после порутанья он перестаёт шпионить, да?

Может, и нет, но всякой гадости там уж точно меньше станет, да и вообще, я его не просто рутану, это задача-минимум. Я установлю SailfishSlackware Linux на этот телефон.

[drBatty]

Я установлю

ss в студию.