форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
Сообщение от opennews (ok) on 17-Июл-12, 21:52
Леннарт Поттеринг (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "В Systemd реализована поддержка изоляции системных вызовов д..."	+4 +/–
Сообщение от Сергей (??) on 17-Июл-12, 22:07
Может кто-нибудь обьяснит мне, тупому, зачем это надо...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "В Systemd реализована поддержка изоляции системных вызовов д..."	+6 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 22:18
	Чтобы ограничить возможности в случае успешной атаки на приложение.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	21. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Anonplus on 17-Июл-12, 23:20
	>> Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN, sock_sendpage и sys_tee, успешно блокируются при надлежащем использовании seccomp. У злоумышленника будет меньше прав и возможностей при атаке и использовании уязвимостей.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	64. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от mma on 18-Июл-12, 12:12
	>зачем это надо... Чтобы редхату не баги в софте искать а политики писать. Тупиковый путь для майнстрима IMHO. Так только для специфичных систем где требуется сертификация по определенным уровням.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "В Systemd реализована поддержка изоляции системных вызовов д..."	–1 +/–
Сообщение от Аноним (??) on 17-Июл-12, 22:12
Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от anonymous (??) on 17-Июл-12, 22:26
	>Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение Надо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "В Systemd реализована поддержка изоляции системных вызовов д..."	+3 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:08
	> Надо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах. Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие. И знаете, в чем-то он прав.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	33. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от anonymous (??) on 18-Июл-12, 00:13
	>Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие. Ты это говоришь так, будто в ядре специально держат костыли для всех инитов.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	42. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Игорь (??) on 18-Июл-12, 02:19
	Именно так. Причем надо принимать во внимание несколько моментов: - Нынешний (в условиях мирового кризиса и спада) Редхат - совсем не то что помнят большинство никсоидов со стажем. Нынешняя редхат готова и жестко экономить и использовать подлые приемчики тоже - ведь в конце-концов она ориентированная на прибыль корпорация, а вовсе не богадельня - Редхат *предельно* заинтересованна в удалении свободных линукс-дистров с серверного рынка,  - ведь там у нее свой коммерческий дистр, - и для этого годится все. В том числе и поделия Леннарта. Причем в данном случае Редхат выигрывает дважды: загоняет универсальные линукс-дистры на рынок десктопных систем и обкатывает новые концепции В общем, кто-как, а я нынешнему Редхату верю только чуточку больше чем ораклу с мелкософтом.  Те враги матерые, со стажем. А Редхат, в моих глазах, - враг "без пяти минут", готовый в любой момент стать врагом полноценным. ...а хомячки продолжают радоваться загрузке за пять сек с помощью системд и думать, что все делается для них любимых.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	49. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от SCIF (ok) on 18-Июл-12, 05:36
	Теория заговора. Форкайте и наслаждайтесь, кто не даёт-то?? Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку. Сами дистры открыты. Центось же существует ;) Поменьше читайте «разоблачения, скандалы, интриги, расследования» и побольше думайте головой и смотрите вокруг.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	51. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-12, 07:18
	твои форки никому не нужны. ты просто не будешь успевать за апстримом и их новым кулфичами.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	52. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 08:07
	давайте дополним. RedHat не брезгует делать vendor lock. Но делает это более элегантно что ли чем MS.. Она просто не распространяет драйвера на железо в открытый досуп, они доступны только под подписке и только в бинарном виде и только собранные под ее ядро. А хомячки должны выступать бесплатным тестерами на пакетах альфа качества в федоре. Потом же их пересоберут правильно, закроют бинарные пакеты и окружение сборки - и будут вам продавать за деньги. А вы будете вставлять себе этот анальный зонд и радоваться - какой хороший RedHat.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	61. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Viliar (ok) on 18-Июл-12, 10:52
	Можно чуть по-подробнее? В идеале ссылки "на почитать".
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	67. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Crazy Alex (ok) on 18-Июл-12, 15:01
	Думаю, не дождётесь :-)
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	81. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от gns (ok) on 18-Июл-12, 19:53
	Я думаю, прежде чем мы продолжим обсуждение, Вы предоставите пруфлинки на тему закрытого исходного кода пакетов редхат.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	91. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 19-Июл-12, 10:06
	я думаю вас не затруднит зайти в RHN и посмотреть на бинарные пакеты с драйверами. Для которых не всегда есть src.rpm. Или прошивки для raid, sas, wifi карты - которые отличаются от того что идет с ядром.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	93. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от gns (ok) on 19-Июл-12, 11:14
	> я думаю вас не затруднит зайти в RHN и посмотреть на бинарные > пакеты с драйверами. > Для которых не всегда есть src.rpm. Если драйвера GPLные, то есть. Если проприетарные, то нет. > Или прошивки для raid, sas, wifi карты - которые отличаются от того > что идет с ядром. Это не совсем то, что утверждалось ранее каким-то из анонимов. Напомню, текст был такой: "А хомячки должны выступать бесплатным тестерами на пакетах альфа качества в федоре. Потом же их пересоберут правильно, закроют бинарные пакеты и окружение сборки - и будут вам продавать за деньги." Разве в федоре есть исходники проприетарных драйверов и фирмварей?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	85. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 23:57
	> пятибаксовыми Уважаемые зажравшиеся москвичи. Прошу понять одну вещь. Вокруг вас расположено огромное государство, членами которого вы являетесь. И в нём принято деньги считать в собственной государственной валюте - рублях. Договорились?
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	78. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Stax (ok) on 18-Июл-12, 17:35
	Какие именно драйверы, вы о чем? Исходный код _всех_ драйверов, что идут в ядре RHEL доступен в src.rpm ядра - со всеми фиксами и патчами, которые редхат использует и именно в том виде, в котором они компилируются в конечный продукт. Никаких драйверов вне ядра в редхате нет (есть non-free kmod'ы в дополнительном репозитории для некоторых редких устройств, но я ни на одном сервере ни разу не сталкивался с необходимостью их применения). Это легко доказывается тем, что ядро в SL и Centos, собираемых полностью из сорцов поддерживает все то же железо, что и RHEL.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	92. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 19-Июл-12, 10:08
	> Какие именно драйверы, вы о чем? > Исходный код _всех_ драйверов, что идут в ядре RHEL доступен в src.rpm > ядра - со всеми фиксами и патчами, которые редхат использует и > именно в том виде, в котором они компилируются в конечный продукт. через 2 месяца после того как выложен исходник. > Никаких драйверов вне ядра в редхате нет (есть non-free kmod'ы в дополнительном > репозитории для некоторых редких устройств, но я ни на одном сервере > ни разу не сталкивался с необходимостью их применения). вы определитесь - или их нету, или non-free kmod все таки есть? В моем случае - потребовалось устанавливать их дрова для ipw2200 wifi card - ибо с штатными сети не было. а ноутбук без wifi выглядит как-то странно.. Отдельно были правильные драйвера для aac raid - с которыми он таки работал с нормальными iops. а не тот который в ядре.. И еще стопка всякого.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Июл-12, 03:02
	> Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку. Из перечисленного она более-менее интересна разве что для SLES. А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта новость -- интересна.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	95. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 19-Июл-12, 12:36
	> А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта > новость -- интересна. Чем, что в монстра протащили очередную галочку? Попадет-ли это чудо в RHEL и в каком виде (~= когда?) - вот что интересно (и сурьезно).
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	96. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Июл-12, 12:53
	>> хотя конкретно эта новость -- интересна. > Чем, что в монстра протащили очередную галочку? Ещё одной юзерспейсной ручкой к полезному ядерному механизму, хотя место действительно в самих сервисах.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	89. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Игорь (??) on 19-Июл-12, 08:16
	>Теория заговора Это не теория заговора, а практика борьбы за рынок >Форкайте и наслаждайтесь, кто не даёт-то?? Системд не надо форкать. Он того не стоит, имхо. Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo >Сами дистры открыты Видимо именно в силу "открытости" ни в одном из них системд нельзя удалить. Можно только отключить, но в системе он все равно будет присутствовать >побольше думайте головой и смотрите вокруг Я думаю, что не Вам меня учить, уважаемый. Следите лучше за своей головой и поменьше пропагандируйте ПО, спроектированное инженером-программистом коммерческой компании, для целей (какая неожиданность!) получения максимальной прибыли этой самой компании.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	90. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 19-Июл-12, 09:49
	> Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo "после 15-ти работы и трех сертификатов соответствия" не суметь установить sysvinit-init ? оригинально.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	97. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от jOKer (ok) on 19-Июл-12, 16:04
	Слушай, Агент, а ты уверен что ты 007? А то по ходу (и по стилю тоже!) канешь на "агент РедХата"! И да, (к твоему сведению) по зависимостям systemd тебе не удалить. Никак. Абыдно, слюшай, да?
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	98. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 19-Июл-12, 16:13
	> И да, (к твоему сведению) по зависимостям systemd тебе не удалить. Никак. > Абыдно, слюшай, да? ну и что ? мешать он не будет.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	99. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от jOKer (ok) on 19-Июл-12, 16:17
	А не приходило в голову что если две системы конкурирует, и одну нельзя удалить, а она от корпорации заинтересованной в получении максимального дохода, то это называется вендор лок, а? О, да! - изящный такой, но зонд. Анальный.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	100. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 19-Июл-12, 16:34
	> А не приходило в голову что если две системы конкурирует, и одну > нельзя удалить, а она от корпорации заинтересованной в получении максимального дохода, systemd нельзя удалить не потому, что он реально нужен, а из-за неправильной сборки пакетов. например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость. ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid распилить пакет на два: один с обычным инитскриптом, а во второй положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid. аналогичная история с apache2 и другими "зависимыми от страшного systemd" пакетами. исключение у себя я нашёл только одно: mpd слинкован с libsystemd-daemon, и никто не знает зачем. но, разумеется, багрепортов писать никто не будет, поскольку строить теории заговора и устанавливать gentoo существенно проще и интереснее, чем ковыряться в пакетах, выясняя откуда вылезает лишняя зависимость.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	101. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от jOKer (ok) on 19-Июл-12, 16:53
	>[оверквотинг удален] > что автоматически порождает зависимость. > ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid > распилить пакет на два: один с обычным инитскриптом, а во второй > положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid. > аналогичная история с apache2 и другими "зависимыми от страшного systemd" пакетами. исключение > у себя я нашёл только одно: mpd слинкован с libsystemd-daemon, и > никто не знает зачем. > но, разумеется, багрепортов писать никто не будет, поскольку строить теории заговора и > устанавливать gentoo существенно проще и интереснее, чем ковыряться в пакетах, выясняя > откуда вылезает лишняя зависимость. На самом деле это совсем не так. Во-первых багрепорты не пишутся на действия майентейнеров. Багрепорты (как следует из названия) - это сообщения об ошибках в программе. В данном же случае - это не сбой в ПО. Это раз. Генту устанавливать существенно тяжелее. Собсно, поэтому и существуют майентейнеры, которые  (по идее) должны на себя взять труд формирования платформы, дамы разрабы и интеграторы не заморачивались. Это два. В-третьих, во всех (я подчеркиваю ВО ВСЕХ) ведущих дистрах лапка Редхата чувствуется весьма и весьма. Та же опенсусе давно и прочно бредет в кильватере редхата. И у них это называется "дружеской помощью" Все! - sapiens sat, - вот когда мне сусеводы скажут: "Хорошо - можете выбирать между systemd и openrc, и между network manager и wicd" - я подумаю о возврате на мой все еще самый любимый дистр, а пока генту - это наше все.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	102. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 19-Июл-12, 17:24
	> На самом деле это совсем не так. Во-первых багрепорты не пишутся на > действия майентейнеров. Багрепорты (как следует из названия) - это сообщения об > ошибках в программе. В данном же случае - это не сбой > в ПО. Это раз. на самом деле всё ровно так и есть. багрепорты (как следует из названия), это сообщения об ошибках. в том числе, и об ошибках упаковки. > Собсно, поэтому и существуют майентейнеры, которые >  (по идее) должны на себя взять труд формирования платформы, дамы > разрабы и интеграторы не заморачивались. Это два. они и берут на себя труд. но предугадать потребности всех не могут. именно для этого и придуманы системы обратной связи в виде разного рода багтрекеров. > В-третьих, во всех (я подчеркиваю ВО ВСЕХ) ведущих дистрах лапка Редхата чувствуется > весьма и весьма. Та же опенсусе давно и прочно бредет в > кильватере редхата. И у них это называется "дружеской помощью" та же опенсусе, давно и прочно, не бредёт ни в чьём кильватере, а занимается развитием своего дистрибутива и сопутствующих сервисов. > Все! - sapiens sat, - вот когда мне сусеводы скажут: "Хорошо - > можете выбирать между systemd и openrc, и между network manager и > wicd" выбирать можно и сейчас.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	103. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от jOKer (ok) on 19-Июл-12, 17:51
	>на самом деле всё ровно так и есть. багрепорты (как следует из названия), это сообщения об ошибках. в том числе, и об ошибках упаковки. Это чистая теория. А на практике (типичная ситуация) так: Я, в багрепорте на треке джанги - "Уважаемые, у меня есть очевидная ошибка, связанная с поддержкой СУБД Postgre Вашим проектом. Вот мой код, а вот мои функциональные тесты, благодаря которым эта ошибка и выявилась." Дежурный майентенер проекта - "Я  не могу вашу ошибку повторить у себя.... Правда у меня не постгри, а другая СУБД, но я думаю, что к коду нашего проекта это не имеет отношения" И все! Мой репорт закрыт. Патчи накладываю по сей день. А теперь, - внимание!, - вопрос: могу я претендовать на объективность майентейнера сусе, при условии что репорт - это репорт не на код, а на самого маентейнера, и при условии что этот майентейнер до кучи штатный сотрудник редхат?!! > но предугадать потребности всех не могут А это и не надо. Достаточно предоставить возможность выбора. >та же опенсусе, давно и прочно, не бредёт ни в чьём кильватере, а занимается развитием своего дистрибутива и сопутствующих сервисов. Бу-гы-га-га. Я даже комментить это высказывание не буду! >выбирать можно и сейчас. Нет, это не всегда возможно. В том же ясте в сусе есть возможность  настройки только одного сетевого менеджера (понятно какого?). А что бы никто не трепыхался в общесистемный (уровнем ниже) конфиг ввели ряд опций network manager. Я потратил не один день что бы установить свой менеджер. И я думаю, что новичкам это не по силам. И не только новичок не сумеет красиво (а хоть бы и НЕ красиво!) удалить systemd и тот логер от Поттерига. Это реально не реально!((((
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	105. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Июл-12, 18:24
	> например, 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" тогда уж...
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	107. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 20-Июл-12, 09:11
	> IMHO лучше бы тогда отпилить systemd-base какой с %dir /lib/systemd/system/. лучше, конечно. распилить на -base, -libs и, собственно, сам systemd. но тогда страдания на тему "у меня в системе есть кусок systemd" будут продолжаться бесконечно, поскольку на содержимое пакетов никто не смотрит :) > PS re #103: по таким поводам вполне вешаются багрепорты-фичреквесты, ну и "sapienti" > тогда уж... багрепорты не нужны, ведь мантейнер может и отказать.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	108. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Michael Shigorin (ok) on 20-Июл-12, 11:42
	> но тогда страдания на тему "у меня в системе есть кусок systemd" будут > продолжаться бесконечно, поскольку на содержимое пакетов никто не смотрит :) Думал добавить, но не нашёлся с формулировкой (кроме "rpm -qa") -- спасибо :) > багрепорты не нужны, ведь мантейнер может и отказать. О да, они такие.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	110. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от qux (ok) on 22-Июл-12, 16:14
	> например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость. Кто вам такое сказал? А если acpid.service будет всеми проигнорирован (потому что systemd в системе не будет), а acpid будет запущен другим способом (хоть руками, хоть через скрипт sysv) — то от этого что-то пойдет не так? И дополнительных движений почти не надо. > ничто (кроме отсутствия багрепорта от заинтересованных лиц) не мешает мантейнеру acpid распилить пакет на два: один с обычным инитскриптом, а во второй положить только /lib/systemd/system/acpid.service и прописать зависимости на acpid. Не нужно, почему — см. выше.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	111. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007_ on 22-Июл-12, 16:38
	>> например, acpid зависит от systemd потому, что в пакете acpid лежит /lib/systemd/system/acpid.service, что автоматически порождает зависимость. > Кто вам такое сказал? вы имеете какое-нибудь представление о том, как формируются зависимости rpm пакетов ?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	112. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от qux (ok) on 22-Июл-12, 16:50
	Какое-нибудь имею. Если я захочу положить в пакет случайный каталог с какими-то текстовыми файлами (пускай *.service) и не пропишу явно зависимости от systemd — у меня не выйдет? Или пакет сам эту зависимость получит?
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	113. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от agent_007_ on 22-Июл-12, 18:27
	> Какое-нибудь имею. Если я захочу положить в пакет случайный каталог с какими-то > текстовыми файлами (пускай *.service) и не пропишу явно зависимости от systemd > — у меня не выйдет? Или пакет сам эту зависимость получит? случайный каталог - на здоровье. каталог, который предоставляется пакетом systemd, автоматически родит зависимость на пакет systemd.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	115. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от qux (ok) on 22-Июл-12, 19:11
	Интересно, не знал. Но даже в таком случае не нужно резать все пакеты на два (к тому же как сказать юзерам, что если у них стоит systemd, они должны ставить acpid-systemd, а не просто acpid?). Можно сделать отдельный пакет systemd-filesystem, где будет всего лишь несколько пустых каталогов (так вроде бы некоторые и делают), и пусть все эти acpid'ы & Ko зависят от него.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	117. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от agent_007 (ok) on 23-Июл-12, 09:03
	> Можно сделать отдельный пакет systemd-filesystem, где будет всего лишь несколько > пустых каталогов (так вроде бы некоторые и делают), и пусть все > эти acpid'ы & Ko зависят от него. не можно, а нужно (и здесь это уже обсудили). и даже обсудили почему было предложено распилить не systemd, а "зависимые" от него пакеты :)
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	114. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Michael Shigorin (ok) on 22-Июл-12, 18:35
	>> например, acpid зависит от systemd потому, что в пакете acpid лежит >> /lib/systemd/system/acpid.service, что автоматически порождает зависимость. > Кто вам такое сказал? Например, http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=s...
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	116. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от qux (ok) on 22-Июл-12, 19:13
	> Например, http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=s... Да, спасибо, уже ткнули. Хотя имхо все равно всё не так печально, выше описал.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	104. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Июл-12, 18:22
	> Слушай, Агент, а ты уверен что ты 007? Достаточно: http://lists.altlinux.org/pipermail/community/2005-May/35311... :)
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	8. "В Systemd реализована поддержка изоляции системных вызовов д..."	+4 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 22:32
	Я на 99% уверен, что там отдельная утилита. systemd - это не один монолитный бинарник. В арче вон systemd частично используется, но init остался старый.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	16. "В Systemd реализована поддержка изоляции системных вызовов д..."	+5 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:13
	> Я на 99% уверен, что там отдельная утилита. systemd - это не > один монолитный бинарник. В арче вон systemd частично используется, но init > остался старый. Да, в основе systemd лежит модульная архитектура, и все, что выходит за рамки задач init, оформлено отдельными бинарниками (причем systemd можно собрать практически без всего, неотключаемы только udevd и journald). Но к данному случаю это не относится. Поддержка seccomp входит в настройку окружения запускаемых процессов служб, т.е. должна быть реализована именно в init. Конечно, можно наплодить бинарников, которые будут устанавливать по одной настройке и execать друг друга по цепочке, но это чистый оверхед и бред сивой кобылы. Подобных настроек в systemd - несколько десятков, вызывать 20 бинарников по цепочке задолбаешься.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 17-Июл-12, 23:27
	> Но к данному случаю это не относится. Поддержка seccomp входит в настройку > окружения запускаемых процессов служб, т.е. должна быть реализована именно в init. Ну-ну...  Как и rlimits и еще куча всякого добра.  А вот в sysv init ради использования всего этого оказалось ненужным городить невнятный монолит. > Конечно, можно наплодить бинарников, которые будут устанавливать по одной настройке и execать > друг друга по цепочке, но это чистый оверхед и бред сивой кобылы. Подобных настроек в systemd - несколько десятков, вызывать 20 бинарников по цепочке задолбаешься. *Пока* несколько десятков.  Но нет - будем экономить на спичках и плодить новые опции, вместо того чтобы один раз спроектировать софт раз и навсегда. Проблема в том, что systemd "запланирован" не как очередная погремушка для десктопа - а как замена init.  С учетом того, что базовый функционал (то самое "практически без всего") совершенно никак не определен - выглядит это смешно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	28. "В Systemd реализована поддержка изоляции системных вызовов д..."	+3 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:37
	> Ну-ну...  Как и rlimits и еще куча всякого добра.  А > вот в sysv init ради использования всего этого оказалось ненужным городить > невнятный монолит. Ага. В sysvinit это делается через задницу. Достаточно сравнить работу админа, перед которым стоит задача выставить все ключевым службам rlimits, capabilites и прочие. В случае с systemd, админ просто редактирует конфиги юнитов и кладет их в /etc. В случае с sysvinit, админ вынужден лично править все init-скрипты, а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты. Не говоря уже о том, что куча фич типа PrivateTmp, PrivateNetwork и DeviceAllow пока что не реализуема средствами sysvinit. > *Пока* несколько десятков.  Но нет - будем экономить на спичках и > плодить новые опции, вместо того чтобы один раз спроектировать софт раз > и навсегда. systemd изначально был спроектирован раз и навсегда. Наращивание функциональности - это количественное изменение, а не смена архитектуры. Понятие юнита никто и никогда не пересматривал - просто вводились новые типы юнитов и настройки для них. > С учетом того, что базовый функционал (то самое "практически без всего") совершенно никак не определен - выглядит это смешно. Базовая функциональность systemd (который init) - всего лишь управление юнитами. Не больше и не меньше.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от myhand (ok) on 18-Июл-12, 00:02
	> Ага. В sysvinit это делается через задницу. Для начала: непосредственно в sysvinit это *не делается*. > В случае с systemd, админ просто редактирует конфиги юнитов и кладет их в /etc. Не поверите, все точно также.  Только "конфиги ... в /etc" - в т.ч. и скрипты, запускаемые sysvinit.  Все это  в достаточной степени гибко - и может быть сколь угодно "заоптимизировано", в смысле простоты настройки. > а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты. Лечите руки или меняйте дистрибутив - у нормальных людей ничего нигде не затирает. > systemd изначально был спроектирован раз и навсегда. Ну тогда твердая двойка за подобное "проектирование". > Базовая функциональность systemd (который init) - всего лишь управление юнитами. Не больше и не меньше. Упс, больше.  Вспомните предмет темы - это не модуль, не плагин.  Это никак не откручивается от "управления юнитами", как и стопицот других финтифлюшек.  Как минимум - пока.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	50. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от www2 (??) on 18-Июл-12, 05:59
	>В случае с sysvinit, админ вынужден лично править все init-скрипты, а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты. Это где такое? В Debian если контрольная сумма чего-то в /etc не совпадает с таковой из предыдущего пакета, то появляется предложение - оставить имеющуюся версию, установить новую, посмотреть различия.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	69. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от анонимаус on 18-Июл-12, 15:56
	хых, да и в rpm тоже самое. Если программеры не дураки, то все инит скрипты маркируются как конфиг файлы, и при обновлении они не затираются, но не все анонимы об этом знают.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	27. "В Systemd реализована поддержка изоляции системных вызовов д..."	–1 +/–
	Сообщение от anonymous (??) on 17-Июл-12, 23:31
	>причем systemd можно собрать практически без всего, неотключаемы только udevd и journald Устаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev без systemd http://www.mail-archive.com/systemd-devel@lists.freedes...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	29. "В Systemd реализована поддержка изоляции системных вызовов д..."	+2 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:41
	> Устаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev > без systemd http://www.mail-archive.com/systemd-devel@lists.freedes... Вы, наверное, по аглицки не разумеете, и потому ссылками наугад кидаетесь. udev можно собрать без systemd. А вот systemd без udev - нельзя, как я и говорил. Разумеется, причина проста. udevd без systemd имеет смысл (например, initrd или альтернативная система инициализации), а systemd без udevd - не имеет (у udev нет полноценных аналогов).
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "В Systemd реализована поддержка изоляции системных вызовов д..."	–3 +/–
	Сообщение от anonymous (??) on 17-Июл-12, 23:52
	>udev можно собрать без systemd Нельзя.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	88. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от anoser_anon on 19-Июл-12, 06:19
	Можно же. Смотри udev-186.ebuild
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	10. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от develop7 (ok) on 17-Июл-12, 22:50
	> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение Ну так оформляйте, делов-то.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	70. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 18-Июл-12, 16:19
	> Ну так оформляйте, делов-то. ага, написать фактически замену systemd.  и только.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Часть нити удалена модератором

	76. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 18-Июл-12, 17:31
	> А что, слабо? Написать действительно хорошую альтернативу sysvinit?  Да, довольно непросто. Просто в силу того, что ее сперва нужно *придумать* и спроектировать.  Поделка поттеринга тут слабо поможет. > просто невыносимо требуется открытие сорцов? Да нет.  Быдлокодить любой дурак умеет.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	80. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от develop7 (ok) on 18-Июл-12, 18:16
	>> А что, слабо? > Написать действительно хорошую альтернативу sysvinit?  Да, довольно непросто. > Просто в силу того, что ее сперва нужно *придумать* и спроектировать. Поделка поттеринга тут слабо поможет. «Show me the code»© — тогда и поговорим.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	77. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от develop7 (ok) on 18-Июл-12, 17:34
	>> Ну так оформляйте, делов-то. > ага, написать фактически замену systemd.  и только. Ну вкрутите в sysvinit тогда.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	79. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 18-Июл-12, 18:01
	> Ну вкрутите в sysvinit тогда. "Вкрутить" (как сделано в данном примере, кстати) - плохая инженерная практика (Big ball of mud).  О чем, собственно, и речь. sysvinit не стремятся научить кофе варить - и это правильно.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	11. "В Systemd реализована поддержка изоляции системных вызовов д..."	+2 +/–
	Сообщение от h31 (ok) on 17-Июл-12, 22:52
	Потому что там ограничения на уровне целых сервисов, а не бинариков. Вполне логичная фича для менеджера запуска.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от кевин on 17-Июл-12, 23:00
	эм секомп фильтры существуют отдельно надо используй где угодно, новость о том что теперь можно задавать эти правила прямо в юнитах системд, а не гдето ещё.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "В Systemd реализована поддержка изоляции системных вызовов д..."	+4 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:06
	> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение Можно. Но этого пока никто не сделал. Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения среды исполнения удобнее настраивать именно в нем.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	53. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 08:13
	>> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение > Можно. Но этого пока никто не сделал. > Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень > удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения > среды исполнения удобнее настраивать именно в нем. теперь попытаемся подумать. Если apache запускается из systemd - все есть, а если я его вдруг рестартовал руками - я потерял эту хваленую защиту. Может потому AppAmmor / Selinux изначально делался отдельными средствами? Что бы при любом раскладе метки контроля доступа были применены ?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	58. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 09:49
	Глупенький. Ты хоть раз попробуй руками запустить. Защита это далеко не самое страшное что потеряешь
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	59. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 09:52
	Ты даже в несвоей винде службы руками не запускаеш
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	19. "В Systemd реализована поддержка изоляции системных вызовов д..."	–1 +/–
	Сообщение от filosofem (ok) on 17-Июл-12, 23:17
	>Думается, что она была бы востребована не только и не столько в systemd Она и не имеет никакого отношения к systemd.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	23. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:23
	> Она и не имеет никакого отношения к systemd. Тем не менее, пока она поддерживается только в systemd.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	26. "В Systemd реализована поддержка изоляции системных вызовов д..."	–2 +/–
	Сообщение от Аноним (??) on 17-Июл-12, 23:29
	> Тем не менее, пока она поддерживается только в systemd. Ну так правильно, редхат, ынтерпрайз, безопасность, selinux, теперь вот это. А больше оно никому и не сдалось.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	36. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от masha (ok) on 18-Июл-12, 00:27
	Для галочки поддержка есть. Срач на эту тему начать можно. Полезность без поддержки со стороны запускаемого приложения близка к 0.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от filosofem (ok) on 18-Июл-12, 00:56
	>Тем не менее, пока она поддерживается только в systemd. 1. Это не поддержка, а деревянная запускалка. В чем ее смысл если есть SELinux и AppArmor? 2. Читай хотя бы новость до конца что ли.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	56. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от openclocker (ok) on 18-Июл-12, 09:12
	Уже есть. Те же АппАрмор и СЕЛинукс. Но т у сабжу уровень пониже, этим он лучше.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

18. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
Сообщение от Аноним (??) on 17-Июл-12, 23:16
Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.html Что характерно, практически все описанные там технологии основаны на уникальных фичах ядра Linux, но никто, кроме systemd и LXC, их не использует. То ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них никогда не слышали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "В Systemd реализована поддержка изоляции системных вызовов д..."	+4 +/–
	Сообщение от свищ on 18-Июл-12, 00:31
	> Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.html > Что характерно, практически все описанные там технологии основаны на уникальных фичах ядра > Linux, но никто, кроме systemd и LXC, их не использует. То > ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них > никогда не слышали. без сомнений и, к сожалению, без иронии - второе. вы почитайте, что тут ретрограды всея локалхостов пишут, в дискуссиях при попытках обратить внимание на суть проблем, их аргументация переводится на уровень "у вас руки кривые", что считают мощнейшим из доводов, и, как и полагается прямым как рельса индивидумам, в глупости своей честны и фанатично непоколебимы
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	71. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от myhand (ok) on 18-Июл-12, 16:24
	any feature that is sold with ".. and systemd can use this fox Xyz", is a *misfeature* in my opinion. (c) тот самый ретроград, по сравнению с которым ты ничто. PS: А вообще, в lkml довольно негативное отношение к systemd.  "Фанаты" - редхетовцы, да и те плюются.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	48. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Crazy Alex (ok) on 18-Июл-12, 05:25
	Просто оно не так сильно нужно, как некоторые тут кричат. При этом требует неких (иногда, как с настройкой selinux - больших) усилий.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "В Systemd реализована поддержка изоляции системных вызовов д..."	+11 +/–
Сообщение от Anonplus on 17-Июл-12, 23:22
Кто бы что ни говорил про Поттеринга, а штука-то годная и нужная.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от свищ on 18-Июл-12, 00:39
	без всякого зазрения утверждаю, поттеринг - замечательный инженер
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	57. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-12, 09:20
	Как инженер - не очень, но идеи у него правильные.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	74. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Аноним (??) on 18-Июл-12, 17:08
	> Как инженер - не очень, но идеи у него правильные. В чем? Вот скажите-ка мне, кто мешает вам, таким красивым и умным, имея сорцы ядра, ограничить момент запуска cервисов лишь избранными вызовами? И наслаждаться невозможностью малвари прошмыгнуть в момент, когда сервисы стартуют? М? BTW, все это уже было лет 8 назад в Solaris. Конкретно - в SMF. И называлось "RBAC" - Role Based Access Control, причем оно прекрасно интегрировалось с SMF. Велосипеды, велосипеды...
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

30. "В Systemd реализована поддержка изоляции системных вызовов д..."	+2 +/–
Сообщение от iZEN (ok) on 17-Июл-12, 23:41
Это просто прекрасно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	75. "В Systemd реализована поддержка изоляции системных вызовов д..."	+2 +/–
	Сообщение от Аноним (??) on 18-Июл-12, 17:08
	> Это просто прекрасно. У тебя ж геморроя нет? Это же прекрасно!
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

47. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
Сообщение от jOKer (ok) on 18-Июл-12, 04:24
Timeo Danaos et dona ferentes Это не говоря уже о склонности к комбайностроению и неряшливом программировании
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
Сообщение от Anoynymous on 18-Июл-12, 10:25
Я вот чего не пойму. В общем виде seccomp filter разработан для прикладных программистов, чтобы последние могли обезопасить свои сервисы (как это сделали разработчики OpenSSH и vsftpd). Так зачем же Поттеринг тянет в свое поделие все, что красиво блестит? Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux (для случаев, когда разработчик сервиса не позаботился о безопасности своей программы). В чем смысл втянуть в мегакомбайн все разработки, на сколько хороши бы они не были? Думаю, скоро мы увидим новости, что системд готов заменить нам и SELinux вместе с AppArmor и всем остальным...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	65. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Crazy Alex (ok) on 18-Июл-12, 12:38
	Ну, очевидный ответ - потому что прикладные програмисты не торопятся использовать эту штуку, а так можно для их программ реализовать нужные ограничения снаружи. Но вне вот интересно - а что,  SELinux/AppArmor этого не умеют, что надо именно эту механику использовать? Если что - я с ними не знаком совершенно, ибо надобности нет.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	109. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Kibab (ok) on 20-Июл-12, 12:25
	Так вот надо менять стиль написания программ, а не тянуть вещь, предназначенную для защиты приложения от самого себя, в какие-то управляющие демоны. Это мусор, seccomp не для этого делался! Но нет же, пришёл Поттеринг и сделал очередную примочку к своему монстру =)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	66. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от filosofem (ok) on 18-Июл-12, 14:45
	Зато вброс годный. Каменты читал? 95% фанбоев как обычно не поняли о чем речь и в чем цимес seccomp filters, но по привычке принялись восхвалять Леннарда. 50% вообще поняли, что Поттеринг изобрел seccomp filters. =) >Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux Не подобный, а на несколько порядков защищеннее, гибче и удобнее. К примеру если процесс запустят не через systemd, то фильтры не применятся, в отличие от SELinux, AppArmor или нормальных реализаций seccomp filters, которые работают в любом случае.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	68. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
	Сообщение от Crazy Alex (ok) on 18-Июл-12, 15:08
	Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload и подобную механику. Уж всяко не хуже systemd будет.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	84. "В Systemd реализована поддержка изоляции системных вызовов д..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июл-12, 21:36
	> Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для > любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload > и подобную механику. Уж всяко не хуже systemd будет. Об чем и спич. В Юниксах это существовало сто лет назад. И кто изобретатель велосипедов с восемнадцатиугольными колесами тут?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

86. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
Сообщение от Kibab (ok) on 19-Июл-12, 01:09
Итак, Леннарт извратился и затащил фичу, которая изначально проектировалась для использования самими приложениями, в свой менеджер инициализации. То, что приложение само может лучше решить, какие свои части как защищать (например, форкнувшись и по-разному ограничив права каждого чайлда), осталось для Поттеринга неважной деталью. В итоге получили аналог SELinux, но реализованный через seccomp filters, которые вообще не отличаются толковой реализацией. Что же, посмотрим, насколько сия кривая поделка проникнет в продакшен и сколько народу не отключат её после первого фоллаута.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

106. "В Systemd реализована поддержка изоляции системных вызовов д..."	+/–
Сообщение от vi on 19-Июл-12, 19:08
Помнится, в те "старые добрые времена", когда SELinux была волне, ходили такие рассказы: сплоит пробившийся на уровне ядра первым делом проверял SELinux и вырубал его сразу же, потом делал все что ему необходимо! Ну естественно же, все развивается по спирали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема