Леннарт Поттеринг (Lennart Poettering) сообщил (https://plus.google.com/115547683951727699051/posts/cb3uNFMNUyK) о реализации поддержки технологии "seccomp filter" в системном менеджере systemd, что позволяет обеспечить изоляцию системных вызовов для запускаемых через systemd процессов. Для создания изолированных окружений используется простой синтаксис определения допустимых системных вызовов, без необходимости непосредственной модификации самих приложений. Указанная возможность может быть активирована при использовании ядра Linux 3.5, релиз которого ожидается на следующей неделе.
В качестве примера помещения процесса в sandbox-окружение приводятся следующие настройки:<font color="#461b7e">
[Service]
ExecStart=/bin/echo "I am in a sandbox"
SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write</font>
В общем виде принцип работы seccomp filter сводится (http://outflux.net/teach-seccomp/) к ограничению доступа к системным вызовам, при этом логика выставляемых ограничений задаётся на уровне защищаемого приложения, а не через задание внешних ограничений, как в случае AppArmor или SELinux. В код программы добавляется структура с перечнем допустимых системных вызовов (например, ALLOW_SYSCALL) и реакции в случае несовпадения (например, KILL_PROCESS). Доступ к системным вызовам определяется в виде правил, оформленных в BPF-представлении (Berkeley Packet Filter), которое получило распространение в системах фильтрации сетевых пакетов.
Система seccomp filter позволяет реализовывать достаточно сложные правила доступа, учитывающие передаваемые и возвращаемые аргументы. Программа сама определяет какие системные вызовы ей необходимы и какие параметры допустимы, все остальные системные вызовы блокируются, что позволяет ограничить возможности атакующего в случае эксплуатации уязвимости в защищённом при помощи seccomp приложении. Возможность задания фильтров аргументов позволяет также защититься от большинства атак, эксплуатирующих уязвимости в системных вызовах. Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN (http://sota.gen.nz/af_can/), sock_sendpage (http://blog.cr0.org/2009/08/linux-null-pointer-dereference-d...) и sys_tee (http://www.juniper.net/security/auto/vulnerabilities/vuln228...), успешно блокируются при надлежащем использовании seccomp. В настоящее время поддержка seccomp filter реализована в таких популярных серверных приложениях, как OpenSSH и vsftpd, патчи с поддержкой seccomp filter уже поставляются в ядре Linux из состава Ubuntu 12.04.URL: https://plus.google.com/115547683951727699051/posts/cb3uNFMNUyK
Новость: http://www.opennet.me/opennews/art.shtml?num=34352
Может кто-нибудь обьяснит мне, тупому, зачем это надо...
Чтобы ограничить возможности в случае успешной атаки на приложение.
>> Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN, sock_sendpage и sys_tee, успешно блокируются при надлежащем использовании seccomp.У злоумышленника будет меньше прав и возможностей при атаке и использовании уязвимостей.
>зачем это надо...Чтобы редхату не баги в софте искать а политики писать. Тупиковый путь для майнстрима IMHO. Так только для специфичных систем где требуется сертификация по определенным уровням.
Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение
>Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроениеНадо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах.
> Надо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах.Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие.
И знаете, в чем-то он прав.
>Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие.Ты это говоришь так, будто в ядре специально держат костыли для всех инитов.
Именно так. Причем надо принимать во внимание несколько моментов:- Нынешний (в условиях мирового кризиса и спада) Редхат - совсем не то что помнят большинство никсоидов со стажем. Нынешняя редхат готова и жестко экономить и использовать подлые приемчики тоже - ведь в конце-концов она ориентированная на прибыль корпорация, а вовсе не богадельня
- Редхат *предельно* заинтересованна в удалении свободных линукс-дистров с серверного рынка, - ведь там у нее свой коммерческий дистр, - и для этого годится все. В том числе и поделия Леннарта. Причем в данном случае Редхат выигрывает дважды: загоняет универсальные линукс-дистры на рынок десктопных систем и обкатывает новые концепции
В общем, кто-как, а я нынешнему Редхату верю только чуточку больше чем ораклу с мелкософтом. Те враги матерые, со стажем. А Редхат, в моих глазах, - враг "без пяти минут", готовый в любой момент стать врагом полноценным.
...а хомячки продолжают радоваться загрузке за пять сек с помощью системд и думать, что все делается для них любимых.
Теория заговора. Форкайте и наслаждайтесь, кто не даёт-то?? Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку. Сами дистры открыты. Центось же существует ;) Поменьше читайте «разоблачения, скандалы, интриги, расследования» и побольше думайте головой и смотрите вокруг.
твои форки никому не нужны. ты просто не будешь успевать за апстримом и их новым кулфичами.
давайте дополним.RedHat не брезгует делать vendor lock. Но делает это более элегантно что ли чем MS..
Она просто не распространяет драйвера на железо в открытый досуп, они доступны только под подписке и только в бинарном виде и только собранные под ее ядро.
А хомячки должны выступать бесплатным тестерами на пакетах альфа качества в федоре. Потом же их пересоберут правильно, закроют бинарные пакеты и окружение сборки - и будут вам продавать за деньги.
А вы будете вставлять себе этот анальный зонд и радоваться - какой хороший RedHat.
Можно чуть по-подробнее? В идеале ссылки "на почитать".
Думаю, не дождётесь :-)
Я думаю, прежде чем мы продолжим обсуждение, Вы предоставите пруфлинки на тему закрытого исходного кода пакетов редхат.
я думаю вас не затруднит зайти в RHN и посмотреть на бинарные пакеты с драйверами.
Для которых не всегда есть src.rpm.Или прошивки для raid, sas, wifi карты - которые отличаются от того что идет с ядром.
> я думаю вас не затруднит зайти в RHN и посмотреть на бинарные
> пакеты с драйверами.
> Для которых не всегда есть src.rpm.Если драйвера GPLные, то есть. Если проприетарные, то нет.
> Или прошивки для raid, sas, wifi карты - которые отличаются от того
> что идет с ядром.Это не совсем то, что утверждалось ранее каким-то из анонимов. Напомню, текст был такой:
"А хомячки должны выступать бесплатным тестерами на пакетах альфа качества в федоре. Потом же их пересоберут правильно, закроют бинарные пакеты и окружение сборки - и будут вам продавать за деньги."
Разве в федоре есть исходники проприетарных драйверов и фирмварей?
> пятибаксовымиУважаемые зажравшиеся москвичи. Прошу понять одну вещь. Вокруг вас расположено огромное государство, членами которого вы являетесь. И в нём принято деньги считать в собственной государственной валюте - рублях. Договорились?
Какие именно драйверы, вы о чем?Исходный код _всех_ драйверов, что идут в ядре RHEL доступен в src.rpm ядра - со всеми фиксами и патчами, которые редхат использует и именно в том виде, в котором они компилируются в конечный продукт.
Никаких драйверов вне ядра в редхате нет (есть non-free kmod'ы в дополнительном репозитории для некоторых редких устройств, но я ни на одном сервере ни разу не сталкивался с необходимостью их применения). Это легко доказывается тем, что ядро в SL и Centos, собираемых полностью из сорцов поддерживает все то же железо, что и RHEL.
> Какие именно драйверы, вы о чем?
> Исходный код _всех_ драйверов, что идут в ядре RHEL доступен в src.rpm
> ядра - со всеми фиксами и патчами, которые редхат использует и
> именно в том виде, в котором они компилируются в конечный продукт.через 2 месяца после того как выложен исходник.
> Никаких драйверов вне ядра в редхате нет (есть non-free kmod'ы в дополнительном
> репозитории для некоторых редких устройств, но я ни на одном сервере
> ни разу не сталкивался с необходимостью их применения).вы определитесь - или их нету, или non-free kmod все таки есть?
В моем случае - потребовалось устанавливать их дрова для ipw2200 wifi card - ибо с штатными сети не было.
а ноутбук без wifi выглядит как-то странно..
Отдельно были правильные драйвера для aac raid - с которыми он таки работал с нормальными iops.
а не тот который в ядре.. И еще стопка всякого.
> Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку.Из перечисленного она более-менее интересна разве что для SLES.
А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта новость -- интересна.
> А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта
> новость -- интересна.Чем, что в монстра протащили очередную галочку?
Попадет-ли это чудо в RHEL и в каком виде (~= когда?) - вот что интересно (и сурьезно).
>> хотя конкретно эта новость -- интересна.
> Чем, что в монстра протащили очередную галочку?Ещё одной юзерспейсной ручкой к полезному ядерному механизму, хотя место действительно в самих сервисах.
>Теория заговораЭто не теория заговора, а практика борьбы за рынок
>Форкайте и наслаждайтесь, кто не даёт-то??
Системд не надо форкать. Он того не стоит, имхо. Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo
>Сами дистры открыты
Видимо именно в силу "открытости" ни в одном из них системд нельзя удалить. Можно только отключить, но в системе он все равно будет присутствовать
>побольше думайте головой и смотрите вокруг
Я думаю, что не Вам меня учить, уважаемый. Следите лучше за своей головой и поменьше пропагандируйте ПО, спроектированное инженером-программистом коммерческой компании, для целей (какая неожиданность!) получения максимальной прибыли этой самой компании.
> Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo"после 15-ти работы и трех сертификатов соответствия" не суметь установить sysvinit-init ? оригинально.
Слушай, Агент, а ты уверен что ты 007? А то по ходу (и по стилю тоже!) канешь на "агент РедХата"!И да, (к твоему сведению) по зависимостям systemd тебе не удалить. Никак. Абыдно, слюшай, да?
> И да, (к твоему сведению) по зависимостям systemd тебе не удалить. Никак.
> Абыдно, слюшай, да?ну и что ? мешать он не будет.
А не приходило в голову что если две системы конкурирует, и одну нельзя удалить, а она от корпорации заинтересованной в получении максимального дохода, то это называется вендор лок, а? О, да! - изящный такой, но зонд. Анальный.
> А не приходило в голову что если две системы конкурирует, и одну
> нельзя удалить, а она от корпорации заинтересованной в получении максимального дохода,systemd нельзя удалить не потому, что он реально нужен, а из-за неправильной сборки пакетов.
например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость.
ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid распилить пакет на два: один с обычным инитскриптом, а во второй положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid.
аналогичная история с apache2 и другими "зависимыми от страшного systemd" пакетами. исключение у себя я нашёл только одно: mpd слинкован с libsystemd-daemon, и никто не знает зачем.
но, разумеется, багрепортов писать никто не будет, поскольку строить теории заговора и устанавливать gentoo существенно проще и интереснее, чем ковыряться в пакетах, выясняя откуда вылезает лишняя зависимость.
>[оверквотинг удален]
> что автоматически порождает зависимость.
> ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid
> распилить пакет на два: один с обычным инитскриптом, а во второй
> положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid.
> аналогичная история с apache2 и другими "зависимыми от страшного systemd" пакетами. исключение
> у себя я нашёл только одно: mpd слинкован с libsystemd-daemon, и
> никто не знает зачем.
> но, разумеется, багрепортов писать никто не будет, поскольку строить теории заговора и
> устанавливать gentoo существенно проще и интереснее, чем ковыряться в пакетах, выясняя
> откуда вылезает лишняя зависимость.На самом деле это совсем не так. Во-первых багрепорты не пишутся на действия майентейнеров. Багрепорты (как следует из названия) - это сообщения об ошибках в программе. В данном же случае - это не сбой в ПО. Это раз.
Генту устанавливать существенно тяжелее. Собсно, поэтому и существуют майентейнеры, которые (по идее) должны на себя взять труд формирования платформы, дамы разрабы и интеграторы не заморачивались. Это два.
В-третьих, во всех (я подчеркиваю ВО ВСЕХ) ведущих дистрах лапка Редхата чувствуется весьма и весьма. Та же опенсусе давно и прочно бредет в кильватере редхата. И у них это называется "дружеской помощью"
Все! - sapiens sat, - вот когда мне сусеводы скажут: "Хорошо - можете выбирать между systemd и openrc, и между network manager и wicd" - я подумаю о возврате на мой все еще самый любимый дистр, а пока генту - это наше все.
> На самом деле это совсем не так. Во-первых багрепорты не пишутся на
> действия майентейнеров. Багрепорты (как следует из названия) - это сообщения об
> ошибках в программе. В данном же случае - это не сбой
> в ПО. Это раз.на самом деле всё ровно так и есть. багрепорты (как следует из названия), это сообщения об ошибках. в том числе, и об ошибках упаковки.
> Собсно, поэтому и существуют майентейнеры, которые
> (по идее) должны на себя взять труд формирования платформы, дамы
> разрабы и интеграторы не заморачивались. Это два.они и берут на себя труд. но предугадать потребности всех не могут. именно для этого и придуманы системы обратной связи в виде разного рода багтрекеров.
> В-третьих, во всех (я подчеркиваю ВО ВСЕХ) ведущих дистрах лапка Редхата чувствуется
> весьма и весьма. Та же опенсусе давно и прочно бредет в
> кильватере редхата. И у них это называется "дружеской помощью"та же опенсусе, давно и прочно, не бредёт ни в чьём кильватере, а занимается развитием своего дистрибутива и сопутствующих сервисов.
> Все! - sapiens sat, - вот когда мне сусеводы скажут: "Хорошо -
> можете выбирать между systemd и openrc, и между network manager и
> wicd"выбирать можно и сейчас.
>на самом деле всё ровно так и есть. багрепорты (как следует из названия), это сообщения об ошибках. в том числе, и об ошибках упаковки.Это чистая теория. А на практике (типичная ситуация) так: Я, в багрепорте на треке джанги - "Уважаемые, у меня есть очевидная ошибка, связанная с поддержкой СУБД Postgre Вашим проектом. Вот мой код, а вот мои функциональные тесты, благодаря которым эта ошибка и выявилась." Дежурный майентенер проекта - "Я не могу вашу ошибку повторить у себя.... Правда у меня не постгри, а другая СУБД, но я думаю, что к коду нашего проекта это не имеет отношения" И все! Мой репорт закрыт. Патчи накладываю по сей день.
А теперь, - внимание!, - вопрос: могу я претендовать на объективность майентейнера сусе, при условии что репорт - это репорт не на код, а на самого маентейнера, и при условии что этот майентейнер до кучи штатный сотрудник редхат?!!
> но предугадать потребности всех не могут
А это и не надо. Достаточно предоставить возможность выбора.
>та же опенсусе, давно и прочно, не бредёт ни в чьём кильватере, а занимается развитием своего дистрибутива и сопутствующих сервисов.
Бу-гы-га-га. Я даже комментить это высказывание не буду!
>выбирать можно и сейчас.
Нет, это не всегда возможно.
В том же ясте в сусе есть возможность настройки только одного сетевого менеджера (понятно какого?). А что бы никто не трепыхался в общесистемный (уровнем ниже) конфиг ввели ряд опций network manager. Я потратил не один день что бы установить свой менеджер. И я думаю, что новичкам это не по силам.
И не только новичок не сумеет красиво (а хоть бы и НЕ красиво!) удалить systemd и тот логер от Поттерига. Это реально не реально!((((
> например, acpid зависит от systemd потому, что в пакете acpid лежит
> /lib/systemd/system/acpid.service, что автоматически порождает зависимость.
> ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid
> распилить пакет на два: один с обычным инитскриптом, а во второй
> положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid.IMHO лучше бы тогда отпилить systemd-base какой с %dir /lib/systemd/system/.
PS re #103: по таким поводам вполне вешаются багрепорты-фичреквесты, ну и "sapienti" тогда уж...
> IMHO лучше бы тогда отпилить systemd-base какой с %dir /lib/systemd/system/.лучше, конечно. распилить на -base, -libs и, собственно, сам systemd. но тогда страдания на тему "у меня в системе есть кусок systemd" будут продолжаться бесконечно, поскольку на содержимое пакетов никто не смотрит :)
> PS re #103: по таким поводам вполне вешаются багрепорты-фичреквесты, ну и "sapienti"
> тогда уж...багрепорты не нужны, ведь мантейнер может и отказать.
> но тогда страдания на тему "у меня в системе есть кусок systemd" будут
> продолжаться бесконечно, поскольку на содержимое пакетов никто не смотрит :)Думал добавить, но не нашёлся с формулировкой (кроме "rpm -qa") -- спасибо :)
> багрепорты не нужны, ведь мантейнер может и отказать.
О да, они такие.
> например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость.Кто вам такое сказал? А если acpid.service будет всеми проигнорирован (потому что systemd в системе не будет), а acpid будет запущен другим способом (хоть руками, хоть через скрипт sysv) — то от этого что-то пойдет не так?
И дополнительных движений почти не надо.> ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid распилить пакет на два: один с обычным инитскриптом, а во второй положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid.
Не нужно, почему — см. выше.
>> например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость.
> Кто вам такое сказал?вы имеете какое-нибудь представление о том, как формируются зависимости rpm пакетов ?
Какое-нибудь имею. Если я захочу положить в пакет случайный каталог с какими-то текстовыми файлами (пускай *.service) и не пропишу явно зависимости от systemd — у меня не выйдет? Или пакет сам эту зависимость получит?
> Какое-нибудь имею. Если я захочу положить в пакет случайный каталог с какими-то
> текстовыми файлами (пускай *.service) и не пропишу явно зависимости от systemd
> — у меня не выйдет? Или пакет сам эту зависимость получит?случайный каталог - на здоровье. каталог, который предоставляется пакетом systemd, автоматически родит зависимость на пакет systemd.
Интересно, не знал. Но даже в таком случае не нужно резать все пакеты на два (к тому же как сказать юзерам, что если у них стоит systemd, они должны ставить acpid-systemd, а не просто acpid?). Можно сделать отдельный пакет systemd-filesystem, где будет всего лишь несколько пустых каталогов (так вроде бы некоторые и делают), и пусть все эти acpid'ы & Ko зависят от него.
> Можно сделать отдельный пакет systemd-filesystem, где будет всего лишь несколько
> пустых каталогов (так вроде бы некоторые и делают), и пусть все
> эти acpid'ы & Ko зависят от него.не можно, а нужно (и здесь это уже обсудили). и даже обсудили почему было предложено распилить не systemd, а "зависимые" от него пакеты :)
>> например, acpid зависит от systemd потому, что в пакете acpid лежит
>> /lib/systemd/system/acpid.service, что автоматически порождает зависимость.
> Кто вам такое сказал?Например, http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=s...
> Например, http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=s...Да, спасибо, уже ткнули. Хотя имхо все равно всё не так печально, выше описал.
> Слушай, Агент, а ты уверен что ты 007?Достаточно: http://lists.altlinux.org/pipermail/community/2005-May/35311... :)
Я на 99% уверен, что там отдельная утилита. systemd - это не один монолитный бинарник. В арче вон systemd частично используется, но init остался старый.
> Я на 99% уверен, что там отдельная утилита. systemd - это не
> один монолитный бинарник. В арче вон systemd частично используется, но init
> остался старый.Да, в основе systemd лежит модульная архитектура, и все, что выходит за рамки задач init, оформлено отдельными бинарниками (причем systemd можно собрать практически без всего, неотключаемы только udevd и journald).
Но к данному случаю это не относится. Поддержка seccomp входит в настройку окружения запускаемых процессов служб, т.е. должна быть реализована именно в init.
Конечно, можно наплодить бинарников, которые будут устанавливать по одной настройке и execать друг друга по цепочке, но это чистый оверхед и бред сивой кобылы. Подобных настроек в systemd - несколько десятков, вызывать 20 бинарников по цепочке задолбаешься.
> Но к данному случаю это не относится. Поддержка seccomp входит в настройку
> окружения запускаемых процессов служб, т.е. должна быть реализована именно в init.Ну-ну... Как и rlimits и еще куча всякого добра. А вот в sysv init ради использования всего этого оказалось ненужным городить невнятный монолит.
> Конечно, можно наплодить бинарников, которые будут устанавливать по одной настройке и execать
> друг друга по цепочке, но это чистый оверхед и бред сивой кобылы. Подобных настроек в systemd - несколько десятков, вызывать 20 бинарников по цепочке задолбаешься.*Пока* несколько десятков. Но нет - будем экономить на спичках и плодить новые опции, вместо того чтобы один раз спроектировать софт раз и навсегда.
Проблема в том, что systemd "запланирован" не как очередная погремушка для десктопа - а как замена init. С учетом того, что базовый функционал (то самое "практически без всего") совершенно никак не определен - выглядит это смешно.
> Ну-ну... Как и rlimits и еще куча всякого добра. А
> вот в sysv init ради использования всего этого оказалось ненужным городить
> невнятный монолит.Ага. В sysvinit это делается через задницу.
Достаточно сравнить работу админа, перед которым стоит задача выставить все ключевым службам rlimits, capabilites и прочие.
В случае с systemd, админ просто редактирует конфиги юнитов и кладет их в /etc.
В случае с sysvinit, админ вынужден лично править все init-скрипты, а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты.Не говоря уже о том, что куча фич типа PrivateTmp, PrivateNetwork и DeviceAllow пока что не реализуема средствами sysvinit.
> *Пока* несколько десятков. Но нет - будем экономить на спичках и
> плодить новые опции, вместо того чтобы один раз спроектировать софт раз
> и навсегда.systemd изначально был спроектирован раз и навсегда. Наращивание функциональности - это количественное изменение, а не смена архитектуры.
Понятие юнита никто и никогда не пересматривал - просто вводились новые типы юнитов и настройки для них.> С учетом того, что базовый функционал (то самое "практически без всего") совершенно никак не определен - выглядит это смешно.
Базовая функциональность systemd (который init) - всего лишь управление юнитами. Не больше и не меньше.
> Ага. В sysvinit это делается через задницу.Для начала: непосредственно в sysvinit это *не делается*.
> В случае с systemd, админ просто редактирует конфиги юнитов и кладет их в /etc.
Не поверите, все точно также. Только "конфиги ... в /etc" - в т.ч. и скрипты, запускаемые sysvinit. Все это в достаточной степени гибко - и может быть сколь угодно "заоптимизировано", в смысле простоты настройки.
> а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты.
Лечите руки или меняйте дистрибутив - у нормальных людей ничего нигде не затирает.
> systemd изначально был спроектирован раз и навсегда.
Ну тогда твердая двойка за подобное "проектирование".
> Базовая функциональность systemd (который init) - всего лишь управление юнитами. Не больше и не меньше.
Упс, больше. Вспомните предмет темы - это не модуль, не плагин. Это никак не откручивается от "управления юнитами", как и стопицот других финтифлюшек. Как минимум - пока.
>В случае с sysvinit, админ вынужден лично править все init-скрипты, а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты.Это где такое? В Debian если контрольная сумма чего-то в /etc не совпадает с таковой из предыдущего пакета, то появляется предложение - оставить имеющуюся версию, установить новую, посмотреть различия.
хых, да и в rpm тоже самое. Если программеры не дураки, то все инит скрипты маркируются как конфиг файлы, и при обновлении они не затираются, но не все анонимы об этом знают.
>причем systemd можно собрать практически без всего, неотключаемы только udevd и journaldУстаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev без systemd http://www.mail-archive.com/systemd-devel@lists.freedes...
> Устаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev
> без systemd http://www.mail-archive.com/systemd-devel@lists.freedes...Вы, наверное, по аглицки не разумеете, и потому ссылками наугад кидаетесь.
udev можно собрать без systemd. А вот systemd без udev - нельзя, как я и говорил.
Разумеется, причина проста. udevd без systemd имеет смысл (например, initrd или альтернативная система инициализации), а systemd без udevd - не имеет (у udev нет полноценных аналогов).
>udev можно собрать без systemdНельзя.
Можно же. Смотри udev-186.ebuild
> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроениеНу так оформляйте, делов-то.
> Ну так оформляйте, делов-то.ага, написать фактически замену systemd. и только.
> А что, слабо?Написать действительно хорошую альтернативу sysvinit? Да, довольно непросто.
Просто в силу того, что ее сперва нужно *придумать* и спроектировать. Поделка поттеринга тут слабо поможет.
> просто невыносимо требуется открытие сорцов?
Да нет. Быдлокодить любой дурак умеет.
>> А что, слабо?
> Написать действительно хорошую альтернативу sysvinit? Да, довольно непросто.
> Просто в силу того, что ее сперва нужно *придумать* и спроектировать. Поделка поттеринга тут слабо поможет.«Show me the code»© — тогда и поговорим.
>> Ну так оформляйте, делов-то.
> ага, написать фактически замену systemd. и только.Ну вкрутите в sysvinit тогда.
> Ну вкрутите в sysvinit тогда."Вкрутить" (как сделано в данном примере, кстати) - плохая инженерная практика (Big ball of mud). О чем, собственно, и речь.
sysvinit не стремятся научить кофе варить - и это правильно.
Потому что там ограничения на уровне целых сервисов, а не бинариков. Вполне логичная фича для менеджера запуска.
эм секомп фильтры существуют отдельно надо используй где угодно, новость о том что теперь можно задавать эти правила прямо в юнитах системд, а не гдето ещё.
> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроениеМожно. Но этого пока никто не сделал.
Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения среды исполнения удобнее настраивать именно в нем.
>> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение
> Можно. Но этого пока никто не сделал.
> Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень
> удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения
> среды исполнения удобнее настраивать именно в нем.теперь попытаемся подумать. Если apache запускается из systemd - все есть, а если я его вдруг рестартовал руками - я потерял эту хваленую защиту. Может потому AppAmmor / Selinux изначально делался отдельными средствами? Что бы при любом раскладе метки контроля доступа были применены ?
Глупенький. Ты хоть раз попробуй руками запустить.
Защита это далеко не самое страшное что потеряешь
Ты даже в несвоей винде службы руками не запускаеш
>Думается, что она была бы востребована не только и не столько в systemdОна и не имеет никакого отношения к systemd.
> Она и не имеет никакого отношения к systemd.Тем не менее, пока она поддерживается только в systemd.
> Тем не менее, пока она поддерживается только в systemd.Ну так правильно, редхат, ынтерпрайз, безопасность, selinux, теперь вот это. А больше оно никому и не сдалось.
Для галочки поддержка есть. Срач на эту тему начать можно. Полезность без поддержки со стороны запускаемого приложения близка к 0.
>Тем не менее, пока она поддерживается только в systemd.1. Это не поддержка, а деревянная запускалка. В чем ее смысл если есть SELinux и AppArmor?
2. Читай хотя бы новость до конца что ли.
Уже есть. Те же АппАрмор и СЕЛинукс. Но т у сабжу уровень пониже, этим он лучше.
Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.htmlЧто характерно, практически все описанные там технологии основаны на уникальных фичах ядра Linux, но никто, кроме systemd и LXC, их не использует. То ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них никогда не слышали.
> Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.html
> Что характерно, практически все описанные там технологии основаны на уникальных фичах ядра
> Linux, но никто, кроме systemd и LXC, их не использует. То
> ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них
> никогда не слышали.без сомнений и, к сожалению, без иронии - второе. вы почитайте, что тут ретрограды всея локалхостов пишут, в дискуссиях при попытках обратить внимание на суть проблем, их аргументация переводится на уровень "у вас руки кривые", что считают мощнейшим из доводов, и, как и полагается прямым как рельса индивидумам, в глупости своей честны и фанатично непоколебимы
any feature that is sold with ".. and systemd can use this fox Xyz", is a *misfeature* in my opinion. (c) тот самый ретроград, по сравнению с которым ты ничто.PS: А вообще, в lkml довольно негативное отношение к systemd. "Фанаты" - редхетовцы, да и те плюются.
Просто оно не так сильно нужно, как некоторые тут кричат. При этом требует неких (иногда, как с настройкой selinux - больших) усилий.
Кто бы что ни говорил про Поттеринга, а штука-то годная и нужная.
без всякого зазрения утверждаю, поттеринг - замечательный инженер
Как инженер - не очень, но идеи у него правильные.
> Как инженер - не очень, но идеи у него правильные.В чем? Вот скажите-ка мне, кто мешает вам, таким красивым и умным, имея сорцы ядра, ограничить момент запуска cервисов лишь избранными вызовами? И наслаждаться невозможностью малвари прошмыгнуть в момент, когда сервисы стартуют? М?
BTW, все это уже было лет 8 назад в Solaris. Конкретно - в SMF. И называлось "RBAC" - Role Based Access Control, причем оно прекрасно интегрировалось с SMF.
Велосипеды, велосипеды...
Это просто прекрасно.
> Это просто прекрасно.У тебя ж геморроя нет? Это же прекрасно!
Timeo Danaos et dona ferentesЭто не говоря уже о склонности к комбайностроению и неряшливом программировании
Я вот чего не пойму. В общем виде seccomp filter разработан для прикладных программистов, чтобы последние могли обезопасить свои сервисы (как это сделали разработчики OpenSSH и vsftpd). Так зачем же Поттеринг тянет в свое поделие все, что красиво блестит? Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux (для случаев, когда разработчик сервиса не позаботился о безопасности своей программы). В чем смысл втянуть в мегакомбайн все разработки, на сколько хороши бы они не были? Думаю, скоро мы увидим новости, что системд готов заменить нам и SELinux вместе с AppArmor и всем остальным...
Ну, очевидный ответ - потому что прикладные програмисты не торопятся использовать эту штуку, а так можно для их программ реализовать нужные ограничения снаружи. Но вне вот интересно - а что, SELinux/AppArmor этого не умеют, что надо именно эту механику использовать? Если что - я с ними не знаком совершенно, ибо надобности нет.
Так вот надо менять стиль написания программ, а не тянуть вещь, предназначенную для защиты приложения от самого себя, в какие-то управляющие демоны. Это мусор, seccomp не для этого делался!
Но нет же, пришёл Поттеринг и сделал очередную примочку к своему монстру =)
Зато вброс годный. Каменты читал? 95% фанбоев как обычно не поняли о чем речь и в чем цимес seccomp filters, но по привычке принялись восхвалять Леннарда. 50% вообще поняли, что Поттеринг изобрел seccomp filters. =)>Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux
Не подобный, а на несколько порядков защищеннее, гибче и удобнее. К примеру если процесс запустят не через systemd, то фильтры не применятся, в отличие от SELinux, AppArmor или нормальных реализаций seccomp filters, которые работают в любом случае.
Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload и подобную механику. Уж всяко не хуже systemd будет.
> Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для
> любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload
> и подобную механику. Уж всяко не хуже systemd будет.Об чем и спич. В Юниксах это существовало сто лет назад. И кто изобретатель велосипедов с восемнадцатиугольными колесами тут?
Итак, Леннарт извратился и затащил фичу, которая изначально проектировалась для использования самими приложениями, в свой менеджер инициализации. То, что приложение само может лучше решить, какие свои части как защищать (например, форкнувшись и по-разному ограничив права каждого чайлда), осталось для Поттеринга неважной деталью. В итоге получили аналог SELinux, но реализованный через seccomp filters, которые вообще не отличаются толковой реализацией. Что же, посмотрим, насколько сия кривая поделка проникнет в продакшен и сколько народу не отключат её после первого фоллаута.
Помнится, в те "старые добрые времена", когда SELinux была волне, ходили такие рассказы:
сплоит пробившийся на уровне ядра первым делом проверял SELinux и вырубал его сразу же, потом делал все что ему необходимо!Ну естественно же, все развивается по спирали.