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

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

"AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
Сообщение от opennews (ok) on 31-Июл-10, 10:12
Джеймс Моррис (James Morris), куратор разработки Linux по вопросам безопасности, сообщил (http://lkml.org/lkml/2010/7/30/61), что патчи, обеспечивающие поддержку технологий AppArmor (http://apparmor.wiki.kernel.org/) и Yama, поставлены в очередь на включение в основную ветку разработки ядра Linux, и должны войти в выпуск 2.6.36. AppArmor Данная технология является одной из реализаций мандатного контроля доступа для Linux. Изначально она была разработана компанией Immunix. Впоследствии эта компания была куплена Novell'ом, AppArmor был открыт под лицензией GPL и включен в ядро openSUSE. Кроме того, поддержка AppArmor была включена в дистрибутивы Mandriva и Ubuntu. Однако, некоторое время спустя, основатель и главный разработчик AppArmor Криспин Коуэн перешел на работу в Microsoft, а Novell объявила о начале полноценной поддержки в своих продуктах конкурирующей технологии SELinux, начиная с openSUSE 11.1 (подробнее об этих событиях (http://etbe.coker.com.au/2008/08/23/apparmor-is... URL: http://lwn.net/Articles/398191/rss Новость: http://www.opennet.dev/opennews/art.shtml?num=27488
Ответить | Правка | Cообщить модератору

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

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

2. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+2 +/–
Сообщение от KERNEL_PANIC (ok) on 31-Июл-10, 10:24
Я то думал, что на АррАrmor уже давно все забили и оно в анабиозе гдето лежит. Как оказывается, нет, его еще в ядро пхнут. Как будто других получше технологий не хватает...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–3 +/–
	Сообщение от goof.gooffy (ok) on 31-Июл-10, 12:33
	Тебе оно мешает? Не хочешь - не используй. Вреда не принесет, а польза будет явно
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от dimqua (ok) on 31-Июл-10, 12:57
	Ну из описания, например, не понятно какие у неё плюсы по сравнению с SELinux.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+7 +/–
	Сообщение от Аноним (??) on 31-Июл-10, 13:15
	а плюсов нет До селинукса этим велосипедам далеко
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–8 +/–
	Сообщение от User294 (ok) on 31-Июл-10, 22:17
	> До селинукса этим велосипедам далеко Только в настройке геморроен и если кто считает что селинуху нельзя поднасрать - он читает новости про эксплойты с повышением прав в линухе (было тут в новостях). Почему-то сплойты первым делом SELinux выпилиывают, чтоб под ногами не мешался :). А так геморная штука, как только что-то окромя стандартных операций надо - сливай вода, туши фонарь. ИМХО можно достичь сравнимой секурити куда менее геморными методами, скажем путем простой распиловки на отдельные изолированные контейнеры. И эффективно, и просто.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	26. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+2 +/–
	Сообщение от аноним on 01-Авг-10, 00:18
	Видимо, вы просто плохо понимаете, как работает Linux. >если кто считает что селинуху нельзя поднасрать - он читает новости про эксплойты с повышением прав в линухе (было тут в новостях). Почему-то сплойты первым делом SELinux выпилиывают, чтоб под ногами не мешался >ИМХО можно достичь сравнимой секурити куда менее геморными методами, скажем путем простой распиловки на отдельные изолированные контейнеры. Контейнеры дают ровно такую же защиту, как и LSM-based MAC (в частности, selinux). Потому что если имеется критическая уязвимость _в самом ядре_, любые средства, работающие на уровне ядра и ниже, _абсолютно бессильны_. В этой ситуации защитить могут только над-ядерные методы - гипервизор (xen) или физическое разделение по серверам. >А так геморная штука, как только что-то окромя стандартных операций надо - сливай вода, туши фонарь Вы уж определитесь, либо оно вам надо, и тогда изучайте и не пишите глупостей, либо оно вам совершенно не нужно, и тогда забудьте о такой вещи, как мандатный контроль доступа.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	29. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–7 +/–
	Сообщение от User294 (ok) on 01-Авг-10, 11:27
	> Видимо, вы просто плохо понимаете, как работает Linux. Не линукс а искусственные довески к нему в виде всяких SELinix-ов и прочие мандатные системы. Нужные в основном всяким FBI и прочим у которых в правилах так записано: должен быть мандатный контроль. Ну а раз в правилах записано - или вынь и полож, или они эту систему юзать не будут. Насколько мандатный контроль защищает от напастей - вопрос далеко не однозначный. > Контейнеры дают ровно такую же защиту, как и LSM-based MAC (в частности, selinux). Практика показала что даже несколько лучшую. Во всяком случае, этот ваш selinux срубается реально существующими сплойтами в 2 счета(ищите новости о повышении прав в линухе, там же и сплойты были). А в контейнерах сплойт вообще не срабатывает, для начала. Это так, небольшая проверка теории практикой. Я допускаю что в некоторых случаях возможен и слом механизмов контейнерной изоляции. Однако возможностей для этого меньше, имхо. Потому как контейнер может быть минимальным, хорошо мониторимым и удобных точек атаки типа пульсаудио и прочих радостей там может и не быть. Даже под рутом. > В этой ситуации защитить могут только над-ядерные методы - гипервизор (xen) Логично, НО бывают еще и уязвимости в гипервизорах :-).Хотя в силу меньшего размера стоит ожидать что их там меньше. > тогда забудьте о такой вещи, как мандатный контроль доступа. Как-то похоже на оправдания. Как по мне - сравнимая (если не более хорошая) изоляция частей системы делается иными, менее геморными методами. А с MAC пусть всякие FBI сношаются, у которых подобных средств правила работы с документами и т.п. требуют.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	35. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от аноним on 01-Авг-10, 14:27
	>Во всяком случае, этот ваш selinux срубается реально существующими сплойтами в 2 счета(ищите новости о повышении прав в линухе, там же и сплойты были). Контейнеры - ровно так же. Срубаются в два счета. >А в контейнерах сплойт вообще не срабатывает, для начала. Да-да, для использования уязвимости в модуле tun нужен модуль tun, как ни странно. Но методов запретить подгрузку модулей и без контейнеров навалом. А вы подумайте о том, что будет, если уязвимость обнаружится в разрешенном модуле.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	48. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от User294 (ok) on 04-Авг-10, 02:16
	>Контейнеры - ровно так же. Срубаются в два счета. А пруф? Например, образец сплойта который вышибет хоть тот же опенвз? Примеры сплойтов срубающих селинукс - я видел в местных новостях. И действительно - он выпиливается. А на хоть той же опнвзе такие сплойты вообще не срабатывают. >Да-да, для использования уязвимости в модуле tun нужен модуль tun, как ни странно. В моей опенвзовой конфигурации он был, это не помогло. Все-равно не работало. Без опенвзы на физической машине - как из пушки. Из взового контейнера почему-то не работает. Может быть, я тупой, или криворукий, или что-то не понимаю в этой жизни (вероятно, детали реализации контейнеризатора?). Или чего-то упустил из вида. >Но методов запретить подгрузку модулей и без контейнеров навалом. Контейнеры не позволяют шариться по хосту даже руту с как-бы-полными правами. Полнота его прав ограничивается его песочницей. Может быть это и мешает сплойту? >А вы подумайте о том, что будет, если уязвимость обнаружится в разрешенном модуле. В теории - ну да, вероятно можно поиметь. На практике - у меня почему-то сплойт вообще не отработал из контейнера. Кстати не помню, tun ли это девайс, еще была другая уязвимость с повышением прав IIRC. А так - дыры в ядре такого калибра к счастью редкость. Контейнер хорош еще и тем что это четко разграниченная сущность. Даже если в его правах где-то лопухнуться/софт дырявый - вред заведомо ограничится только этой песочницей. Да и резка ресурсов штатная и удобная фича.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	27. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+2 +/–
	Сообщение от аноним on 01-Авг-10, 00:20
	Резюмируя: контейнеры дают ровно такую же степень защиты, как и LSM, при этом проще в настройке (особенно если автоматизировать развертывание окружений), но жрут гораздо больше ресурсов и не так гибки в настройке.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	30. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–5 +/–
	Сообщение от User294 (ok) on 01-Авг-10, 11:43
	>но жрут гораздо больше ресурсов Да не настолько уж и больше. Зависит от конкретики, конечно. Кстати думается что kernel same pages merging может сие пролечить. >и не так гибки в настройке. Напротив, гораздо гибче. В каждом может жить своя система. С своими настройками, своими квотами пожирания ресурсов хоста и прочая.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	36. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от аноним on 01-Авг-10, 14:29
	>>но жрут гораздо больше ресурсов > >Да не настолько уж и больше. Зависит от конкретики, конечно. Кстати думается >что kernel same pages merging может сие пролечить. А про то, что в каждом контейнере пашут всякие вспомогательные службы типа sshd, которые при правильной организации существуют в одном экземпляре, вы в курсе? >Напротив, гораздо гибче. В каждом может жить своя система. С своими настройками, >своими квотами пожирания ресурсов хоста и прочая. man cgroups Такие же квоты можно установить для любого процесса.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	49. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от User294 (ok) on 04-Авг-10, 02:48
	>А про то, что в каждом контейнере пашут всякие вспомогательные службы типа >sshd, которые при правильной организации существуют в одном экземпляре, вы в курсе? При некоторой организации процесса sshd можно и совсем не запускать (можно например с хоста пнуть все что надо) А у разных копий sshd даже при 100% одинаковом коде будут разными как минимум данные в памяти, т.е. некий оверхед всяко будет. Еще насчет экземпляров - могут быть shared либы, при том не обязательно совпадающих версий. Строго говоря - в чем-то типа опенвзы весьма распостранена практика содержания юзермодов от нескольких разных систем. В этом случае бухтеж насчет памяти валиден на 100%, т.к. в памяти висит куча разных версий процессов и либ. Взамен получается несколько "почти разных" систем и "как бы дебиан" может легко сосуществовать на одной и той же машине с "как бы центосом". Ессно кернел у всех один, но юзермод от соответствующих систем. >man cgroups Я в курсе про cgroups. Что сказать то хотели? Что вы ман читали и что полезная фича? Да, полезная фича и ман к ней интересный. Напоминает нечто типа опенвзы но прямо в ванильном ядре и пока явно попроще. >Такие же квоты можно установить для любого процесса. Мысль как-то неокончена. Ну, можно. И? Как по мне - контейнеры это простая для понимания и вполне себе эффективная и работающая изоляция как минимум не хуже селинуха. В какомнить опенвзе еще и удобно сделано - каждая песочница с точки зрения юзера похожа на независимую машину. Что и в плане изоляции отлично, и в администреже удобно. И не надо аться с политиками - слом "машины" заведомо затрагивает только то что на ней.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	6. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+1 +/–
	Сообщение от Аноним (??) on 31-Июл-10, 13:16
	>Ну из описания, например, не понятно какие у неё плюсы по сравнению >с SELinux. Главный плюс AppArmor в том, что с ней можно разобраться за 5 минут, там очень простая, очевидная и логичная система настроек. SELinux шею можно свернуть разбираясь с нюансах. Сравните политики для SELinux и правила AppArmor, это небо и земля.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от Аноним (??) on 31-Июл-10, 18:26
	Ну дык будь последовательным и: сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :) Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил ....
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	15. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–6 +/–
	Сообщение от User294 (ok) on 31-Июл-10, 22:20
	>Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил .... Первым можно задолбаться защищать систему и его могут сломать (смотрим как работают сплойты юзавшие повышение прав в линухе и делаем выводы). Второй внушает еще меньше доверия. Как по мне - лично я при параное пилю все на отдельные контейнеры просто. Изоляция - отличная. И долбаться с селинухом не надо.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	23. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от аноним on 31-Июл-10, 23:48
	>Первым можно задолбаться защищать систему Админа, который полез в серьезный продакшен, не затруднив себя изучением основ ремесла, в т.ч. базовых навков работы с selinux, нужно гнать в шею из этого продакшена. У того, кто selinux изучил, таких глупых проблем не возникнет. >его могут сломать (смотрим как работают сплойты юзавшие повышение прав в линухе и делаем выводы) Если уязвимость в ядре, могут сломать любой механизм изоляции, включая LSM-based MAC или те же контейнеры. >Как по мне - лично я при параное пилю все на отдельные контейнеры просто Очень продуктивно. По сравнению с selinux - сильно экономит место на диске, память и нагрзку на проц. Зато уровень защиты тот же.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	31. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–6 +/–
	Сообщение от User294 (ok) on 01-Авг-10, 12:04
	>У того, кто selinux изучил, таких глупых проблем не возникнет. В природе есть два мнения - ваше и неправильное? :) >Если уязвимость в ядре, могут сломать любой механизм изоляции, включая LSM-based MAC >или те же контейнеры. Сильно зависит от контейнеров. Практика показала что даже в простейших - почему-то эксплойты не срабатывают, а на просто железке SELinux отправляется нафиг в 2 счета. Хотя при особой параное насчет изоляции можно юзать виртуалки где гипервизор маленький и потому скорее всего содержит довольно мало багов. Сие было реализовано например Рутковской в ее параноидальной системе, например :) >Очень продуктивно. По сравнению с selinux - сильно экономит место на диске, При современных объемах дисков - сие проблемой вообще не является, имхо. Тем более что контейнеры могут быть небольшими, с минимальными окружениями. >память Вот это есть. Слегка для легких контейнеров, во весь рост для тяжелых полных виртуалок. Однако допускается что в продакшне большую ее часть жрут все-таки полезные сервисы и нужные для их работы сущнеости, а не окружение само по себе. Кстати в линух IIRC внедряют технологию объединения одинаковых страниц. При юзеже оной фичи должно полегчать - одинаковые куски системы будут в памяти 1 раз всего. >и нагрзку на проц. А что - нагрузка на проц? Минимальные и простые контейнеры (с степенью изоляции не хуже а может и лучше чем у селинукса и явно большими возможностями) - почти не отличаются от bare metal. Разница на несколько процентов максимум. Еще вопрос, не больше ли слопает SELinux: лишние проверки прав как бы не нахаляву происходят. Тяжелые штуки типа XEN - да, разумеется. Зато там вместо взлома ядра для полного поимения надо ломать гипервизор, что как-бы совсем иная степень защиты, рядом с которой SELinux и рядом не стоял. >Зато уровень защиты тот же. Практика показала что это не совсем так. Берем сплойт из новости про повышение прав в линухе. Огреваем им систему с селинухом. Наблюдаем как огребли рута и селинукс быстренько пошел к черту. Пробуем огреть чего-нибудь тем же сплойтом из хотя-бы опенвзового контейнера ... и обламываемся. Потому как сплойт вообще не срабатывает...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от аноним on 01-Авг-10, 14:18
	>Практика показала что это не совсем так. Берем сплойт из новости про повышение прав в линухе. Огреваем им систему с селинухом. Наблюдаем как огребли рута и селинукс быстренько пошел к черту. Пробуем огреть чего-нибудь тем же сплойтом из хотя-бы опенвзового контейнера ... и обламываемся. Потому как сплойт вообще не срабатывает... Ну вы сразу бы и говорили, что вы скрипт кидди, и ничего не понимаете в работе сплойтов, умеете только их запускать по редмишке. Чисто для справки - в тот единственный сплойт, который обезвреживал LSM (через дыру в коде tun-драйвера), добавить возможность выхода за пределы контейнера - совсем не проблема. Более того, тот код уже сам по себе был смертельно опасен для всей системы, и вместо получения рута туда можно было засунуть и запись в блочные устройства. Повторяю еще раз - практически всем дырам в ядре глубоко наплевать на контейнеры. Ядро одно на всех.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	50. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от User294 (ok) on 04-Авг-10, 03:42
	>Чисто для справки - в тот единственный сплойт, который обезвреживал LSM (через >дыру в коде tun-драйвера), добавить возможность выхода за пределы контейнера - >совсем не проблема. Да, если дело дошло до хоста и его ядра. А удастся ли спровоцировать проблему из контейнера? Судя по всему - удается это далеко не всегда. Насчет скрипткиддисов - нет, я просто давно ничего не ломаю и в данный момент - запускаю эксплойты сугубо на своих системах с целью проверки их дырявости и изучения возможностей их поимения другими. Кстати контейнеры бывают разные. Если взять полновесный виртуализатор типа Xen-а (хоть и заплатив за это тормозами и потреблением памяти) - для поимения хоста или соседних песочниц ломать надо мелкий гипервизор. Вон у рутковской параноидальная система есть, например. Специально на такие случаи как раз. >Более того, тот код уже сам по себе был смертельно опасен для всей системы, >и вместо получения рута туда можно было засунуть и запись в блочные устройства. Ну да, я понимаю что если ядро хоста раздолбили - можно сделать что угодно. Тем не менее, на практике - из опенвзового контейнера почему-то долбаться вообще не захотело. Насколько я понял - сплойт вообще ниасилил сделать какую-то нужную операцию из контейнера. Кстати не уверен что это было TUN а не сплойт, который махинации с виртуальной памятью юзал (mmap-эксплойт, вроде). >Повторяю еще раз - практически всем дырам в ядре глубоко наплевать на >контейнеры. Ядро одно на всех. Дельно говорите, НО контейнеры изменяют некоторые аспекты работы ядра. Есть подозрение что некоторые из этих изменений могут мешать работе сплойтов. Как минимум могу припомнить что махинации с виртуальной памятью из контейнера не срабатывали совсем, хотя ядро было уязвимое. А на "железке" - работало на ура.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	16. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–3 +/–
	Сообщение от Аноним (??) on 31-Июл-10, 22:26
	>Ну дык будь последовательным и: >сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :) > >Первым можно таки реально защитить систему. Вторым - можно сделать вид что >защитил .... AppArmor не ставит перед собой глобальных целей, он просто позволяет не дать запускаемому приложению больше, чем нужно, отсекая все лишнее. Этого в подавляющем большинстве случаев более чем достаточно.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	24. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+2 +/–
	Сообщение от аноним on 31-Июл-10, 23:50
	>AppArmor не ставит перед собой глобальных целей, он просто позволяет не дать >запускаемому приложению больше, чем нужно, отсекая все лишнее. Этого в подавляющем >большинстве случаев более чем достаточно. Так должна работать нормальная система MAC, например, selinux в targeted-режиме. apparmor, с учетом его тотальной уязвимости, лишь создает видимость защиты.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	28. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–3 +/–
	Сообщение от StrangeAttractor (ok) on 01-Авг-10, 02:59
	> сравни _возможности_ SELinux и AppArmor, это небо и земля.(С) :) > Первым можно таки реально защитить систему. Вторым - можно сделать вид что защитил .... Рискну высказать своё некомпетентное (в уме не е-у ни байта ни про SELinux ни про AppArmor) мнение. В руках некого админа надёжна только та система, в т.ч. система защиты, которую он полностью понимает. И чем проще система, тем она практически надёжней. По этому AppArmor вроде как предпочтительнее. А если не понимаешь ни то ни то, лучше вообще выпилит их нафиг и настраивать секюрити по-старинке, что я и делаю. А плодить дополнительные сущьности, пытаться защищаться надстройками не будучи уверенным (а если был бы - так они и не нужны) в том, что внутри - дело сомнительное.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	9. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+7 +/–
	Сообщение от аноним on 31-Июл-10, 15:41
	>Ну из описания, например, не понятно какие у неё плюсы по сравнению с SELinux. Не надо сравнивать кислое с длинным. selinux - для защиты промышленных серверов, обслуживаемых квалифированными админами. Поэтому пофиг на простоту, там главное гибкость и мощь. apparmor, smack, tomoyo - для защиты десктопа юзера Васи или шлюза маленького офиса, поднятого стунентом за полставки. Вот тут гибкость уже на последнем месте, а на первом - простота. Другое дело, что непонятно, какие плюсы есть у apparmor по сравнению с тем же tomoyo. tomoyo умеет все то же самое плюс еще многое (например, "контроль контекста вызова" - офигенная фича), и в ядре уже относительно давно, и настройки у него такие же простые. Видимо, убунтовцы просто поленились переписывать конфиги, решив, что легче будет просто протолкнуть apparmor в ядро. Что ж, уних это удалось, рад за них. Но вот за ядро обидно.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	18. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–5 +/–
	Сообщение от User294 (ok) on 31-Июл-10, 22:36
	>Поэтому пофиг на простоту, там главное гибкость и мощь. Не согласен. Если система сложная, админу труднее умещать ее в своей голове. Растет риск облажаться. Как по мне - проще сервак на контейнеры нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	21. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от slepnoga (??) on 31-Июл-10, 22:51
	>>Поэтому пофиг на простоту, там главное гибкость и мощь. > >Не согласен. Если система сложная, админу труднее умещать ее в своей голове. >Растет риск облажаться. Как по мне - проще сервак на контейнеры >нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше. > Админу? тык кто его пустит то политики вертеть ? Не его это дело, а таки спеца по  ИТ безопасности. Дело админа - применить или протестить. Если это все по другому сделано - то и селинух там нафик не нужен
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	32. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–2 +/–
	Сообщение от User294 (ok) on 01-Авг-10, 12:14
	>Админу? тык кто его пустит то политики вертеть ? Не его это дело, а таки спеца по >ИТ безопасности. Угу, для управления парой серверов ща отрастим бюрократическую машину по принципу "один солдат и куча начальников" :-). Не, в здоровом энтерпрайзе это может и реально, однако я видел весьма серьезные энтерпрайзы которых давила жаба на такую схему. Самое странное что глобальных поимений почему-то не наблюдалось. >Дело админа - применить или протестить. Похоже на обоснование нужности выделенного безопасника. А энтерпрайзы с вами согласны? В лично моем понимании - хорошо когда есть кто-то прорабатывающий стратегии защиты, однако по моим наблюдениям энтерпрайзы часто не желают платить такому специалисту адекватную зарплату. А зарплата уровня стандартного эникейца для такого спеца - гхм, извините не прикольно как-то.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	25. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+2 +/–
	Сообщение от аноним on 31-Июл-10, 23:55
	>Не согласен. Если система сложная, админу труднее умещать ее в своей голове. >Растет риск облажаться. Вы, видимо, просто никогда не работали с selinux. Да, для изучения базовых навыков работы с этой системой нужно затратить некоторые усилия, пошевелить мозгом (для этого, кстати, необходим сам мозг). Но, поняв внутреннюю логику системы и усвоив базовые операции, человек уже никогда там не заблудится. Это как арифметика. >Как по мне - проще сервак на контейнеры нарезать чем изгаляться с селинухом. Изоляция на уровне и возни меньше. Вам - меньше, серваку - больше.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	33. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–4 +/–
	Сообщение от User294 (ok) on 01-Авг-10, 12:22
	>Вы, видимо, просто никогда не работали с selinux. Как вам сказать? Я посмотрел на его политики, сломал моск и решил что могу не хуже более иными методами. >Да, для изучения базовых навыков работы с этой системой нужно затратить некоторые >усилия, пошевелить мозгом (для этого, кстати, необходим сам мозг). Но, поняв >внутреннюю логику системы и усвоив базовые операции, человек уже никогда там >не заблудится. Хотите сказать что весь набор прав по системе умещается в вашей голове? Круто, а мне не хочется столько левого дерьма в голове держать. Я могу сделать не хуже по изоляции и гораздо проще в плане понимания того что и кому в данный момент в этой конструкции льзя и нельзя. >Это как арифметика. Угу, только есть некая разница >Вам - меньше, серваку - больше. Не настолько уж и больше. Тем более что когда система проще - она предсказуемее и легче проверить что используется именно задуманный набор прав (в контейнерах по типу 1 контейнер на сервис сие получается автоматически).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	37. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от аноним on 01-Авг-10, 14:33
	>Как вам сказать? Я посмотрел на его политики, сломал моск и решил >что могу не хуже более иными методами. Позвольте узнать, ваше знакомство с арифметикой закончилось так же? >Хотите сказать что весь набор прав по системе умещается в вашей голове? Ага, а еще я компилирую в уме программы, и компьютер мне вообще не нужен. Перестаньте глупости писать. >Я могу сделать не хуже по изоляции Но и не лучше. И при этом гораздо хуже по эффективности использования ресурсов.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	51. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от User294 (ok) on 09-Авг-10, 13:26
	>Позвольте узнать, ваше знакомство с арифметикой закончилось так же? Нет, почему же, я знаю и высшую математику. Только, простите, я успешно забыл навороченные доказательства ряда теорем. Просто в силу нерезиновости головы и ненужности мне такого объема информации по данному аспекту. Это не означает что я не смогу применить матемтический аппарат к нужным лично мне задачам. Грубо говоря - я знаю математику на том уровне который требуется для моих задач. Это включает и некоторые компоненты высшей математики, не то что арифметику. Вот и тут так же - мне не за чем держать в моей бошке все эти селинуксовые навороты, если примерно то же самое по результативности (а может и лучше) получается иными методами. В 100500 раз более простыми. >Ага, а еще я компилирую в уме программы, и компьютер мне вообще >не нужен. Перестаньте глупости писать. Что за левые набросы? >>Я могу сделать не хуже по изоляции >Но и не лучше. При попытке огреть опенвзовый контейнер сплойтом делавшим махинации с виртуальной памятью для повышения прав - сплойт вообще не сработал, не осилив нужные операции. Подозреваю что контейнеризатор их завернул. А на железяке сработало как из пушки. >И при этом гораздо хуже по эффективности использования ресурсов. По CPU и Disk speed - почти как железяка, а disk space не так уж и дорог в 2010 году. Да и RAM по сути только на сами процессы и тратится. Может и будет какой-то оверхед но зато как бы и гарантии есть что если есть некто днс-сервак и мы точно знаем что ему надо столько таких и сяких ресурсов - больше он сожрать не сможет. Даже если его раздолбают хацкеры-фигацкеры.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	7. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+4 +/–
	Сообщение от MidNighter on 31-Июл-10, 13:16
	> Тебе оно мешает? Не хочешь - не используй. А давайте wine в ядро запхнём! А чего, хочешь используй - не хочешь используй!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	11. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от аноним on 31-Июл-10, 15:49
	>А давайте wine в ядро запхнём! Да вроде как уже (см. longene). Правда, не mainstream, что радует.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	19. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от User294 (ok) on 31-Июл-10, 22:37
	>А давайте wine в ядро запхнём! Не ядерный код -> не запихнем.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	8. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+1 +/–
	Сообщение от KERNEL_PANIC (ok) on 31-Июл-10, 14:18
	> Тебе оно мешает? Не хочешь, не используй Так все в ядро пихнуть можно. Оно и так уже раздуто, по самый не могу, даже Линус по этому поводу паникует. Если так дело и дальше пойдет, то ядро скоро гиг и больше весить будит. Кому надо - наложит патч, это не сложно. Я не собираюсь его использовать, для меня это лишнюю опцию при сборке ядра отключать, и повышает время компиляции имхо.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+1 +/–
	Сообщение от аноним on 31-Июл-10, 15:45
	>Вреда не принесет, а польза будет явно Неа. Пользы по сравнению с tomoyo ноль, а вред может "принестись" запросто. Чем больше кода в ядре, там труднее его нормальный аудит, и поэтому добавление каждого KLOC в ядро делает его все более уязвимым.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+3 +/–
Сообщение от аноним on 31-Июл-10, 16:13
Вообще, в случае локального/удаленного рута apparmor будет защищать не лучше пресловутого фИгового листика. Он же приниципально не котролирует права на mount -bind. Получив возможность запускать код от рута, первым делом биндим /bin, /sbin и т.п. куда-нибудь в тихое местечко, и вуаля - вся система наша, что есть apparmor, что нет его. Даже простой tomoyo, при правильной настройке, может очень сильно обломать кайф таким ксакепам. А apparmor - нет, при всем желании.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
Сообщение от i (??) on 31-Июл-10, 22:32
почему никто на grsecurity не обращает внимания? что там не так? http://www.grsecurity.net/features.php
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+1 +/–
	Сообщение от slepnoga (??) on 31-Июл-10, 22:47
	Там уже можно вилдкард для дир ? Нет - ну запиливаем обратно на сервак без юзверей. Или оно уже научилось метить трафик и имеет сервер политик ? То же нет? Ну и еще пересобрать всю систему, что для кучи народа совершенно неприемлимо. О, девы уже могут писать полтики для грсека или админу все так же надо трахать себе моск на каждой отдельной машине , вместо их раздачи по сети ?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

38. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
Сообщение от segoon (ok) on 01-Авг-10, 21:49
В новости ни слова об OpenWall/*/Linux, хотя первые 2 из трёх возможностей Yama основаны именно в нём: http://www.openwall.com/linux/README.shtml Documentation/Yama.txt: This protection is based on the restrictions in Openwall and grsecurity.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
Сообщение от gapsf2 (ok) on 02-Авг-10, 06:30
RSBAC - http://www.rsbac.org/ - гибче и мощнее. Но включать в ядро его не хотят.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–3 +/–
	Сообщение от Yuriy (??) on 02-Авг-10, 14:48
	>RSBAC - http://www.rsbac.org/ - гибче и мощнее. >Но включать в ядро его не хотят. ну хоть ктото наконец то про него написал из всего сброда что радует:)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

41. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
Сообщение от Роман (??) on 02-Авг-10, 15:18
Отсутствие нормально спроектированной, последовательной подсистемы безопасности в Linux приводит к необходимости вот таких костыльных решений. В этом смысле архитектура безопасности Windows не в пример лучше - единый механизм защиты для любого системного объекта.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от segoon (ok) on 02-Авг-10, 17:06
	Вы про ACL или ещё что-то? ACL уже давно есть.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	44. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от Роман (??) on 02-Авг-10, 19:04
	>Вы про ACL или ещё что-то? ACL уже давно есть. Для произвольного системного объекта (подлежащего защите) или только для файлов? Как насчёт ACL для семафоров, разделяемой памяти (shm)?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	43. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от segoon (ok) on 02-Авг-10, 17:17
	>Отсутствие нормально спроектированной, последовательной подсистемы безопасности в Linux приводит к необходимости вот >таких костыльных решений. > >В этом смысле архитектура безопасности Windows не в пример лучше - единый >механизм защиты для любого системного объекта. Тут, кстати, я полностью верю в закон Дарвина :) Чем больше подсистем безопасности в апстриме (читай - на виду у всех), тем лучше их можно изучить, выявить слабые и сильные места и пр. Если не появится явного лидера, то уже существующие сгладят свои острые углы. Вот, к примеру, начало жаркого обсуждения почему _нужны_ несколько security подсистем: http://lkml.org/lkml/2007/10/1/192 И как вы, мне интересно, нормально спроектируете систему политики безопасности, которая удовлетворяла бы _всех_/почти всех?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	–1 +/–
	Сообщение от Роман (??) on 02-Авг-10, 19:25
	>Чем больше подсистем >безопасности в апстриме (читай - на виду у всех), тем лучше >их можно изучить, выявить слабые и сильные места и пр. Если >не появится явного лидера, то уже существующие сгладят свои острые углы. > >И как вы, мне интересно, нормально спроектируете систему политики безопасности, которая удовлетворяла >бы _всех_/почти всех? Я не против модульности в системе безопасности. В конце концов, в Windows это тоже фактически отдельный модуль (Security Reference Monitor) статически влинкованный в ядро. Я об общей её архитектуре. Если в Windows продвинутая модель безопасности закладывалась на этапе проектирования (линейка NT), то Linux изначально и by design ограничен unix-моделью, а прордвинутые фишки добавлены задним числом (я бы даже сказал - через задний проход) в виде LSM.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	46. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от segoon (ok) on 02-Авг-10, 20:56
	А вы в курсе того, на что способна эта unix-модель? Когда она была создана, какие задачи она должна решать (и ведь решает до сих пор!), и где её возможности кончаются?) Вы можете назвать популярные проблемы, которые в классической модели posix не решаются или решаются криво? Правительственные многоуровневые модели прав к таковым не относить. Простота unix даёт о себе знать, в настройке простой вещи намного сложнее ошибиться, чем в сложной (простите за каламбур).
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	47. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
	Сообщение от segoon (ok) on 02-Авг-10, 21:56
	Кстати, про by design... В Windows множество ошибок, в т.ч. безопасности, были именно by design. Если выбирать между много всего, в т.ч. ошибок, и ограниченно, но контролируемо, то я лучше выберу второе.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

52. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
Сообщение от nagual (ok) on 05-Дек-10, 04:19
В виндовсе в какой то мере соблюдается обратная совместимость с предыдущими версиями. Это очень тяжелое бремя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "AppArmor и Yama будут включены в Linux-ядро 2.6.36"	+/–
Сообщение от Аноним (??) on 21-Мрт-17, 19:11
>Он же приниципально не котролирует права на mount -bind. Получив возможность запускать код от рута, первым делом биндим /bin, /sbin и т.п. куда-нибудь в тихое местечко, и вуаля - вся система наша, что есть apparmor, что нет его А вот и контроилирует: без capability sys_admin, mount --bind и pivot_root невозможны. >Если вы скопируете, например, утилиту ping из каталога /bin/ в каталог /usr/bin или переименуете ее в my_ping, то никакие ограничения AppArmor на нее действовать уже не будут – не будет профиля для «новой» программы. Во первых, не скопируем, потму что у пофили это обычно блокируют. Даже если скопируем - не запустим, так как на запуск право дается избранным файлам. Даже если запустим - запущенное приложение унаследует ограничения родительского профиля. >Распознавание приложений и, соответственно, определение их полномочий, производится по имени исполняемого файла. Именно этот момент очень часто выступает ключевым в критике AppArmor. Действительно, подменив имя исполняемого файла, злоумышленник может вывести приложение из-под контроля AppArmor. Самый простой пример — создание жесткой ссылки. Более сложный вариант — выполнение mount --bind или pivot_root. Хрен там раз: AppArmor контролирует создание ссылок, куда попало ссылку не кинешь. Хрен там два: без capability sys_admin, mount --bind и pivot_root невозможны. >Недостаток такого подхода заключается в том, что при создании жесткой символической ссылки приложение «уходит» из-под контроля системы безопасности. AppArmor это успешно контролирует через l, >В частности, TOMOYO, в отличие от AppArmor, позволяет контролировать права на операции mount --bind и pivot_root Врёти, без capability sys_admin, ничего у вас не выйдет, а большинство профилей в этом разрешении не нуждаются (точнее не видел ни одгого такого профиля). >Даже простой tomoyo, при правильной настройке, может очень сильно обломать кайф таким ксакепам. А apparmor - нет, при всем желании. >Вообще, в случае локального/удаленного рута apparmor будет защищать не лучше пресловутого фИгового листика. Врёти, ваши доказательства не доказательства и разгромлены выше.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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