The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В Systemd реализована поддержка изоляции системных вызовов для запускаемых сервисов

17.07.2012 21:35

Леннарт Поттеринг (Lennart Poettering) сообщил о реализации поддержки технологии "seccomp filter" в системном менеджере systemd, что позволяет обеспечить изоляцию системных вызовов для запускаемых через systemd процессов. Для создания изолированных окружений используется простой синтаксис определения допустимых системных вызовов, без необходимости непосредственной модификации самих приложений. Указанная возможность может быть активирована при использовании ядра Linux 3.5, релиз которого ожидается на следующей неделе.

В качестве примера помещения процесса в sandbox-окружение приводятся следующие настройки:


   [Service]
   ExecStart=/bin/echo "I am in a sandbox"
   SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write

В общем виде принцип работы seccomp filter сводится к ограничению доступа к системным вызовам, при этом логика выставляемых ограничений задаётся на уровне защищаемого приложения, а не через задание внешних ограничений, как в случае AppArmor или SELinux. В код программы добавляется структура с перечнем допустимых системных вызовов (например, ALLOW_SYSCALL) и реакции в случае несовпадения (например, KILL_PROCESS). Доступ к системным вызовам определяется в виде правил, оформленных в BPF-представлении (Berkeley Packet Filter), которое получило распространение в системах фильтрации сетевых пакетов.

Система seccomp filter позволяет реализовывать достаточно сложные правила доступа, учитывающие передаваемые и возвращаемые аргументы. Программа сама определяет какие системные вызовы ей необходимы и какие параметры допустимы, все остальные системные вызовы блокируются, что позволяет ограничить возможности атакующего в случае эксплуатации уязвимости в защищённом при помощи seccomp приложении. Возможность задания фильтров аргументов позволяет также защититься от большинства атак, эксплуатирующих уязвимости в системных вызовах. Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN, sock_sendpage и sys_tee, успешно блокируются при надлежащем использовании seccomp. В настоящее время поддержка seccomp filter реализована в таких популярных серверных приложениях, как OpenSSH и vsftpd, патчи с поддержкой seccomp filter уже поставляются в ядре Linux из состава Ubuntu 12.04.

  1. Главная ссылка к новости (https://plus.google.com/115547...)
  2. OpenNews: Релиз OpenSSH 6.0
  3. OpenNews: Релиз FTP сервера vsftpd 3.0.0 с поддержкой нового sandbox-режима
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/34352-seccomp
Ключевые слова: seccomp, systemd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (92) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Сергей (??), 22:07, 17/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Может кто-нибудь обьяснит мне, тупому, зачем это надо...
     
     
  • 2.5, Аноним (-), 22:18, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Чтобы ограничить возможности в случае успешной атаки на приложение.
     
  • 2.21, Anonplus (?), 23:20, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN, sock_sendpage и sys_tee, успешно блокируются при надлежащем использовании seccomp.

    У злоумышленника будет меньше прав и возможностей при атаке и использовании уязвимостей.

     
  • 2.64, mma (?), 12:12, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >зачем это надо...

    Чтобы редхату не баги в софте искать а политики писать. Тупиковый путь для майнстрима IMHO. Так только для специфичных систем где требуется сертификация по определенным уровням.

     

  • 1.4, Аноним (-), 22:12, 17/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение
     
     
  • 2.7, anonymous (??), 22:26, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение

    Надо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах.

     
     
  • 3.15, Аноним (-), 23:08, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Надо протолкнуть systemd. RedHat крайне не заинтересован в альтернативах.

    Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие.
    И знаете, в чем-то он прав.

     
     
  • 4.33, anonymous (??), 00:13, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Конечно. Давеча Инго Молнар говорил, что разработчикам ядра надо равняться на одну базовую систему (читай glibc & systemd & util-linux), а то поддержка зоопарка несовместимых альтернатив сильно тормозит развитие.

    Ты это говоришь так, будто в ядре специально держат костыли для всех инитов.

     
  • 3.42, Игорь (??), 02:19, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Именно так Причем надо принимать во внимание несколько моментов - Нынешний в ... большой текст свёрнут, показать
     
     
  • 4.49, SCIF (ok), 05:36, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теория заговора. Форкайте и наслаждайтесь, кто не даёт-то?? Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку. Сами дистры открыты. Центось же существует ;) Поменьше читайте «разоблачения, скандалы, интриги, расследования» и побольше думайте головой и смотрите вокруг.
     
     
  • 5.51, Аноним (-), 07:18, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    твои форки никому не нужны. ты просто не будешь успевать за апстримом и их новым кулфичами.
     
  • 5.52, Аноним (-), 08:07, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    давайте дополним.

    RedHat не брезгует делать vendor lock. Но делает это более элегантно что ли чем MS..

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

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

     
     
  • 6.61, Viliar (ok), 10:52, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Можно чуть по-подробнее? В идеале ссылки "на почитать".
     
     
  • 7.67, Crazy Alex (ok), 15:01, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, не дождётесь :-)
     
     
  • 8.81, gns (ok), 19:53, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю, прежде чем мы продолжим обсуждение, Вы предоставите пруфлинки на тему з... текст свёрнут, показать
     
     
  • 9.91, Аноним (-), 10:06, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    я думаю вас не затруднит зайти в RHN и посмотреть на бинарные пакеты с драйверам... текст свёрнут, показать
     
     
  • 10.93, gns (ok), 11:14, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Если драйвера GPLные, то есть Если проприетарные, то нет Это не совсем то, что... текст свёрнут, показать
     
  • 8.85, Аноним (-), 23:57, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемые зажравшиеся москвичи Прошу понять одну вещь Вокруг вас расположено о... текст свёрнут, показать
     
  • 6.78, Stax (ok), 17:35, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Какие именно драйверы, вы о чем?

    Исходный код _всех_ драйверов, что идут в ядре RHEL доступен в src.rpm ядра - со всеми фиксами и патчами, которые редхат использует и именно в том виде, в котором они компилируются в конечный продукт.

    Никаких драйверов вне ядра в редхате нет (есть non-free kmod'ы в дополнительном репозитории для некоторых редких устройств, но я ни на одном сервере ни разу не сталкивался с необходимостью их применения). Это легко доказывается тем, что ядро в SL и Centos, собираемых полностью из сорцов поддерживает все то же железо, что и RHEL.

     
     
  • 7.92, Аноним (-), 10:08, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    через 2 месяца после того как выложен исходник вы определитесь - или их нету, и... большой текст свёрнут, показать
     
  • 5.87, Michael Shigorin (ok), 03:02, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Мандрива, Слес и ещё вагон и маленькая тележка дистров имеют платную поддержку.

    Из перечисленного она более-менее интересна разве что для SLES.

    А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта новость -- интересна.

     
     
  • 6.95, myhand (ok), 12:36, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А в редхате и впрямь какие-то нездравые вещи творятся, хотя конкретно эта
    > новость -- интересна.

    Чем, что в монстра протащили очередную галочку?

    Попадет-ли это чудо в RHEL и в каком виде (~= когда?) - вот что интересно (и сурьезно).

     
     
  • 7.96, Michael Shigorin (ok), 12:53, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> хотя конкретно эта новость -- интересна.
    > Чем, что в монстра протащили очередную галочку?

    Ещё одной юзерспейсной ручкой к полезному ядерному механизму, хотя место действительно в самих сервисах.

     
  • 5.89, Игорь (??), 08:16, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Теория заговора

    Это не теория заговора, а практика борьбы за рынок

    >Форкайте и наслаждайтесь, кто не даёт-то??

    Системд не надо форкать. Он того не стоит, имхо. Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo

    >Сами дистры открыты

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

    >побольше думайте головой и смотрите вокруг

    Я думаю, что не Вам меня учить, уважаемый. Следите лучше за своей головой и поменьше пропагандируйте ПО, спроектированное инженером-программистом коммерческой компании, для целей (какая неожиданность!) получения максимальной прибыли этой самой компании.

     
     
  • 6.90, agent_007 (ok), 09:49, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы его можно было бы просто удалить, то я бы не менял (после 15-ти работы и трех сертификатов соответствия) opensuse на gentoo

    "после 15-ти работы и трех сертификатов соответствия" не суметь установить sysvinit-init ? оригинально.

     
     
  • 7.97, jOKer (ok), 16:04, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Слушай, Агент, а ты уверен что ты 007? А то по ходу (и по стилю тоже!) канешь на "агент РедХата"!

    И да, (к твоему сведению) по зависимостям systemd тебе не удалить. Никак. Абыдно, слюшай, да?

     
     
  • 8.98, agent_007 (ok), 16:13, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну и что мешать он не будет ... текст свёрнут, показать
     
     
  • 9.99, jOKer (ok), 16:17, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А не приходило в голову что если две системы конкурирует, и одну нельзя удалить,... текст свёрнут, показать
     
     
  • 10.100, agent_007 (ok), 16:34, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    systemd нельзя удалить не потому, что он реально нужен, а из-за неправильной сбо... большой текст свёрнут, показать
     
     
  • 11.101, jOKer (ok), 16:53, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален На самом деле это совсем не так Во-первых багрепорты не... большой текст свёрнут, показать
     
     
  • 12.102, agent_007 (ok), 17:24, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    на самом деле всё ровно так и есть багрепорты как следует из названия , это со... большой текст свёрнут, показать
     
     
  • 13.103, jOKer (ok), 17:51, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это чистая теория А на практике типичная ситуация так Я, в багрепорте на тре... большой текст свёрнут, показать
     
  • 11.105, Michael Shigorin (ok), 18:24, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    IMHO лучше бы тогда отпилить systemd-base какой с dir lib systemd system PS ... текст свёрнут, показать
     
     
  • 12.107, agent_007 (ok), 09:11, 20/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    лучше, конечно распилить на -base, -libs и, собственно, сам systemd но тогда с... текст свёрнут, показать
     
     
  • 13.108, Michael Shigorin (ok), 11:42, 20/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Думал добавить, но не нашёлся с формулировкой кроме rpm -qa -- спасибо О ... текст свёрнут, показать
     
  • 11.110, qux (ok), 16:14, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Кто вам такое сказал А если acpid service будет всеми проигнорирован потому чт... текст свёрнут, показать
     
     
  • 12.111, agent_007_ (?), 16:38, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вы имеете какое-нибудь представление о том, как формируются зависимости rpm паке... текст свёрнут, показать
     
     
  • 13.112, qux (ok), 16:50, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Какое-нибудь имею Если я захочу положить в пакет случайный каталог с какими-то ... текст свёрнут, показать
     
     
  • 14.113, agent_007_ (?), 18:27, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    случайный каталог - на здоровье каталог, который предоставляется пакетом system... текст свёрнут, показать
     
     
  • 15.115, qux (ok), 19:11, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, не знал Но даже в таком случае не нужно резать все пакеты на два к ... текст свёрнут, показать
     
     
  • 16.117, agent_007 (ok), 09:03, 23/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    не можно, а нужно и здесь это уже обсудили и даже обсудили почему было предло... текст свёрнут, показать
     
  • 12.114, Michael Shigorin (ok), 18:35, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Например, http git altlinux org gears r rpm git p rpm git a blob f scripts fil... текст свёрнут, показать
     
     
  • 13.116, qux (ok), 19:13, 22/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да, спасибо, уже ткнули Хотя имхо все равно всё не так печально, выше описал ... текст свёрнут, показать
     
  • 8.104, Michael Shigorin (ok), 18:22, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Достаточно http lists altlinux org pipermail community 2005-May 353112 html ... текст свёрнут, показать
     
  • 2.8, Аноним (-), 22:32, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Я на 99% уверен, что там отдельная утилита. systemd - это не один монолитный бинарник. В арче вон systemd частично используется, но init остался старый.
     
     
  • 3.16, Аноним (-), 23:13, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Я на 99% уверен, что там отдельная утилита. systemd - это не
    > один монолитный бинарник. В арче вон systemd частично используется, но init
    > остался старый.

    Да, в основе systemd лежит модульная архитектура, и все, что выходит за рамки задач init, оформлено отдельными бинарниками (причем systemd можно собрать практически без всего, неотключаемы только udevd и journald).

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

     
     
  • 4.24, myhand (ok), 23:27, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну-ну Как и rlimits и еще куча всякого добра А вот в sysv init ради исполь... большой текст свёрнут, показать
     
     
  • 5.28, Аноним (-), 23:37, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ага В sysvinit это делается через задницу Достаточно сравнить работу админа, п... большой текст свёрнут, показать
     
     
  • 6.32, myhand (ok), 00:02, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для начала непосредственно в sysvinit это не делается Не поверите, все точно... большой текст свёрнут, показать
     
  • 6.50, www2 (??), 05:59, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >В случае с sysvinit, админ вынужден лично править все init-скрипты, а потом еще пересобирать пакеты для всех служб (и делать это при каждом обновлении), чтобы они не затирали отредактированные скрипты.

    Это где такое? В Debian если контрольная сумма чего-то в /etc не совпадает с таковой из предыдущего пакета, то появляется предложение - оставить имеющуюся версию, установить новую, посмотреть различия.

     
     
  • 7.69, анонимаус (?), 15:56, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    хых, да и в rpm тоже самое. Если программеры не дураки, то все инит скрипты маркируются как конфиг файлы, и при обновлении они не затираются, но не все анонимы об этом знают.
     
  • 4.27, anonymous (??), 23:31, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >причем systemd можно собрать практически без всего, неотключаемы только udevd и journald

    Устаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev без systemd http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg05287

     
     
  • 5.29, Аноним (-), 23:41, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Устаревшая информация. По ссылке Леннарт и Ко отклонили патч, позволяющий собрать udev
    > без systemd http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg05287

    Вы, наверное, по аглицки не разумеете, и потому ссылками наугад кидаетесь.
    udev можно собрать без systemd. А вот systemd без udev - нельзя, как я и говорил.
    Разумеется, причина проста. udevd без systemd имеет смысл (например, initrd или альтернативная система инициализации), а systemd без udevd - не имеет (у udev нет полноценных аналогов).

     
     
  • 6.31, anonymous (??), 23:52, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >udev можно собрать без systemd

    Нельзя.

     
     
  • 7.88, anoser_anon (?), 06:19, 19/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Можно же. Смотри udev-186.ebuild
     
  • 2.10, develop7 (ok), 22:50, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение

    Ну так оформляйте, делов-то.

     
     
  • 3.70, myhand (ok), 16:19, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так оформляйте, делов-то.

    ага, написать фактически замену systemd.  и только.

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

  • 5.76, myhand (ok), 17:31, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, слабо?

    Написать действительно хорошую альтернативу sysvinit?  Да, довольно непросто.

    Просто в силу того, что ее сперва нужно *придумать* и спроектировать.  Поделка поттеринга тут слабо поможет.

    > просто невыносимо требуется открытие сорцов?

    Да нет.  Быдлокодить любой дурак умеет.


     
     
  • 6.80, develop7 (ok), 18:16, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> А что, слабо?
    > Написать действительно хорошую альтернативу sysvinit?  Да, довольно непросто.
    > Просто в силу того, что ее сперва нужно *придумать* и спроектировать. Поделка поттеринга тут слабо поможет.

    «Show me the code»© — тогда и поговорим.

     
  • 4.77, develop7 (ok), 17:34, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну так оформляйте, делов-то.
    > ага, написать фактически замену systemd.  и только.

    Ну вкрутите в sysvinit тогда.

     
     
  • 5.79, myhand (ok), 18:01, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вкрутите в sysvinit тогда.

    "Вкрутить" (как сделано в данном примере, кстати) - плохая инженерная практика (Big ball of mud).  О чем, собственно, и речь.

    sysvinit не стремятся научить кофе варить - и это правильно.

     
  • 2.11, h31 (ok), 22:52, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что там ограничения на уровне целых сервисов, а не бинариков. Вполне логичная фича для менеджера запуска.
     
  • 2.12, кевин (?), 23:00, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    эм секомп фильтры существуют отдельно надо используй где угодно, новость о том что теперь можно задавать эти правила прямо в юнитах системд, а не гдето ещё.
     
  • 2.14, Аноним (-), 23:06, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение

    Можно. Но этого пока никто не сделал.
    Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения среды исполнения удобнее настраивать именно в нем.

     
     
  • 3.53, Аноним (-), 08:13, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну допустим, штука полезная, но почему нельзя было оформить эту фичу в виде отдельной внешней утилиты? Думается, что она была бы востребована не только и не столько в systemd, а так снова комбайностроение
    > Можно. Но этого пока никто не сделал.
    > Впрочем, наличие встроенной поддержки seccomp непосредственно в initе - как раз очень
    > удачное архитектурное решение. Именно systemd запускает процессы служб, и поэтому ограничения
    > среды исполнения удобнее настраивать именно в нем.

    теперь попытаемся подумать. Если apache запускается из systemd - все есть, а если я его вдруг рестартовал руками - я потерял эту хваленую защиту. Может потому AppAmmor / Selinux изначально делался отдельными средствами? Что бы при любом раскладе метки контроля доступа были применены ?

     
     
  • 4.58, Аноним (-), 09:49, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Глупенький. Ты хоть раз попробуй руками запустить.
    Защита это далеко не самое страшное что потеряешь
     
  • 4.59, Аноним (-), 09:52, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ты даже в несвоей винде службы руками не запускаеш
     
  • 2.19, filosofem (ok), 23:17, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Думается, что она была бы востребована не только и не столько в systemd

    Она и не имеет никакого отношения к systemd.

     
     
  • 3.23, Аноним (-), 23:23, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Она и не имеет никакого отношения к systemd.

    Тем не менее, пока она поддерживается только в systemd.

     
     
  • 4.26, Аноним (-), 23:29, 17/07/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Тем не менее, пока она поддерживается только в systemd.

    Ну так правильно, редхат, ынтерпрайз, безопасность, selinux, теперь вот это. А больше оно никому и не сдалось.

     
  • 4.36, masha (ok), 00:27, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для галочки поддержка есть. Срач на эту тему начать можно. Полезность без поддержки со стороны запускаемого приложения близка к 0.
     
  • 4.40, filosofem (ok), 00:56, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Тем не менее, пока она поддерживается только в systemd.

    1. Это не поддержка, а деревянная запускалка. В чем ее смысл если есть SELinux и AppArmor?
    2. Читай хотя бы новость до конца что ли.

     
  • 2.56, openclocker (ok), 09:12, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уже есть. Те же АппАрмор и СЕЛинукс. Но т у сабжу уровень пониже, этим он лучше.
     

  • 1.18, Аноним (-), 23:16, 17/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.html

    Что характерно, практически все описанные там технологии основаны на уникальных фичах ядра Linux, но никто, кроме systemd и LXC, их не использует. То ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них никогда не слышали.

     
     
  • 2.37, свищ (?), 00:31, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Вообще насчет технологий безопасности в systemd можно почитать http://0pointer.de/blog/projects/security.html
    > Что характерно, практически все описанные там технологии основаны на уникальных фичах ядра
    > Linux, но никто, кроме systemd и LXC, их не использует. То
    > ли портируемость превыше безопасности, то ли просто "крутые Linux-программисты" про них
    > никогда не слышали.

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

     
     
  • 3.71, myhand (ok), 16:24, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    any feature that is sold with ".. and systemd can use this fox Xyz", is a *misfeature* in my opinion. (c) тот самый ретроград, по сравнению с которым ты ничто.

    PS: А вообще, в lkml довольно негативное отношение к systemd.  "Фанаты" - редхетовцы, да и те плюются.

     
  • 2.48, Crazy Alex (ok), 05:25, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Просто оно не так сильно нужно, как некоторые тут кричат. При этом требует неких (иногда, как с настройкой selinux - больших) усилий.
     

  • 1.22, Anonplus (?), 23:22, 17/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Кто бы что ни говорил про Поттеринга, а штука-то годная и нужная.
     
     
  • 2.38, свищ (?), 00:39, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    без всякого зазрения утверждаю, поттеринг - замечательный инженер
     
     
  • 3.57, Аноним (-), 09:20, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как инженер - не очень, но идеи у него правильные.
     
     
  • 4.74, Аноним (-), 17:08, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Как инженер - не очень, но идеи у него правильные.

    В чем? Вот скажите-ка мне, кто мешает вам, таким красивым и умным, имея сорцы ядра, ограничить момент запуска cервисов лишь избранными вызовами? И наслаждаться невозможностью малвари прошмыгнуть в момент, когда сервисы стартуют? М?

    BTW, все это уже было лет 8 назад в Solaris. Конкретно - в SMF. И называлось "RBAC" - Role Based Access Control, причем оно прекрасно интегрировалось с SMF.

    Велосипеды, велосипеды...

     

  • 1.30, iZEN (ok), 23:41, 17/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это просто прекрасно.
     
     
  • 2.75, Аноним (-), 17:08, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это просто прекрасно.

    У тебя ж геморроя нет? Это же прекрасно!

     

  • 1.47, jOKer (ok), 04:24, 18/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Timeo Danaos et dona ferentes

    Это не говоря уже о склонности к комбайностроению и неряшливом программировании

     
  • 1.60, Anoynymous (?), 10:25, 18/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я вот чего не пойму. В общем виде seccomp filter разработан для прикладных программистов, чтобы последние могли обезопасить свои сервисы (как это сделали разработчики OpenSSH и vsftpd). Так зачем же Поттеринг тянет в свое поделие все, что красиво блестит? Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux (для случаев, когда разработчик сервиса не позаботился о безопасности своей программы). В чем смысл втянуть в мегакомбайн все разработки, на сколько хороши бы они не были? Думаю, скоро мы увидим новости, что системд готов заменить нам и SELinux вместе с AppArmor и всем остальным...
     
     
  • 2.65, Crazy Alex (ok), 12:38, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, очевидный ответ - потому что прикладные програмисты не торопятся использовать эту штуку, а так можно для их программ реализовать нужные ограничения снаружи. Но вне вот интересно - а что,  SELinux/AppArmor этого не умеют, что надо именно эту механику использовать? Если что - я с ними не знаком совершенно, ибо надобности нет.
     
     
  • 3.109, Kibab (ok), 12:25, 20/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Так вот надо менять стиль написания программ, а не тянуть вещь, предназначенную для защиты приложения от самого себя, в какие-то управляющие демоны. Это мусор, seccomp не для этого делался!
    Но нет же, пришёл Поттеринг и сделал очередную примочку к своему монстру =)
     
  • 2.66, filosofem (ok), 14:45, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Зато вброс годный. Каменты читал? 95% фанбоев как обычно не поняли о чем речь и в чем цимес seccomp filters, но по привычке принялись восхвалять Леннарда. 50% вообще поняли, что Поттеринг изобрел seccomp filters. =)

    >Подобный уровень общесистемной защиты уже обеспечивается AppArmor и SELinux

    Не подобный, а на несколько порядков защищеннее, гибче и удобнее. К примеру если процесс запустят не через systemd, то фильтры не применятся, в отличие от SELinux, AppArmor или нормальных реализаций seccomp filters, которые работают в любом случае.

     
     
  • 3.68, Crazy Alex (ok), 15:08, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload и подобную механику. Уж всяко не хуже systemd будет.
     
     
  • 4.84, Аноним (-), 21:36, 18/07/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кстати, подумалось - селинуксообразный стиль для seccomp (внешнее конфигурирование для
    > любой софтины, откуда бы не запускалсь) совершенно тривиально делается через ld.so.preload
    > и подобную механику. Уж всяко не хуже systemd будет.

    Об чем и спич. В Юниксах это существовало сто лет назад. И кто изобретатель велосипедов с восемнадцатиугольными колесами тут?

     

  • 1.86, Kibab (ok), 01:09, 19/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Итак, Леннарт извратился и затащил фичу, которая изначально проектировалась для использования самими приложениями, в свой менеджер инициализации. То, что приложение само может лучше решить, какие свои части как защищать (например, форкнувшись и по-разному ограничив права каждого чайлда), осталось для Поттеринга неважной деталью. В итоге получили аналог SELinux, но реализованный через seccomp filters, которые вообще не отличаются толковой реализацией. Что же, посмотрим, насколько сия кривая поделка проникнет в продакшен и сколько народу не отключат её после первого фоллаута.
     
  • 1.106, vi (?), 19:08, 19/07/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Помнится, в те "старые добрые времена", когда SELinux была волне, ходили такие рассказы:
    сплоит пробившийся на уровне ядра первым делом проверял SELinux и вырубал его сразу же, потом делал все что ему необходимо!

    Ну естественно же, все развивается по спирали.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру