Тео де Раадт (Theo de Raadt) представил (http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html) на конференции Hackfest 2015 новый механизм изоляции системных вызовов Pledge (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...), продолжающий развитие идей, реализованных в появившейся в OpenBSD 5.8 (https://www.opennet.dev/opennews/art.shtml?num=43156) подсистеме tame (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-5.8/man2/tame...). Pledge уже интегрирован в ветку OpenBSD-CURRENT и будет доступен в релизе OpenBSD 5.9. В настоящее время механизмы защиты Pledge задействованы в 70% утилит базовой системы, к релизу OpenBSD 5.9 планируется обеспечить полный охват всех утилит.
По своей сути Pledge напоминает множество других механизмов ограничения доступа к системным вызовам, таких как seccomp, capsicum и systrace, но в отличие от них разработан с оглядкой на максимальное упрощение применения. Из-за усложнений, связанных с необходимости построения правил, включающих отдельные вызовы, прошлые попытки повсеместного применения изоляции системных вызовов при помощи systrace оказались безрезультатны. Единицы программ были защищены, но основная масса так и осталась без изменений. Для решения данной проблемы решено было создать новый метод формирования политик безопасности, который мог бы был легко применён ко всем приложениям базовой системы, без необходимости вникать в детали. В итоге за шесть месяцев существования Pledge на его использование переведено более 400 утилит OpenBSD.Pledge требует внесения в приложения специальных аннотаций, определяющих уровень привилегий на текущем этапе выполнения приложения. Вместо детализации на уровне отдельных системных вызовов, Pledge манипулирует классами доступа. Аннотации выставляются через указание функции pledge(), первым аргументом которой является список разрешённых классов системных вызовов, а вторым - массив файловых путей, куда разрешён доступ. После сборки и запуска модифицированного приложения, ядро берёт на себя работу по контролю соблюдения заданных правил. При этом вместо традиционной блокировки доступа к неразрешённым системным вызовов применён иной подход - в случае выявление несанкционированного поведения приложение принудительно завершается. По замыслу разработчиков подобный подход заметно усложняет исследование возможных путей обхода ограничений в процессе атаки.
Анализ закономерностей обращения к системным вызовам в штатных утилитах OpenBSD показал, что имеется типичный сценарий использования системных вызовов: достаточно большое число системных вызовов используется на этапе инициализации, после чего обращение к ним существенно сокращается. Обычно для обеспечения защиты достаточно добавить вызов pledge() в участок кода после инициализации, но до начала основного цикла.
Классы системных вызовов включают (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...) stdio (ввод/вывод), rpath (только чтение файлов), wpath (запись файлов), cpath (создание файлов), tmppath (работа со временными файлами), inet (сетевые сокеты), unix (unix-сокеты), dns (резолвинг в DNS), getpw (доступ на чтение к базе пользователей), ioctl (вызов ioctl), proc (управление процессами), exec (запуск процессов), id (управление правами доступа) и т.п.
Например, для программы cat, которая только читает файлы, можно указать pledge("stdio rpath", NULL), для mkdir - pledge("stdio rpath cpatch wpatch fattr", NULL), а для patch - pledge("stdio rpath cpatch wpatch tmpath fattr", NULL). Подобные ограничения позволят работать с файлами, но не дадут создавать сокеты и запускать другие приложения. Насколько pledge более прост для внедрения можно судить по утилите file: при использовании systrace для лимитирования системных вызовов требовалось 300 строк кода, в то время как pledge позволяет обойтись двумя вызовами pledge.
<center><a href="http://www.openbsd.org/papers/hackfest2015-pledge/mgp00028.h... src="https://www.opennet.dev/opennews/pics_base/0_1447166009.jpg&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
URL: https://news.ycombinator.com/item?id=10537268
Новость: http://www.opennet.dev/opennews/art.shtml?num=43295
В итоге получается примерный аналог AppArmor, но с указанием профиля безопасности не во внешнем файле, а в исходном коде программы.Особенно интересно будет с доступом к конкретным файлам, а не файлами вообще (как в примерах). Захотел переместить файл, оставив симлинк - лови привет :)
Отличие в том, что AppArmor/SELinux ты как админ можешь отключить, когда он заебал (и большинство так и делают), а pledge() нет, кроме как выпилив из исходников.
Зато с pledge() меньше вероятность того, что внесенные ограничения будут мешать работать с программой, так как их определяют сами разработчики, а не мейнтенер дистрибутива
Реквестую в каждый бинарник хардкодить Manifest.xml с набором пермишенов. :D
> Зато с pledge() меньше вероятность того, что внесенные ограничения будут мешать работать с программой, так как их определяют сами разработчики, а не мейнтенер дистрибутиваЕсли разработчикам не лень написать правило для pledge, почему им должно быть лень написать правила для AppArmor?
специально для вас есть слайд:
http://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.html
Я его видел и не подразумевал в предыдущем комментарии, что отключение защиты это хорошо.
> когда он заебал (и большинство так и делают)это применимо большей частью к selinux'у
Вы абсолютно не понимаете специфики OpenBSD
Прогрессирующий нарцисизм? спасибо не надо
> Прогрессирующий нарцисизм? спасибо не надоНе этот, а главный. Security by bullshit :)
> Отличие в том, что AppArmor/SELinux ты как админ можешь отключить, когда он заебал
> (и большинство так и делают), а pledge() нет, кроме как выпилив из исходников.... или заменив функционал этого pledge() за заглушку.
> В итоге получается примерный аналог AppArmorа вообще в самом-самом итоге получится примерный аналог minix
Что только люди не делают лиж бы не писать на нормальных языках типа Scala/Java....
> Что только люди не делают лиж бы не писать на нормальных языках типа Scala/Java....От дурака-программиста "нормальные" языки не защищают.
Кроме того, языки, в которых скорость разработки ставится превыше ресурсоэффективности конечного продукта - весьма способствуют разаведению таких программистов.
нормальные языки @ жава. Чот ржу
Как понять фразу "нормальные языки на жава" или "нормальные языки при жава"?
http://advice-dog.ru/dog/%D0%BD%D0%BE�...так понятнее?
Которые написаны на С/С++
Отличный костыль!
Елегантное решение
Не проще ли полностью виртуализировать операционные системы, а потерю производительности скомпенсировать отказом от пожиралок CPU типа питон, php и скриптовых языков.
> Не проще ли полностью виртуализировать операционные системы, а потерю производительности
> скомпенсировать отказом от пожиралок CPU типа питон, php и скриптовых языков.много производительности не бывает
Виртуализация не является решением проблем безопасности.
> Виртуализация не является решением проблем безопасности.Виртуализация вообще не решает большинство проблем, а лишь плодит новые. Но админам локалхостов или гогнохостингов этого, разумеется, не понять.
Точно, ни проблему бессмертия, ни мира во всем мире, ни даже "трубы горят" виртуализация не решает. Но может она и не для этого была придумана? Ведь все таки небольшое(на фоне всей совокупности проблем человечества) количество проблем она отлично позволяет решить. В том числе и проблемы в области компьютерной безопасности.
Решать проблемы безопасности виртуализацией - все равно что решать RAIDом проблему сохранности данных. Это во-первых.Во-вторых, некоторые побочные свойства виртуализации могут, разумеется, быть использованы в том числе и применительно к вопросам безопасности. Но.
Безопасность - это регламент.
Защита - только часть его (наряду с такими аспектами как аудит, сценарии, анализ и идентификация угроз, экономическое обоснование).
Технические средства защиты - только малая часть ее.
Конкретные технологии, используемые в технических средствах защиты - только малая часть их.
Ты вообще читал пост, на который отвечаешь? Ну давай специально для тебя дам другие примеры проблем. Виртуализация не решает проблему тупых пользователей, виртуализация не решает проблему ущербного workflow, придуманного тупыми пользователями, виртуализация не решает проблему безграмотных админов, нанятых тупыми пользователями, виртуализауция не решает проблему тупых быдлокодеров, пишущих программы тупым пользователям. В общем не решает всего того, что ты назвал регламентом. Но среди технических средств защиты виртуализация одно из самых эффективных. Во многом из-за того, что позволяет техническими средствами снизить потенциальный урон по причине нетехнических факторов. Собственно как и RAID для сохранности данных. Но можно конечно быть тупым идеалистом и плакаться на несовершенство мира вместо решения реальных проблем.
> позволяет техническими средствами снизить потенциальный урон по причине нетехнических факторовРешать административные проблемы техническими средствами - верный путь к успеху.
> как и RAID для сохранности данных
RAID не является решением проблемы сохранности данных.
Решением проблем сохранности данных является бэкап.
>Решать административные проблемы техническими средствами - верный путь к успеху.Сидеть и сетовать на несовершенство мира конечно гораздо продуктивней.
>RAID не является решением проблемы сохранности данных.
>Решением проблем сохранности данных является бэкап.Умную вещь прочитал, значит свой мозг можно не включать? Как тебе поможет бэкап, если пропажа данных даже за последнюю секунду уже является неприемлемым вариантом? Опять этот гадкий несовершенный мир не дает строить сферического коня в вакууме.
> сетовать на несовершенство мираЭтого никто не предлагал. В частности, администратичные проблемы решаются административными средствами.
> пропажа данных даже за последнюю секунду уже является неприемлемым вариантом
Для начала я бы посоветовал не смешивать пропажу данных и недоступность данных в течение какого-то времени.
Ну да, а решением всех медицинских проблем является клонирование.
Сейчас столько инструментов есть, начиная с презираемого вами резервирования диска, теневых копий, репликации, что для того, чтобы понадобилось бекап поднимать - это надо либо просрать всё, что можно, либо чтоб ракета в датацентр попала.
Ну и к тому же бекап это просто копия - которая может проэкспайриться и оказаться уничтожена - так что помимо него нужны ещё и отдельные инструменты мониторинга изменений, проверки целостности. Да и даже банального перевода в р/о данных, не подлежащих правке, типа архивов. То есть нужен инструмент, который скажет "шеф всё пропало" и что надо поднимать бекап (потому что пользователи могут далеко не сразу распознать, что какой-то редкоиспользуемый документ пропал).
У нас в конторе под кило серваков, всё под vmware или hyperV. Storage - общий мегаSAN за 100500 нефти.Как обеспечивать безотказную работу этих 100500 разных корпоративных систем без лоховской виртуализации?
Читайте мануалы к вмвари, там много всего есть про отказоустойчивость, ну или саппорт теребите, если заплатили так много денег за то, что в теории вы бы могли сделать совершенно бесплатно (если судить по заданному здесь вопросу вы никаких особенно навороченных фич вмвари не используете).
Ну а то, что вы вляпались в hyperv - уже ваши собственные проблемы, не надо было вообще наступать на эту кучку отходов жизнедеятельности Баллмера.И у вас есть точка отказа: "общий мегаSAN за 100500 нефти" - такие штуки хоть и очень надёжны, но тоже со свистом и бурным весельем вылетают несмотря на все подключения несколькими линками, многоконтроллерность, вроде-бы-как-отсутствие-точек-отказа и прочие очень полезные, но не спасающие на 100% фичи.
Вообще-то вопрос был на высказывание: "Виртуализация вообще не решает большинство проблем, а лишь плодит новые. Но админам локалхостов или гогнохостингов этого, разумеется, не понять." HyperV тоже вполне себе работает, переходят на него из-за "дешевле".Вопрос: как делать отказоустойчивость 1k серверов (с очень разным набором софта) сделать без виртуализации?
В том и дело, что вы потратили кучу денег и даже не поняли куда. Это делалось 100 лет назад с помощью солярных зон и хербита, это делается сейчас с помощью линукс контейнеров и хербита, это делалось в локальном и даже географически отказоустойчивом варианте с помощью veritas storage foundation. По сути потратили на gui-панельки и тратите на невероятный оверхед, особенно для vmware.
Я тебе сейчас очень страшную вещь скажу - зоны солярки, джейлы БСД и контейнеры в линуксе это все тоже виртуализация. Просвещайся: https://en.wikipedia.org/wiki/Operating-system-level_virtual...
Ну и vmware ты небось видел только как vmware workstation на винде. Почитай про их серверные продукты.
Пожалуй, промолчу ...
> Вопрос: как делать отказоустойчивость 1k серверов (с очень разным набором софта) сделать без виртуализации?Смотрю на ~650 OpenVZ контейнеров (а есть ещё множество сервисов, которые крутятся вне контейнеров) с очень разным набором софта и понимаю, что да, это можно сделать и без виртуализации.
Ну правда большинство контейнеров даже не в отказоустойчивом кластере - помрёт железный сервер с контейнерами, ну и фиг с ним, отряд не заметит потери бойца.
Можно еще рекомендации Microsoft почитать, в частности Microsoft’s Preferred Architecture for Exchange> In the PA, all servers are physical, multi-role servers. Physical hardware is deployed rather than virtualized hardware for two reasons:
> The servers are scaled to utilize eighty percent of resources during the worst-failure mode.
> Virtualization adds an additional layer of management and complexity, which introduces additional recovery modes that do not add value, as Exchange provides equivalent functionality out of the box.”
Кто сказал, что безопасность - это просто?
Ну, это не новость, это уже старость.Оно ещё под именем tame сколько развивалось, потом переименовалось, и презентаций уже было несколько штук.
> Ну, это не новость, это уже старость.
> Оно ещё под именем tame сколько развивалось, потом переименовалось, и презентаций уже
> было несколько штук.Это как раз нормальная новость - первый анонс, ещё про tame(), честно говоря, был несколько рановат.
Но, в любом случае, искреннее спасибо автору новостей про OpenBSD.
> Подобные ограничения позволят работать с файлами, но не дадут создавать сокеты и запускать другие приложения.Вопрос из Отдела Логики РАН: Я живу на Арбате, купил себе КАМАЗ, с 8 до 23 передвижение на них в центре запрещено. Не долбойоп ли я?
живи в КАМАЗе
А низзя еще вместо того чтобы переписывать софт простую утилитку pledge, которая выставляет заданные юзером ограничения и exec'ает софт? Типа: pledge [-options] ./myapp [-options]
> А низзя еще вместо того чтобы переписывать софт простую утилитку pledge, которая
> выставляет заданные юзером ограничения и exec'ает софт? Типа: pledge [-options] ./myapp
> [-options]Низзя. Потому что извне нельзя нормально узнать, какому процессу в какой момент какие привилегии можно порезать.
поддержка pledge() в разных языках программирования https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55...
