Бен Лаури (Ben Laurie (http://en.wikipedia.org/wiki/Ben_Laurie)), известный своим вкладом в разработку OpenSSL и обеспечение поддержки SSL для http-сервера Apache, представил (http://www.links.org/?p=1242) практическое руководство по использованию интегрированной во FreeBSD подсистемы Capsicum (http://www.cl.cam.ac.uk/research/security/capsicum/) для изоляции выполнения программ и библиотек. Использование Capsicum продемонстрировано на примере утилиты bzip2 и библиотеки libtiff (https://github.com/benlaurie/libtiff), все действия разбиты на 13 этапов, для каждого из которых представлены для изучения соответствующие патчи.
Подсистема Capsicum опционально включена в состав FreeBSD 9 в качестве экспериментальной возможности и будет активирована по умолчанию начиная с FreeBSD 10. Capsicum представляет собой фреймворк для организации изолированного выполнения приложений и ограничения использования приложениями определённых функций. Capsicum расширяет POSIX API и предоставляет несколько новых системных примитивов, нацеленных на поддержку модели безопасности через управление возможностями объектов ("object-capability") для Unix-систем. Capsicum нацелен на дополнение традиционного централизованного мандатного контроля доступа средствами для защиты отдельных приложений и активируется на стороне самого приложения. Используя Capsicum приложение можно запустить в режиме повышенной изоляции (sandbox), при котором программа сможет выполнять только ранее специфицированные штатные действия.
Дополнительно можно отметить статью "Automatic binary hardening with Autoconf (http://mainisusuallyafunction.blogspot.com/2012/05/automatic... в которой показано как автоматизировать проверку наличия дополнительных механизмов повышения безопасности в скриптах Autoconf и активировать сборку с задействованием всех доступных методов повышения безопасности на этапе сборки. В частности, рассматриваются такие возможности современных компиляторов, как рандомизация выделения памяти, дополнительные проверки корректности выполнения строковых операций и операций с памятью (-D_FORTIFY_SOURCE=2), защита от целочисленных переполнений (-fno-strict-overflow), защита от переполнения стека (-fstack-protector-all) и т.п. Отмечается (http://www.openwall.com/lists/oss-security/2012/05/15/1), что использовать данные возможности в своих программах стоит с осторожностью, предварительно протестировав возможное негативное влияние на производительность (некоторые наблюдают замедление до 30%)..
URL: http://www.openwall.com/lists/oss-security/2012/05/15/2
Новость: http://www.opennet.me/opennews/art.shtml?num=33854
Тяжело им без SELinux.
Толсто.
у них есть свой мандатный контроль доступа. К тому же 1, а не 4 разных
> у них есть свой мандатный контроль доступа.Но редхата своего у них нет, так что правила писать некому.
> К тому же 1, а не 4 разных
Значит, повод для зависти все-таки есть.
MACа нужно как минимум два: привязанный к меткам и привязанный к именам. Их архитектуры будут совершенно разными, и ни одна из них не может быть универсальна сама по себе.
> MACа нужно как минимум два: привязанный к меткам и привязанный к именам.ради самообразования(не ради bsd vs linux), зачем нужен делали МАС по именам, вместо "по меткам"? Только простоты ради?
* зачем сделали МАС по именам, а не по меткам?
> ради самообразования(не ради bsd vs linux), зачем нужен делали МАС по именам,
> вместо "по меткам"? Только простоты ради?Не только ради простоты.
Пара примеров.
Далеко не все ФС поддерживают метки безопасности. А если ФС предполагается использовать в разных юниксах с разными реализациями MAC - это вообще грустно.
Еще в меточных системах иногда возникает необходимость обновить ветки на всей иерархии. Как правило, эта операция производится на ранней стадии загрузки (чтобы не интерферировать с работой юзерспейса) и может занимать довольно продолжительное время, что не всегда приемлемо.
Наконец, бывают случаи, когда файлам нужно присвоить контекст, отличный от контекста их программы-создателя. В меточных системах это обычно делается путем обновления меток в поддереве по событию ФС, что не очень изящно и экономично.
> у них есть свой мандатный контроль доступа.А что, MAC в рамках TrustedBSD так довели до рабочего состояния?
Afaik, история закончилась в середине нулевых тем, что распилили пару дарповских грантов, и на том успокоились.
Afaik оно работает, даже в OS X, не говоря уже о FreeBSD, где начиная с 5 версии. Есть ещё SEBSD, порт SELinux для FreeBSD, вот с ним не понятно, в каком он состоянии.
В OS X запросто, там все-таки Apple. А вот насчет Фри - не могли бы вы пруфы представить? Хаутушки какие-нибудь, например.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ma...
Брат аноним уже дал ссылку на оффициальный guide, там даже есть некий набор готовых политик.
> Тяжело им без SELinux.MAC и фильтр сисколов - это совершенно разные технологии. Capsicum - это аналог линуксового seccomp.
Ну откуда ж ему знать то? Его цель - просто пёрнуть в лужу, а не вникнуть в суть новости
> Ну откуда ж ему знать то? Его цель - просто пёрнуть в лужу, а не вникнуть в суть новостиНо по сути он все же прав. На фре без SELinux тяжело.
По сути во Фре есть свой MAC, да и порт SELinux тоже делали, SEBSD, незнаю, правда, что с ним сейчас.
> Capsicum - это аналог линуксового seccomp.Какой-то очень приблизительный аналог то - фильтр сисколов vs довески на права.
Это такая хреновинка, которую 90% не знают и 9% отключают если включено?
> Это такая хреновинка, которую 90% не знают и 9% отключают если включено?Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют эту судьбу. Включая сабж.
> Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют эту судьбу. Включая сабж.... и уже через годик почти любой подробный мануал по настройке чего-нибудь будет начинаться словами "убедитесь, что capsicum полностью отключен"
> Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют
> эту судьбу. Включая сабж.Потому что что виндозные ACL что вот это вот - такая хрень что проще застрелиться чем запрогарммить сие в более-менее сложной программе "по феншую". Вот на это и кладут все с прибором. Ну из числа тех у кого цель не гребаный перфекционизм а выпустить за обозримое время чего-то реально работающее в реальном мире. А вот такие супердуперсистемы безопасности рискуют полностью сорвать миссию, в силу чрезмерной сложности и интрузивности. Какая нафиг разница что программа будет еще чуть-чуть секурнее, если с такой хренью есть риск вообще никогда не выкатить релиз, а?
Разобрались бы для начала в разнице между SELinux и Capsicum, потом бы писали бред. Это фундаментально разные технологии и подходы.
Вообще-то если прочесть про капсикум, то Google планирует интегрировать его в ядро Linux. Тяжело всем.
> Вообще-то если прочесть про капсикум, то Google планирует интегрировать его в ядро Linux. Тяжело всем.В результате его интегрируют только в ядро ChromeOS. А в мейнстиме среагируют также, как и на seccomp filter: гуляйте, ребята, со своим глюкодромом.
> Вообще-то если прочесть про капсикум, то Google планирует интегрироватьПочему-то вспоминается анекдот:
Анонс в аэропорту: "планировал совершить посадку самолет номер 13..."
Мне capsicum показался излишне усложнённым, seccomp filter в Linux гораздо проще в понимании и использовании.
> Мне capsicum показался излишне усложнённым, seccomp filter в Linux гораздо проще в
> понимании и использовании.А можно поподробнее? Было бы интересно послушать.
http://outflux.net/teach-seccomp/
> http://outflux.net/teach-seccomp/Посмотрел, спасибо. Что вывел для себя:
1. В примере разрешаются вызовы read, write. Это всё здорово, однако для stdin мне нужен только read, а для stdout только write. Тем не менее, этого ограничения не вводится. В Capsicum ограничиваются операции для каждого дескриптора в отдельности.
2. Разрешение exit, какого-то exit_group... Зачем? Почему они вообще требуют разрешения?
3. Куча каких-то вложенных структур, необходимых для инициализации защиты. Почему всё так сложно сделано?
4. Почему для того, чтобы посмотреть, каких системных вызовов мне ещё не хватает, я должен цеплять какой-то мутный объектник? Почему нельзя было сделать выделенный код возврата из вызова syscall ("Not permitted in capability mode", "Capabilities insufficient" в FreeBSD Capsicum)?
5. + if (errno == EINVAL)
+ fprintf(stderr, "SECCOMP_FILTER is not available. :(\n");
Ну да, конечно же, errno == EINVAL это лучший способ проверить, доступна ли фича для использования. Сравнить с feature_present("security.capability_mode") я оставлю в качестве самостоятельного упражнения.Неделю назад я, когда читал доклад про Capsicum на BSD Day, сказал, что пока не смотрел, насколько seccomp filter отличается от seccomp, но подозреваю, что сильно лучше не стало. Я рад, что не соврал уважаемым слушателям.
С учётом того, что разработка Capsicum поддерживается в том числе и Google и в перспективе весьма массивно будет двигаться в ядро Linux, а равно как и в OpenBSD, я позволю себе дальше не заморачиваться с seccomp filter.
> Посмотрел, спасибо. Что вывел для себя:
> 1. В примере разрешаются вызовы read, write. Это всё здорово, однако для
> stdin мне нужен только read, а для stdout только write.Я конечно понимаю что бсдшники - перфекционисты. Но вот как раз именно поэтому и рулят более другие системы. Да никому в этом мире не уперлось максимальное решение со всеми наворотами. Надо реально работающее и простое в использовани. Так, в общем случае.
>> Посмотрел, спасибо. Что вывел для себя:
>> 1. В примере разрешаются вызовы read, write. Это всё здорово, однако для
>> stdin мне нужен только read, а для stdout только write.
> Я конечно понимаю что бсдшники - перфекционисты. Но вот как раз именно
> поэтому и рулят более другие системы. Да никому в этом мире
> не уперлось максимальное решение со всеми наворотами. Надо реально работающее и
> простое в использовани. Так, в общем случае.Проблема именно в том, что seccomp filters -- это не "простое в использовании". Даже тупой хелловорлд содержит уйму boilerplate-кода, доказательство тому -- просто чтение этого самого мануала по ссылке... И я бы поспорил, что оно "реально работает" -- когда у вас появляются ещё файлы, кроме stdin и stdout, и вы хотите из них читать и при этом что-то плевать на консоль -- вы автоматически вынуждены разрешить write(). Теперь вопрос -- на какие дескрипторы будет разрешён write() ? Я допускаю, правда, что в seccomp filter существует не менее хитрый способ ещё и отфильтровать аргументы у системных вызовов. Иначе бы этим вообще было бы невозможно пользоваться. Но он вряд ли будет менее кривым, чем способ инициализации этого фреймворка :-)
> Проблема именно в том, что seccomp filters -- это не "простое в
> использовании". Даже тупой хелловорлд содержит уйму boilerplate-кода,А вон ту инструкциб из 13 действий мы назовем простой и удобной, ну конечно. В результате закончится все тем что 99% прикладников на это положат большой румяный ..., а вы переделывайте за ними по феншую, если пупок не развяжется.
> А вон ту инструкциб из 13 действий мы назовем простой и удобной,
> ну конечно. В результате закончится все тем что 99% прикладников на
> это положат большой румяный ..., а вы переделывайте за ними по
> феншую, если пупок не развяжется.Ну вы сравнили bzip2 и хелловорлд :-))) Вообще пора включить мозг -- 99% современного софта написано без особой оглядки на безопасность, поэтому переделывать в любом случае придётся много.
Конечно, всё сразу переделать не удаться никому :-) Однако всё и не нужно. Критические системные сервисы и сетевые службы -- в первую очередь. И здесь мы вспоминаем про недавние новости про поддержку seccomp filters в vsftpd и OpenSSH, например. Далее, один из основных разрабочиков OpenSSH сидит от меня через два кабинета, и он в кулуарных разговорах высказывал заинтересованность в поддержке Capsicum.А на тех поделкописателей, которые будут упорно орать, что безопасность не важна -- в конце концов и положат большой и румяный :-)
> И здесь мы вспоминаем про недавние новости про поддержку seccomp filters
> в vsftpd и OpenSSH, например.Ну все замечательно, конечно, но это аж 2 программы. При том далеко не самые проблемные в плане реальных взломов через них. Что это напоминает? Правильно, похоже на microsoft‑windows‑xp‑with‑firewall.jpg
> Далее, один из основных разрабочиков OpenSSH сидит от меня через два кабинета,
> и он в кулуарных разговорах высказывал заинтересованность в поддержке Capsicum.Я рад за вас, но к чему это все? Попонтоваться? Собственно это его геморрой, ему и решать - надо ему еще порцию возни или нет. Один какой-то ssh, далеко не самый дырявый на свете - вообще ничего такого не меняет. Машина где кроме ssh ничего нет - вообще бесполезна для окружающих. А вот тут то и будет основной болт, ровно такой же как случился в винде. У которой технически есть куча пермиссий на все что можно, но практически - оно настолько задрюкано что прикладники просто кладут на это. Просто потому что трах с откусыванием прав до тотального минимума, выяснение какие права нужны и прочая - займут чуть ли не больше времени чем написание остальной части программы. Ну вот все и забили на это дружно. Прикладники положили - юзерам пришлось сидеть под админом. Иначе половина прикладух ломается непредсказуемым образом. Но некоторые видимо не хотят учить чужие ошибки. Да, это кстати и к seccomp filter относится. Ну и будет еще два раза по microsoft‑windows‑xp‑with‑firewall.jpg на практике.
> А на тех поделкописателей, которые будут упорно орать, что безопасность не важна
> -- в конце концов и положат большой и румяный :-)То-есть, бсдшники положат сами на себя? Помнится им тут однажды paxuser довольно конкретно раздал, сравнив разные технологии hardening-а. А что, рискнете revisit'ануть дискуссию и рассказать что в отношении к секурити поменялось с тех пор? А то там помнится даже у убунтов средств по втыканию палок в колеса хакерам было больше чем у флегматичных пофигистов-теоретиков.
> Ну все замечательно, конечно, но это аж 2 программы. При том далеко
> не самые проблемные в плане реальных взломов через них. Что это
> напоминает? Правильно, похоже на microsoft‑windows‑xp‑with‑firewall.jpgЗнаете, сейчас один из самых реальных и действенных способов ломануть юзера (помимо social engineering, ликвидация проблем в этой области находится вне компетенции программистов) -- это через браузер, через его дыры. В этом плане безусловным молодцом является так нелюбимый на этом форуме Google Chrome, который как раз интенсивно использует доступные на целевой платформе технологии обеспечения безопасности. Кстати говоря, поддержка Capsicum была туда уже добавлена в ходе изначального эксперимента, см. подробнее публикации по Capsicum. Там же было хорошее сравнение различных механизмов безопасности на различных ОС, и Linux выглядел не в самом лучшем свете. Правда, seccomp filter там ещё не было. Но, судя по тому, что я видел в факе по ссылке выше, особо ничего не поменялось. Такая же наколеночная поделка.
>> Далее, один из основных разрабочиков OpenSSH сидит от меня через два кабинета,
>> и он в кулуарных разговорах высказывал заинтересованность в поддержке Capsicum.
> Я рад за вас, но к чему это все? Попонтоваться?"Попонтоваться" можно было бы, если бы это был я ;)))
> А вот тут то и
> будет основной болт, ровно такой же как случился в винде. У
> которой технически есть куча пермиссий на все что можно, но практически
> - оно настолько задрюкано что прикладники просто кладут на это.Ещё раз настоятельно рекомендую ознакомиться с публикациями про Capsicum. В том числе там подробно рассказано, почему механизмы безопасности Windows, призванные защищать данные одного юзера от другого, плохо работают для сендбоксинга приложений.
> это дружно. Прикладники положили - юзерам пришлось сидеть под админом. Иначе
> половина прикладух ломается непредсказуемым образом. Но некоторые видимо не хотят учить
> чужие ошибки. Да, это кстати и к seccomp filter относится. Ну
> и будет еще два раза по microsoft‑windows‑xp‑with‑firewall.jpg
> на практике.Да, у большинства авторов руки растут из жопы и про безопасность они не думают. Что, это повод пользоваться дырявым софтом?
> То-есть, бсдшники положат сами на себя? Помнится им тут однажды paxuser довольно
> конкретно раздал, сравнив разные технологии hardening-а.Кто это? я его не знаю. Можно ссылку на дискуссию? Было бы интересно почитать!
> Я конечно понимаю что бсдшники - перфекционисты.Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.
И она более-менее решена, в прямом и топорном стиле. Возможность не предусмотрена - "как же мы без этого и того?" Возможность предусмотрена - "к чему все эти навороты?"
Как говорится, плох тот мент, который к столбу не докопается. И еще: свинья везде грязь найдет.
А конструктивной критикой тут и не пахнет.
> А конструктивной критикой тут и не пахнет.Собственно, поэтому не вижу смысла вступать в диалог. И другим не советую.
>> Я конечно понимаю что бсдшники - перфекционисты.
> Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.Ну так в случае идеальной софтины докопаться не получится. Хотя наезды макофага на пингвин, при том что в его хомякоподелке и пятой части фич пингвина нет - выглядят забавно.
> Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.
> И она более-менее решена, в прямом и топорном стиле.
> А конструктивной критикой тут и не пахнет.А слабо теперь аргументировать, что вы тут понаписали? :-)
Как раз искал! Шикарно! Спасибо огромное.
> Как раз искал! Шикарно! Спасибо огромное.Если искались, подпишитесь на cl-capsicum-discuss, откроете для себя ещё много интересного :-)
>Подсистема Capsicum опционально включена в состав FreeBSD 9 в качестве экспериментальной возможности и будет активирована по умолчанию начиная с FreeBSD 10.На BSDCan говорили, что уже в 9.1 будет в GENERIC.
а там не говорили когда 9.1 зарелизится?
> а там не говорили когда 9.1 зарелизится?Планируется начать release cycle в конце мая и закончить в июле-августе.
Ну ать-ать-ать, кто ж так новости постит, а? Это п...!> Дополнительно можно отметить статью "Automatic binary hardening with Autoconf"
Все бы замечательно конечно, но меня совершенно не интересуют бсдшные технологии, а вот автоконф и hardening пригодится. Но по названию новости - попробуй догадайся.
> PIE really hurts on i386 because data references use an extra register, and
> registers are scarce to begin with. It's much cheaper on amd64 thanks to
> PC-relative addressing.Ну, кто там сомневался что x86 с его куцыми регистрами - не рулит? :)