| |
| 2.2, Аноним (-), 22:04, 15/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Толсто.
у них есть свой мандатный контроль доступа. К тому же 1, а не 4 разных
| | |
| |
| 3.4, Аноним (-), 22:38, 15/05/2012 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> у них есть свой мандатный контроль доступа.
Но редхата своего у них нет, так что правила писать некому.
> К тому же 1, а не 4 разных
Значит, повод для зависти все-таки есть.
MACа нужно как минимум два: привязанный к меткам и привязанный к именам. Их архитектуры будут совершенно разными, и ни одна из них не может быть универсальна сама по себе.
| | |
| |
| 4.23, Аноним (-), 21:06, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> MACа нужно как минимум два: привязанный к меткам и привязанный к именам.
ради самообразования(не ради bsd vs linux), зачем нужен делали МАС по именам, вместо "по меткам"? Только простоты ради?
| | |
| |
| 5.33, Аноним (-), 02:28, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> ради самообразования(не ради bsd vs linux), зачем нужен делали МАС по именам,
> вместо "по меткам"? Только простоты ради?
Не только ради простоты.
Пара примеров.
Далеко не все ФС поддерживают метки безопасности. А если ФС предполагается использовать в разных юниксах с разными реализациями MAC - это вообще грустно.
Еще в меточных системах иногда возникает необходимость обновить ветки на всей иерархии. Как правило, эта операция производится на ранней стадии загрузки (чтобы не интерферировать с работой юзерспейса) и может занимать довольно продолжительное время, что не всегда приемлемо.
Наконец, бывают случаи, когда файлам нужно присвоить контекст, отличный от контекста их программы-создателя. В меточных системах это обычно делается путем обновления меток в поддереве по событию ФС, что не очень изящно и экономично.
| | |
|
|
| 3.6, Аноним (-), 22:56, 15/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> у них есть свой мандатный контроль доступа.
А что, MAC в рамках TrustedBSD так довели до рабочего состояния?
Afaik, история закончилась в середине нулевых тем, что распилили пару дарповских грантов, и на том успокоились.
| | |
| |
| 4.7, Аноним (-), 06:49, 16/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Afaik оно работает, даже в OS X, не говоря уже о FreeBSD, где начиная с 5 версии. Есть ещё SEBSD, порт SELinux для FreeBSD, вот с ним не понятно, в каком он состоянии.
| | |
| |
| 5.12, Аноним (-), 14:39, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
В OS X запросто, там все-таки Apple. А вот насчет Фри - не могли бы вы пруфы представить? Хаутушки какие-нибудь, например.
| | |
| |
| 6.40, Аноним (-), 15:19, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Брат аноним уже дал ссылку на оффициальный guide, там даже есть некий набор готовых политик.
| | |
|
|
|
|
| 2.5, Аноним (-), 22:40, 15/05/2012 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Тяжело им без SELinux.
MAC и фильтр сисколов - это совершенно разные технологии. Capsicum - это аналог линуксового seccomp.
| | |
| |
| 3.8, user (??), 08:11, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну откуда ж ему знать то? Его цель - просто пёрнуть в лужу, а не вникнуть в суть новости
| | |
| |
| 4.15, Аноним (-), 16:05, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну откуда ж ему знать то? Его цель - просто пёрнуть в лужу, а не вникнуть в суть новости
Но по сути он все же прав. На фре без SELinux тяжело.
| | |
| |
| 5.41, Аноним (-), 15:21, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
По сути во Фре есть свой MAC, да и порт SELinux тоже делали, SEBSD, незнаю, правда, что с ним сейчас.
| | |
|
|
| 3.38, Аноним (-), 12:32, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Capsicum - это аналог линуксового seccomp.
Какой-то очень приблизительный аналог то - фильтр сисколов vs довески на права.
| | |
|
| 2.9, Куяврик (?), 10:24, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это такая хреновинка, которую 90% не знают и 9% отключают если включено?
| | |
| |
| 3.13, Аноним (-), 14:41, 16/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Это такая хреновинка, которую 90% не знают и 9% отключают если включено?
Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют эту судьбу. Включая сабж.
| | |
| |
| 4.16, Аноним (-), 16:06, 16/05/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют эту судьбу. Включая сабж.
... и уже через годик почти любой подробный мануал по настройке чего-нибудь будет начинаться словами "убедитесь, что capsicum полностью отключен"
| | |
| 4.26, Аноним (-), 21:46, 16/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Да. Практически все продвинутые технологии безопасности на десктопах и гoвносерверах разделяют
> эту судьбу. Включая сабж.
Потому что что виндозные ACL что вот это вот - такая хрень что проще застрелиться чем запрогарммить сие в более-менее сложной программе "по феншую". Вот на это и кладут все с прибором. Ну из числа тех у кого цель не гребаный перфекционизм а выпустить за обозримое время чего-то реально работающее в реальном мире. А вот такие супердуперсистемы безопасности рискуют полностью сорвать миссию, в силу чрезмерной сложности и интрузивности. Какая нафиг разница что программа будет еще чуть-чуть секурнее, если с такой хренью есть риск вообще никогда не выкатить релиз, а?
| | |
|
|
| 2.17, Kibab (ok), 18:44, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Разобрались бы для начала в разнице между SELinux и Capsicum, потом бы писали бред. Это фундаментально разные технологии и подходы.
| | |
| 2.22, NoMan (?), 19:45, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то если прочесть про капсикум, то Google планирует интегрировать его в ядро Linux. Тяжело всем.
| | |
| |
| 3.29, Аноним (-), 02:11, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то если прочесть про капсикум, то Google планирует интегрировать его в ядро Linux. Тяжело всем.
В результате его интегрируют только в ядро ChromeOS. А в мейнстиме среагируют также, как и на seccomp filter: гуляйте, ребята, со своим глюкодромом.
| | |
| 3.39, Аноним (-), 12:36, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то если прочесть про капсикум, то Google планирует интегрировать
Почему-то вспоминается анекдот:
Анонс в аэропорту: "планировал совершить посадку самолет номер 13..."
| | |
|
|
| 1.3, Аноним (-), 22:36, 15/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Мне capsicum показался излишне усложнённым, seccomp filter в Linux гораздо проще в понимании и использовании.
| | |
| |
| 2.18, Kibab (ok), 18:45, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Мне capsicum показался излишне усложнённым, seccomp filter в Linux гораздо проще в
> понимании и использовании.
А можно поподробнее? Было бы интересно послушать.
| | |
| |
| |
| 4.21, Kibab (ok), 19:31, 16/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> 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.
| | |
| |
| 5.25, Аноним (-), 21:42, 16/05/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Посмотрел, спасибо. Что вывел для себя:
> 1. В примере разрешаются вызовы read, write. Это всё здорово, однако для
> stdin мне нужен только read, а для stdout только write.
Я конечно понимаю что бсдшники - перфекционисты. Но вот как раз именно поэтому и рулят более другие системы. Да никому в этом мире не уперлось максимальное решение со всеми наворотами. Надо реально работающее и простое в использовани. Так, в общем случае.
| | |
| |
| 6.27, Kibab (ok), 21:48, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Посмотрел, спасибо. Что вывел для себя:
>> 1. В примере разрешаются вызовы read, write. Это всё здорово, однако для
>> stdin мне нужен только read, а для stdout только write.
> Я конечно понимаю что бсдшники - перфекционисты. Но вот как раз именно
> поэтому и рулят более другие системы. Да никому в этом мире
> не уперлось максимальное решение со всеми наворотами. Надо реально работающее и
> простое в использовани. Так, в общем случае.
Проблема именно в том, что seccomp filters -- это не "простое в использовании". Даже тупой хелловорлд содержит уйму boilerplate-кода, доказательство тому -- просто чтение этого самого мануала по ссылке... И я бы поспорил, что оно "реально работает" -- когда у вас появляются ещё файлы, кроме stdin и stdout, и вы хотите из них читать и при этом что-то плевать на консоль -- вы автоматически вынуждены разрешить write(). Теперь вопрос -- на какие дескрипторы будет разрешён write() ? Я допускаю, правда, что в seccomp filter существует не менее хитрый способ ещё и отфильтровать аргументы у системных вызовов. Иначе бы этим вообще было бы невозможно пользоваться. Но он вряд ли будет менее кривым, чем способ инициализации этого фреймворка :-)
| | |
| |
| 7.30, Аноним (-), 02:17, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Проблема именно в том, что seccomp filters -- это не "простое в
> использовании". Даже тупой хелловорлд содержит уйму boilerplate-кода,
А вон ту инструкциб из 13 действий мы назовем простой и удобной, ну конечно. В результате закончится все тем что 99% прикладников на это положат большой румяный ..., а вы переделывайте за ними по феншую, если пупок не развяжется.
| | |
| |
| 8.35, Kibab (ok), 02:38, 17/05/2012 [^] [^^] [^^^] [ответить] | +/– | Ну вы сравнили bzip2 и хелловорлд - Вообще пора включить мозг -- 99 совреме... текст свёрнут, показать | | |
| |
| 9.37, Аноним (-), 12:28, 17/05/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Ну все замечательно, конечно, но это аж 2 программы При том далеко не самые про... большой текст свёрнут, показать | | |
| |
| 10.44, Kibab (ok), 20:55, 18/05/2012 [^] [^^] [^^^] [ответить] | +/– | Знаете, сейчас один из самых реальных и действенных способов ломануть юзера пом... большой текст свёрнут, показать | | |
|
|
|
|
| 6.31, Аноним (-), 02:17, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Я конечно понимаю что бсдшники - перфекционисты.
Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.
И она более-менее решена, в прямом и топорном стиле. Возможность не предусмотрена - "как же мы без этого и того?" Возможность предусмотрена - "к чему все эти навороты?"
Как говорится, плох тот мент, который к столбу не докопается. И еще: свинья везде грязь найдет.
А конструктивной критикой тут и не пахнет.
| | |
| |
| 7.32, Аноним (-), 02:18, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А конструктивной критикой тут и не пахнет.
Собственно, поэтому не вижу смысла вступать в диалог. И другим не советую.
| | |
| 7.36, Аноним (-), 12:00, 17/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Я конечно понимаю что бсдшники - перфекционисты.
> Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.
Ну так в случае идеальной софтины докопаться не получится. Хотя наезды макофага на пингвин, при том что в его хомякоподелке и пятой части фич пингвина нет - выглядят забавно.
| | |
| 7.45, Kibab (ok), 20:58, 18/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Нет, тут просто решалась вполне конкретная задача: докопаться к чему-нибудь.
> И она более-менее решена, в прямом и топорном стиле.
> А конструктивной критикой тут и не пахнет.
А слабо теперь аргументировать, что вы тут понаписали? :-)
| | |
|
|
|
|
|
|
| |
| 2.19, Kibab (ok), 18:46, 16/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Как раз искал! Шикарно! Спасибо огромное.
Если искались, подпишитесь на cl-capsicum-discuss, откроете для себя ещё много интересного :-)
| | |
|
| 1.11, Аноним (-), 14:29, 16/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Подсистема Capsicum опционально включена в состав FreeBSD 9 в качестве экспериментальной возможности и будет активирована по умолчанию начиная с FreeBSD 10.
На BSDCan говорили, что уже в 9.1 будет в GENERIC.
| | |
| |
| |
| 3.43, Alexander Motin (?), 19:17, 18/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а там не говорили когда 9.1 зарелизится?
Планируется начать release cycle в конце мая и закончить в июле-августе.
| | |
|
|
| 1.24, Аноним (-), 21:39, 16/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Ну ать-ать-ать, кто ж так новости постит, а? Это п...!
> Дополнительно можно отметить статью "Automatic binary hardening with Autoconf"
Все бы замечательно конечно, но меня совершенно не интересуют бсдшные технологии, а вот автоконф и hardening пригодится. Но по названию новости - попробуй догадайся.
| | |
| 1.34, Аноним (-), 02:38, 17/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> 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 с его куцыми регистрами - не рулит? :)
| | |
|
