Один из администраторов инфраструктуры kernel.org опубликовал в списке разработчиков ядра Linux уведомление (https://lkml.org/lkml/2011/9/23/357), в котором рассказал о статусе восстановления серверов после взлома (http://www.opennet.me/opennews/art.shtml?num=31651) и работе, проделанной для увеличения безопасности. Kernel.org недоступен уже почти месяц. Столь длительный срок связан с тем, что разработчики были заняты детальным аудитом и полной переработкой архитектуры аутентификации и организации доступа во всех публично доступных сервисах kernel.org.
Возобновить работу сайта в первозданном виде, переустановив операционную систему и восстановив данных из резервной копии, можно было за несколько часов, но такой шаг не устраивал, так как инцидент показал принципиальные недоработки в организации доступа, которые рано или поздно могли привести к повторному взлому. В частности, наличие shell-аккаунтов у 448 разработчиков потенциально делали каждого из них мишенью для атакующих. В случ...URL: https://lkml.org/lkml/2011/9/23/357
Новость: http://www.opennet.me/opennews/art.shtml?num=31845
Вот уж действительно основательный подход. И наверно это довольно серьезный удар по имиджу Linux, как основы безопасной системы. Хотя я честно рад, что большинство из линуксойдов все же прежде всего гики, и наверно прекрасно понимают, что абсолютно безопасных систем не бывает, а ребята из kernel.org молодцы: возникшие проблемы требуют серьезных действий, и они это сделали.
>...это довольно серьезный удар по имиджу Linux, как основы безопасной системы...Только для неспециалистов.
>>...это довольно серьезный удар по имиджу Linux, как основы безопасной системы...
> Только для неспециалистов.А рекламируемая безопасность OpenBSD - это тоже для неспециалистов?
>А рекламируемая безопасность OpenBSD - это тоже для неспециалистов?Да.
> А рекламируемая безопасность OpenBSD - это тоже для неспециалистов?У рекламируемых специалистов разок случился весьма годный FAIL с их OpenSSH: их сервер вскрыли и подменяли сырец OpenSSH. Отмазка удивила своей инфантильностью: мы, типа, голодранцы, своего сервера у нас нет. Поэтому мы использовали чужой, а там накосячили с администрированием. Блин, да какая мне разница как именно меня через вас поимели?!
>> А рекламируемая безопасность OpenBSD - это тоже для неспециалистов?
> У рекламируемых специалистов разок случился весьма годный FAIL с их OpenSSH: их
> сервер вскрыли и подменяли сырец OpenSSH. Отмазка удивила своей инфантильностью: мы,
> типа, голодранцы, своего сервера у нас нет. Поэтому мы использовали чужой,
> а там накосячили с администрированием. Блин, да какая мне разница как
> именно меня через вас поимели?!может быть тогда ты покажешь версию того, что у тебя в качестве sshd используется? или админу локалхоста не нужен ssh[d]? ;-)
>может быть тогда ты покажешь версию того, что у тебя в качестве sshd используется?0.53.1
>>может быть тогда ты покажешь версию того, что у тебя в качестве sshd используется?
> 0.53.1Я не любитель тяжеловесной и переусложненной блоатвари.
Не то чтобы мне ресурсов жалко - просто переусложнение и набивание лишней функциональностью сильно увеличивает объем кода и вероятность наличия в нем ошибок, критичных для безопасности.
> может быть тогда ты покажешь версию того, что у тебя в качестве sshd используется?0.53. Это хорошо или плохо?
Это? Это печально.
Печально - это 5.9. А 0.53 - это ок.
> может быть тогда ты покажешь версию того, что у тебя в качестве
> sshd используется? или админу локалхоста не нужен ssh[d]? ;-)Кстати, а с мутной историей про ipsec и бэкдоры там хотя-бы разобрались уже? И каков вывод - есть ли бэкдор на данный момент? Где результаты аудита? Дофига ж времени уже прошло?
> Кстати, а с мутной историей про ipsec и бэкдоры там хотя-бы разобрались
> уже? И каков вывод - есть ли бэкдор на данный момент?
> Где результаты аудита? Дофига ж времени уже прошло?Там не совсем что бы бекдор, вся фишка заключается в том что при некорректной настройке IPSEC есть высокая вероятность скомпроментирования системы, а если еще более точно то там какая то фитча указанная по дефолту в конфиге не совсем корректно работает - вобщем вся суть в том что надо знать что включать и как включать (функционал)
в общем как то так...
>А рекламируемая безопасность OpenBSD - это тоже для неспециалистов?
>>рекламируемаяТот, кто верит рекламе - разве специалист?
Реклама бывает не только навязчивая, можно наоборот как бы прятaть информацию и рекламировать сам факт сложности доступа, чтобы как раз таких "умников" ловить. Специалисты блин.
> И наверно это довольно серьезный удар по имиджу LinuxВо первых, вопрос не в том, что систему нельзя сломать. Преимущество Линукса в том, что его архитектура максимально затрудняет возможность взлома. И это учитывая полностью открытый код! Представьте что будет, если открыть код для той же Винды - и без того большое количество хакерских/вирусных лазеек под нее ожидаемо увеличится в разы!
Во вторых: кто сказал, что проблема kernel.org была в Линуксе, а не, скажем, в настройке серверов администраторами? Сегодня большинство серьезных компаний используют Линукс и ему подобные ОС как систему с большим запасом безопасности. Даже военные сидят на Линуксе, скажем, в Сша и России.> большинство из линуксойдов все же прежде всего гики
Пользователь Линукса ничем не отличается от пользователей других ОС. Есть неопытные, которым достаточно браузера и пары приложений. Есть более опытные, занимающиеся администрированием, работающих с консолькой...
Зачем мазать всех одной краской? Чтобы отпугнуть потенциальных неопытных пользователей, читающих Ваши комментарии, "надуманной сложностью" Линукса? Линукс давно уже сравнялся по простоте работы с другими популярными ОС.> а ребята из kernel.org молодцы
После ушата грязи следует положительная фраза, чтобы скрыть свое полностью отрицательное отношение к предмету разговора и не вызвать сильной критики со стороны читателей, так как в основном все с этой фразой согласны...
Не хочу Вас обидеть, но нельзя не заметить что Ваша скрытая анти-реклама Линукса по стилистике напоминает приемы времен Геббельса...
> Не хочу Вас обидеть, но нельзя не заметить что Ваша скрытая анти-реклама
> Линукса по стилистике напоминает приемы времен Геббельса...Других способов защиты винды, кроме откровенного вранья и промывания мозгов - просто не существует.
>> Не хочу Вас обидеть, но нельзя не заметить что Ваша скрытая анти-реклама
>> Линукса по стилистике напоминает приемы времен Геббельса...
> Других способов защиты винды, кроме откровенного вранья и промывания мозгов - просто
> не существует.Никто не защищает Венду. Местную публику призывают открыть глаза и перестать истерить на тему Венда-дыра, Линух-непробиваемая стена. Всё.
> Никто не защищает Венду. Местную публику призывают открыть глаза и перестать истерить
> на тему Венда-дыра, Линух-непробиваемая стена. Всё.Любая ОС - дыра по определению. Просто у винды эта дыра огромна, а линукса - сравнительно небольшая.
> Любая ОС - дыра по определению. Просто у винды эта дыра огромна,
> а линукса - сравнительно небольшая.Просто у линукса дыру можно и самому заштопать и вообще применить нестандартные техники защиты, типа Qube OS от Рутковской. А в винде - только и остается что ждать патчей и надеяться что до их выхода - не раздолбают. А альтернативные техники защиты в силу общей огороженности системы малобюджетным исследователям сложно делать. А как защищают разрекламленные защиты за много баксов - видно на примере DigiNotar. Хорошо защитили - компания стала банкротом!
Истерят, вообще-то, залётные виндузятники, потому что на дыре они, а не мы. Раскройте глаза.
> Вот уж действительно основательный подход. И наверно это довольно серьезный удар по
> имиджу Linux, как основы безопасной системы.Так покажите безопасную систему? :) Только чур не надо про винды, DigiNotar вон 21 числа обанкротился благодаря взломщикам.
> Так покажите безопасную систему? :) Только чур не надо про винды, DigiNotar
> вон 21 числа обанкротился благодаря взломщикам.Ответ вполне предсказуем. Кернел.орг взломали -> все претензии к дырявости винды автоматически аннулируются.
> Ответ вполне предсказуем. Кернел.орг взломали -> все претензии к дырявости винды автоматически аннулируются.Ну понятно - если в свой глаз влетело бревно, надо срочно кинуть соломинку в глаз конкурента. Только вот полный дестрой IT инфраструктуры, выпуск 250+ фэйковых сертификатов и в результате банкротство CA - это как-то позлее будет чем взлом кернелорга где наиболее ценный материалец - хрен запатчишь так по простому.
> Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что уявзвимости ядра которые требуют shell акаунта - это не критические. Неужели такая серьезная компания врала?
для ядра - не критические. Если уж доступ к shell получен - ошибка где-то выше.
а для хостеров ?:)
то есть linux безопасен только как сферический конь в вакуме?
Тут недавно windows обливали грязью за то что от любого пользователя можно получить админа, а выходит linux нефига не лучше? Через дырявый php скрипт запустили утилитку и ву-аля.. вот он админ.
И это нефига не критическая проблема :)
А кто виноват, что запускает дырявый php-скрипт? ;)
никто.
Но называть некритической дырку через которую можно получить рута от непривилигированного акаунта - мягко скажем не корректно.
> А кто виноват, что запускает дырявый php-скрипт? ;)Когда поимеешь проблемы на работе, тебе будет глубоко пофигу "кто виноват". А сам ты весь пхп код всеравно проверять не будешь.
> Когда поимеешь проблемы на работе, тебе будет глубоко пофигу "кто виноват". А
> сам ты весь пхп код всеравно проверять не будешь.Ну так запустите мой код, который совсем не троян?! Вообще, белый и пушистый кот. Хакер Вася Пупкин подтвердит - никаких троянов, что вы! Раз весь код не проаудитишь - давайте запускать что попало. Например можно мой скриптик запустить. Не хотите? :)
> можно мой скриптик запустить. Не хотите? :)Нет, твой не хочу. Ты походу даже не понял, на что отвечаешь. Выше написали про дырявый пхп на хостинге. Речь идет про дырявые php сайты (частных вебстудий) и неизвестные уязвимости в известных php продуктах.
> неизвестные уязвимости в известных php продуктах.отчего же «неизвестные»? известные, называются «php-погромисты».
тут собрались админы localhost - они с трудом понимают проблемы хостеров.
Хотел бы я посмотреть как бы они каждый скрипт который заливают клиенты просматривали - и решали - быть ему на хостинге или нет..
Оченььь интересно было посмотреть.
> тут собрались админы localhost - они с трудом понимают проблемы хостеров.
> Хотел бы я посмотреть как бы они каждый скрипт который заливают клиенты
> просматривали - и решали - быть ему на хостинге или нет..
> Оченььь интересно было посмотреть.Мусье админит кластеры амазон йецедва? Есть ли сложности в прокладке очередной 6 киловольтной ЛЭП до нового сервера? Как решаете проблемы с мелкими но болезненными для имиджа восстаниями местной черни, лопочущей чтото там про экологию ? Хотелось бы уточнить, насколько регулярно надо отстегивать лоббистам рядом с оральном кабинетом? А то мы тут совсем темные локалхостеры.
Поддерживаю. Если так"Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени."
начнут считать не только авторы новостей, но и те, кто непосредственно занимается Linux, то можно ставить жирный крест на это ОС.
> начнут считать не только авторы новостей, но и те, кто непосредственно занимается
> Linux, то можно ставить жирный крест на это ОС.Почитайте про последние взломы SourceForge, GNU.org и т.п. Везде взломщики смогли получить root. Иногда приходится годами ждать момента, но такой момент бывает когда о дыре уже стало известно, а обновление с исправление еще не пришло. Более того, скажу вам, что просто читая changelog последних тестовых и не тестовых выпусков ядра Linux можно эмпирически выявить кучу дыр. Для примера смотрите secunia.com, через пару дней после каждого обновления ядра бывают отчеты о дырах, которые в changelog очень нейтрально описаны.
>> начнут считать не только авторы новостей, но и те, кто непосредственно занимается
>> Linux, то можно ставить жирный крест на это ОС.
> Почитайте про последние взломы SourceForge, GNU.org и т.п. Везде взломщики смогли получить...
> бывают отчеты о дырах, которые в changelog очень нейтрально описаны.savannah.gnu.org? Нет свидетельств получения root'a. sourceforge? Опять же не вижу, про root'a. При чем тут последние тестовые ядра? Я считаю, это ошибка использовать Fedora на продакшен серверах. Так что я бы предпочел увидеть changelog LTS ядер с описанием дыр.
> savannah.gnu.org? Нет свидетельств получения root'a. sourceforge? Опять же не вижу, про
> root'a.И там и там подменили sshd и снифили пароли пользователей, что подразумевает наличие root-прав.
> При чем тут последние тестовые ядра?
При том, что если ошибка исправлена, с большой вероятностью она появилась не вчера и также присутствует в ядрах, используемых в дистрибутивах.
>> savannah.gnu.org? Нет свидетельств получения root'a. sourceforge? Опять же не вижу, про
>> root'a.
> И там и там подменили sshd и снифили пароли пользователей, что подразумевает
> наличие root-прав.Да, про source forge есть такое (про savannah хз). Но это не означает повышение привилегий через kernel bug. Может, воспользовались тем паролем, что добыли из sql базы.
>> При чем тут последние тестовые ядра?
> При том, что если ошибка исправлена, с большой вероятностью она появилась не
> вчера и также присутствует в ядрах, используемых в дистрибутивах.Сомнительная вероятность. Есть примеры, когда ошибки появились в последних версиях и старые не затрагивают или наоборот. Добавить сюда различия в дистрибутивных патчах. Зато однозначно очевидно: чем дольше используется ядро, тем больше вероятность, что в нем пофиксят баг. А презентовать Linux как однопользовательскую ОС - это как-то... кхм...
> root. Иногда приходится годами ждать момента, но такой момент бывает когда
> о дыре уже стало известно, а обновление с исправление еще не
> пришло.Я правильно понял, что ты именно так и "ломаешь" сайты? Найдешь заброшенный сайт, который не меняют годами, с SQL и делаешь на него закладку "авось да когда-нибудь"? По-моему это почти то же самое, что дождаться, когда сервер помрет от старости, а потом сказать, что произвел DoS атаку.:)
:) это врядли. альтернативы существенно хуже, да и методы организации доступа чётко говорят, что пользователей в шелл в большинстве случаев пускать не надо
>Через дырявый php скрипт запустили утилитку и ву-аля.. вот он админ.Админ виртуального контейнера, поздравляю.
>>Через дырявый php скрипт запустили утилитку и ву-аля.. вот он админ.
> Админ виртуального контейнера, поздравляю.Где вас таких неумелых учат.
через дырку в ядре - становится полным админом ибо выполняет код с привилегиями ядра, а не процесса.
С привелегиями ядра, вы уверены? Не различаете пользователя/суперпользователя и kernel/user-space? Получив рута в том же контейнере OpenVZ, KVM, Xen etc, вы сломаете только конкретный контейнер, для того все эти вещи умные дядьки и придумали. ;)
> С привелегиями ядра, вы уверены? Не различаете пользователя/суперпользователя и kernel/user-space?
> Получив рута в том же контейнере OpenVZ, KVM, Xen etc, вы
> сломаете только конкретный контейнер, для того все эти вещи умные дядьки
> и придумали. ;)Смотря о чем речь. Ежели речь не о всяких hardware-assisted виртуализациях (как KVM и Xen), а про OpenVZ, то ядро там в ring 0, а изоляция только в том, что контейнерам приурезаны допустимые сисколлы. Но если уж есть вариант как в kernel space запустить произвольный код, то все, машина полностью, как говорят братья наши школьные, pwned.
С ring 1, ясен пень, такого не будет, там дальше, атаковать надо гипервизор, а там ошибку найти труднее, он мельче и проще.
Уверен. А вы видимо сказок о невзламываемости OpenVZ начиначилсь?
Смею огорчить - половина из них - это реклама одной конторы - которая долгое время ложила на GPL, и при этом на нее никто не наезжал.Linux-vserver в свое время тривиально позволял выпрыгивать из песочницы поимев рута в контейнере.
OpenVZ чуть сложнее - но и там, метка "контейнер" - это только число в struct task + указатель на лимиты (которые мягко скажем тут наплевать). так что имея возможность выполнить что либо в контексте ядра - стать админом host - мягко скажем тривиально.Дальше объяснять? или возьмете букварик и пойдете читать домашнее задание?
> OpenVZ чуть сложнее - но и там, метка "контейнер" - это только
> число в struct task + указатель на лимиты (которые мягко скажем
> тут наплевать). так что имея возможность выполнить что либо в контексте
> ядра - стать админом host - мягко скажем тривиально.Тут все зависит от уровня паранойи и потребности в скорости. OpenVZ + набор ловушек для автоматического шатдауна контейнера и аларма админу например вполне вариант. Хотя для особых параноиков лучше что-то типа Xen, хоть он и сажает скорость дисков нещадно.
> набор ловушек для автоматического шатдауна контейнера и аларма админу напримерНу покажите мне такой набор ловушек. Желательно в сочетании с историей успеха.
> Ну покажите мне такой набор ловушек. Желательно в сочетании с историей успеха.Да блин, набор скриптов самопальных, заменяющих некоторые стандартные команды на нечто немного более лулзовое, с разносом сервисов по контейнерам/виртуалкам. Пишется за 15 минут любым школьником на коленке. При том чем нестандартнее - тем лучше: фактор неожиданности совсем не лишний. Лучшая защита - превентивное нападение ;)
А за историями успеха - это вам к MS, они так красочно расписывали как они LSE на виндус и дотнет перевели, что хотелось побежать и купить! Правда вот новости по соседству были другого мнения - там было что-то про завал торгов на 8 часов и про то что заявленные времена транзакций дотнетчики так и не достигли :). Сейчас до MS дошло вроде, что их вранье очень уж эпично смотрится рядом с такими новостями и кажется они все-таки убрали уже свою "историю успеха". Но кто-то видимо желает добавки :)
>> набор ловушек для автоматического шатдауна контейнера и аларма админу например
> Ну покажите мне такой набор ловушек. Желательно в сочетании с историей успеха.А хотите пять минут лечебного смеху с утра? :) Ко мне вот на такое ловились: http://sisyphus.ru/srpm/apache-honeypot (хотя казалось бы, ну куда уж проще).
Ну не используйте OpenVZ, кто ж вам мешает, или вас его разработчики страстно поимели? Имея экплоит для всего можно взломать всё. У вас какая-то сказка со счастливым концом получается: ломануть ssh -> ломануть рута -> ломануть openvz-тюрьму -> выйти наружу.
Ну давай, напиши рабочий сценарий, умник. Это тебе домашнее задание.
> какая-то сказка со счастливым концом получается: ломануть ssh -> ломануть рута
> -> ломануть openvz-тюрьму -> выйти наружу.Чисто теоретически такое возможно, поэтому для особо параноидальных применений можно все это поверх виртуалочек в XEN например запустить. Пусть хаксоры слетят с катушек пытаясь понять - что за лабиринт отражений такой, в который они попали :)
> С привелегиями ядра, вы уверены? Не различаете пользователя/суперпользователя
> и kernel/user-space?Так человек будто и говорил про запуск произвольного кода в контексте ядра. Из относительно недавнего -- коркомёт (хорошо, что в альте он из коробки по схожим соображениям отключен и дырка не работала).
>Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что уявзвимости ядра которые требуют shell акаунта - это не критические. Неужели такая серьезная компания врала?Вообще-то одно из другого следует, включайте головной мозг уже.
>>Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что уявзвимости ядра которые требуют shell акаунта - это не критические. Неужели такая серьезная компания врала?
> Вообще-то одно из другого следует, включайте головной мозг уже.то есть врала? и любая дырка в ядре - уже критическая ?
>какой-то товарищ из RedHat говорил что уявзвимости ядра которые требуют shell акаунта - это не критические.Можно точную цитату со ссылкой на источник?
>>какой-то товарищ из RedHat говорил что уявзвимости ядра которые требуют shell акаунта - это не критические.
> Можно точную цитату со ссылкой на источник?Сами найдете. Было на OpenNet хвастливое высказвание от RH - который рассказывал что в ядре небыло критических ошибок.
>Сами найдете. Было на OpenNet хвастливое высказвание от RH - который рассказывал что в ядре небыло критических ошибок.А еще сам Столман говорил, что винда - единственная полностью свободная ОС, ага. Пруф сами найдете.
> А еще сам Столман говорил, что винда - единственная полностью свободная ОС,На опеннете, разумеется. Тут столлман и RH периодически устраивают баталии руками анонимусов :)
> Тут столлман и RH периодически устраивают баталии руками анонимусов :)На самом деле, Столман и RH - всего лишь послушные марионетки в руках могущественного Анонима. Что он пожелает - то они и скажут.
> Можно точную цитату со ссылкой на источник?Я другой Аноним. Ссылка эта
http://www.redhat.com/f/pdf/security/RHEL4_RiskReport_6yr_wp...Суть в том, что в понимании Red Hat критическая уязвимость - это remote root или возможность автоматической эксплуатации без ведома пользователя. Согласитесь, remote root и local root - это разного класса уязвимости. Именно по этому local root в классификации Red Hat значится как опасная, но не критическая.
> Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что
> уявзвимости ядра которые требуют shell акаунта - это не критические. Неужели
> такая серьезная компания врала?Нет, врал какой-то несерьезный аноним с опеннета, приписывая свои высказывания другим.
> Нет, врал какой-то несерьезный аноним с опеннета, приписывая свои высказывания другим.Причем этот деятель агитпропа упорно не хочет приводить ссылку - иначе кто-нибудь может по ней по ней пройти и прочитать, как все было на самом деле, и обнаружить, что это совсем не согласуется с враньем про "заявления RedHat".
> Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что
> уявзвимости ядра которые требуют shell акаунта - это не критические.Ссылочка будет или речь на самом деле шла про local DoS, как обычно?
А то есть тут одна "серьёзная" компания, которая регулярно подзуживает неокрепших умов, подсовывая сомнительные "доводы" -- ну, чтоб не так вот прямо врать, как про UEFI.
> подсовывая сомнительные "доводы" -- ну, чтоб не так вот прямо врать, как про UEFI.Кстати про UEFI на хабре выдвинули вполне доходчивые доводы против:
1) Если систему взгрели до уровня когда можно писать загрузчик - защищать там уже по сути нечего, хакер на этот момент мог спереть все что только можно. Поэтому...
2) Единственным сомнительным "бонусом" станет не загружающаяся совсем система. Насколько это лучше чем загружающаяся система, но с руткитом - вопрос вкусов и предпочтений. По-моему оба варианта - дрянь. А если учесть что винда не фонтан в качестве средства рекавери, а что-то еще запустить не выйдет... впрочем кого волнуют проблемы хомячков, правда? :)Итого: притянутая за уши система DRM-ограничений и загородок. "Для безопасности [облапошивания] пользователя".
>> Станно. буквально 2 недели назад - какой-то товарищ из RedHat говорил что
>> уявзвимости ядра которые требуют shell акаунта - это не критические.
> Ссылочка будет или речь на самом деле шла про local DoS, как
> обычно?в том треде были приведены ссылки как миниум на 4 дыры которые имели эксплойты по поднятию привелегий. Все 4 были помечены в RH - как серьезные, но не критические.
Я уж не знаю что может быть более критическое...
> Я уж не знаю что может быть более критическое...Капитан подсказывает: ремотный рут по сети. Ну как в шиндошс с ее мсбластами и лавсанами, современные видоизменения которых прошибают все сплошняком - от винтукея до "суперсекурных" 2008 с последним сервиспаком.
Видимо собрат Аноним имеет в виду это
http://www.opennet.me/opennews/art.shtml?num=31548\
http://www.redhat.com/f/pdf/security/RHEL4_RiskReport_6yr_wp...2.2. Critical Flaws
Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation.By definition, a critical vulnerability is one that could potentially be exploited remotely and automatically by a worm. However we also stretch the definition to include those flaws that affectweb browsers or plug-ins where a user only needs to visit a malicious (or compromised) websitein order to be exploited. Since the vast majority of critical severity issues occurred due to webbrowsers or plug-ins, this is why there is such a difference between the number of critical issues that affect a default install of Enterprise Linux 4 AS and WS.
For the purposes of the severity classification we ignore what privileges the attacker would be able to gain: a remote root compromise via something like Samba would be of a much higher risk than a user-complicit Firefox flaw that results in running code as an unprivileged user, but both would be rated as critical on this scale.
To help qualify the risk we’ve split up the critical vulnerabilities into those that require some minimal user interaction to be exploitable (such as if a user visits a malicious web page), and those that require no user interaction at all (and therefore could potentially be exploited by a worm).
>отдельную базу виртуальных пользователей, не имеющих системных аккаунтовВиртуальные аккаунты не панацея, неизвестно, какие дыры там обнаружатся.
>считает свой проект абсолютно безопасным и готов выплатить тысячу долларов
Главная уязвимость системы - излишняя самоуверенность разработчиков.
>перестанут работать ... обработчики, написанные на shell. Подобные обработчики потребуется переписать с учетом особенностей...
А вот и первая потенциальная уязвимость.
>> отдельную базу виртуальных пользователей, не имеющих системных аккаунтов
> Виртуальные аккаунты не панацея, неизвестно, какие дыры там обнаружатся.Панацея очевидна, отключить сервер от интернета навсегда. Только людям еще работать надо, поэтому не подходит.
>считает свой проект абсолютно безопасным и готов выплатить тысячу долларов
> Главная уязвимость системы - излишняя самоуверенность разработчиков.Бла-бла-бла. Главная уязвимость комментатора - попытка делать самоуверенные выводы не основанные ни на чем.
> А вот и первая потенциальная уязвимость
Видно людям же этот функционал нужен чтобы эффективно работать, иначе не стали бы это делать, не дураки. Не работать, или работать медленно и неудобно - не панацея.
> Виртуальные аккаунты не панацея, неизвестно, какие дыры там обнаружатся.правильно. лучше всего закрыть kernel.org навсегда и предложить всем разработчикам заняться действительно полезным делом: писать твикалки и чистилки реестра под Единственную Неуязвимую ОС.
>Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.Двумя руками подписываюсь под этим утверждением. Именно так все и бывает: взом пользовательского аккаунта, локальный эксплойт с целью обретения рутовых привелегий и инсталляция руткита в оконцовке.
А все потому что SSH - это одна большая дырка, как ни покрути. Пока брандмауэром не защитишь - все одно сломают.
ssh дырка? простите, в каком месте? юзать шелл на каждый чих - некошерно, согласен. ключики надо свои защищать - тоже согласен. но ssh-то тут при чём? какой именно алгоритм криптовки вы считаете дыркой?P.S. компьютер одна большая дырка. вот есть у меня гиря чугунная....
> ssh дырка? простите, в каком месте? юзать шелл на каждый чих -
> некошерно, согласен. ключики надо свои защищать - тоже согласен. но ssh-то
> тут при чём? какой именно алгоритм криптовки вы считаете дыркой?
> P.S. компьютер одна большая дырка. вот есть у меня гиря чугунная....Лучше паяльник.
Разработчики утверждают, что, если получить доступ к админу, сервер взламывается за несколько минут. :)
> Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.Это что, шутка такая??? Что это за система, в которой получение локальным пользователем прав root'а -- вопрос времени??? О какой безопасности вообще тогда может идти речь???
> Это что, шутка такая??? Что это за система, в которой получение локальным
> пользователем прав root'а -- вопрос времени??? О какой безопасности вообще тогда
> может идти речь???Любая. Раз в год стабильно везде находят подобные дыры, где-то реже, а где-то чаще. При наличии локального Shell разные дополнительные надстройки типа SELinux и AppArrmor мало помогают, они больше для защиты пролома отдельных приложений, а не Glibc и ядра. Радует только то, что многие дистрибутивы осознали порочную практику наводнения системы suid-ными программами и активно переходят на capabilities.
SELinux, apparmor -- это средства описания тех или иных привилегий, но ни коим образом не средство от их повышения. Так что вполне естественно, что они не помогают. И таки повышение привилегий, хоть локального пользователя, хоть удалённого, это абсолютно ненормально для системы, которую хотелось бы называть надёжной и безопасной.
> SELinux, apparmor -- это средства описания тех или иных привилегий,
> но ни коим образом не средство от их повышения."Да ладно, профессор!" (C) Анекдот.
SELinux (как и любая система MAC) предназначен ИМЕННО для этого: для защиты от local root compromise в частности и от несанкционированного privileges escalation вообще.
>> SELinux, apparmor -- это средства описания тех или иных привилегий,
>> но ни коим образом не средство от их повышения.
> "Да ладно, профессор!" (C) Анекдот.
> SELinux (как и любая система MAC) предназначен ИМЕННО для этого: для защиты
> от local root compromise в частности и от несанкционированного privileges escalation
> вообще.Каким образом?
> SELinux (как и любая система MAC) предназначен ИМЕННО для этого: для защиты
> от local root compromise в частности и от несанкционированного privileges escalation вообще.У шиндошса NT ACL сто лет в обед как есть. Что-то это не больно DigiNotar'у помогло: хаксор поимел SYSTEM через неизвестную дыру а в качестве бонуса спер креденшлы админа AD (с такими правами можно раскинуть бэкдоры на вообще все машины в AD, да хоть через те же групповые политики, например).
> У шиндошса NT ACLправильно что под анонимом, незнаешь о чем речь и мысли кудато в сторону блуждают
> У шиндошса NT ACL сто лет в обед как есть.Охрененно одно и тоже: обычный дискреционный ACL винды и линуха супротив мандатного SELinux. Спесьялисты....
> При наличии локального Shell разные дополнительные надстройки типа
> SELinux и AppArrmor мало помогаютПро апп-армор не скажу, а про СЕ советую его для начала поманить ...
> они больше для защиты пролома отдельных приложений, а не Glibc и ядра.
Да ты что ? ;) Не лучше сделай man selinux сделай. И кстати отгдай с 3х раз
shell это отдельное приложение ?> поддерживающее отдельную базу виртуальных пользователей, не имеющих системных аккаунтов.
Они тама что в анабиозе ? 21 век уже давно у всех LDAP/389DS стоят, или им как обычно
велосипеды подавай ?P.S. Вспомни историю :
"Мы включили SELinux в установку по умолчанию не без причины; не отключайте ее! В 2005 году червь Linux/Lupper использовал дыры в некоторых PHP-приложениях. Политики SELinux, установленные по умолчанию на Red Hat и Fedora, блокировали этого червя." Марка Кокса [Mark Cox] из команды безопасности Red Hat.
> 21 век уже давно у всех LDAP/389DS стоятЭто в 20-м было, LDAP всякие. В 21-м все-таки PAM.
> Это в 20-м было, LDAP всякие. В 21-м все-таки PAM.Да вы офигенно крутой спец. PAM и LDAP у вас типа конкурирующие технологии, да :D
>> При наличии локального Shell разные дополнительные надстройки типа
>> SELinux и AppArrmor мало помогают
> Про апп-армор не скажу, а про СЕ советую его для начала поманить
> ...Во первых, на kernel.org была Fedora с SELinux. Во вторых, покажите мне хоть один дистрибутив с залоченным SELinux shell-ом. В том то и проблема, что какой-нибудь Firefox зажмут, а войдя по ssh можно что угодно делать.
> покажите мне хоть один дистрибутив с залоченным SELinux shell-ом.А вы мне покажите хоть одну дыру в шелле, позволяющую получить рутовые права. Именно в шелле, а не в программе, которую можно из него запустить.
> В том то и проблема, что какой-нибудь Firefox зажмут, а войдя по ssh можно что угодно делать.
Браузеры, как наиболее уязвимые и небрежно написанные программы, необходимо защищать в первую очередь.
А шелл на для того предназначен, чтобы делать все что угодно. И если админ разбрасывается своими реквизитами - это уже какбэ не проблема шелла, не находите?
>>> При наличии локального Shell разные дополнительные надстройки типа
>>> SELinux и AppArrmor мало помогают
>> Про апп-армор не скажу, а про СЕ советую его для начала поманить
>> ...
> Во первых, на kernel.org была Fedora с SELinux. Во вторых, покажите
> мне хоть один дистрибутив с залоченным SELinux shell-ом. В том то
> и проблема, что какой-нибудь Firefox зажмут, а войдя по ssh можно
> что угодно делать.Огораживать ФФ есть очень большой смысл. 1) ФФ (и вообще -- браузер) -- довольно сложная программа, безошибочность которой сложно гарантировать 2) причём, если, например, ошибки/уязвимости в ядре касаются всей системы, и поэтому тщательно выискиваются и устраняются (да и то, как мы видим, лишь с относительным успехом), то ошибки/уязвимости браузера касаются только конкретного бесправного юзера и устраняются не столь ревностно; частично устранение ошибок заменяется носкриптами и заклинаниями типа: "нефик по порносайтам лазить" 3) ФФ по определению должен работать с кодом, который пользователь не контролирует; этот код не должен получить доступ к данным пользователя, даже если он вырвется из контекста браузера 4) в то же время ФФ незачем иметь доступ к данным пользователя (кроме сохранения файлов и доступа к своим настройкам) и тогда, когда ФФ нормально функционирует и исполняет легитимный код 5) поэтому, с одной стороны, ФФ легко огородить, не нанося ущерба его нормальному функционированию, с другой стороны, такое огораживание полезно на случай наличия уязвимости в ФФ, а с третьей стороны, оно легко и эффективно реализуется тем же селинуксом (если система в целом не взломана).
Огораживание шелла бессмысленно по определению. Точнее, шелл исполняется в контексте пользователя и уже этим огорожен по отношению к системе в целом. Внутри же контекста пользователя шелл по определению должен быть полноправным.
Но даже если огородить шелл селинуксом, проблему это не решило бы. Проблема в том, что иногда программы, запущенные в контексте пользователя (унаследовав этот контекст от шелла), меняют контекст на рутовый. Это уязвимость в чистом виде, в ядре, или в какой-то из сетуидных программ, или ещё где-то, пока что господа с кернел.орг ничего нам об этом не рассказали. Как этому может помешать селинукс? Селинукс, следуя своим политикам, запретит шеллу/программе-эксплойту перейти в контекст рута? Так это и без селинукса должно быть запрещено. Классическая юниксовая система контроля доступа принимает решение раньше, чем происходит обращение к селинуксу. Если решение отрицательное, то обращения к селинуксу просто не будет. Так что у селинукса просто не будет случая встать на защиту системы.
> Огораживать ФФ есть очень большой смысл.Что еще один из криокамеры ? Давно уже все пускают фф так :
sandbox -X firefox
>> Огораживать ФФ есть очень большой смысл.
> Что еще один из криокамеры ? Давно уже все пускают фф так
> :
> sandbox -X firefoxОй, да, простите, это всё меняет.
>> Огораживать ФФ есть очень большой смысл.
> Что еще один из криокамеры ? Давно уже все пускают фф так
> :
> sandbox -X firefoxА скачаное после длолгих мучительных поисках по сотням форумов как сохранить? Фотографировать экран?
> разные дополнительные надстройки типа SELinux и AppArrmor мало помогают, они больше для защиты пролома отдельных приложений, а не Glibc и ядра.Очень остроумно. А как вы проломите glibc и ядро, не воспользовавшись ни одним приложением?
> Очень остроумно. А как вы проломите glibc и ядро, не воспользовавшись ни
> одним приложением?Написав и собрав свое приложение дергающие нужный системный вызов ? Как по вашему эксплоиты запускают ?
> Написав и собрав свое приложение дергающие нужный системный вызов ? Как по
> вашему эксплоиты запускают ?Бгг. Эксплойт - не программа, да?
>> Написав и собрав свое приложение дергающие нужный системный вызов ? Как по
>> вашему эксплоиты запускают ?
> Бгг. Эксплойт - не программа, да?А по умолчанию всё разрешающий для неизвестный процессов полиси - не полиси ?
> А по умолчанию всё разрешающий для неизвестный процессов полиси - не полиси... а детская игрушка, да.
> Бгг. Эксплойт - не программа, да?Может быть и не программой, если прилетает в другую программу и вклинивается в ее код. При этом он будет выполняться в контексте этой программы.
> Очень остроумно. А как вы проломите glibc и ядро, не воспользовавшись ни
> одним приложением?Очень остроумно. А зачем нужна система без программ? :)
>> разные дополнительные надстройки типа SELinux и AppArrmor мало помогают, они больше для защиты пролома отдельных приложений, а не Glibc и ядра.
> Очень остроумно. А как вы проломите glibc и ядро, не воспользовавшись ни
> одним приложением?Если есть shell, то есть возможность собрать самому все что угодно и дернуть любой sysctl, ioctl и прочее.
> Радует только то, что многие дистрибутивы осознали порочную практику наводнения
> системы suid-ными программами и активно переходят на capabilities.Огорчает то, что без должного понимания это... чревато дырками, как вот с sendmail было: программа проверяет, что работает "не от рута", и не делает проверки, которым с включенными капабилитями всё равно место.
http://lwn.net/Articles/420624/ (можно просканировать по sendmail и solardiz)
>Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.еще один повод подумать над более распределенной системой доступа, раз комбинация users & groups не исключают повышения уровня доступа.
> еще один повод подумать над более распределенной системой доступа, раз комбинация users & groups не исключают повышения уровня доступа.Ещё один повод поискать ошибку в ядре, вместо того, чтобы переделывать всю инфраструктуру kernel.org из-за нежелания искать эту ошибку. Или, раз уж это лишь вопрос времени, давайте вообще запретим uid отличные от нулевого.
> еще один повод подумать над более распределенной системой доступаВылазайте уже из криокамеры ... man SElinux !
это вы kernel.org учите жить :)
> это вы kernel.org учите жить :)Они слишком круты, чтобы разбираться в тонкостях работы написанного ими ядра.
> Вылазайте уже из криокамеры ... man SElinux !Угу, каждый первый боевой сплойт считает своим долгом его вырубить первым делом, чтобы под ногами не путался.
>> Вылазайте уже из криокамеры ... man SElinux !
> Угу, каждый первый боевой сплойт считает своим долгом его вырубить первым делом,
> чтобы под ногами не путался.Знаем мы этот "сплойт". Он по форумам постоянно кочует, "Первым делом я после установки федоры сношу пульсаудио отключаю селинукс к0чаю мп3 кодек, настоящий нвидия блоб, нескучные обои, ой вот мне уже пишут в почте мужик из африки что то там про казну... ну все накогда мне тут с вами, пойду 100 бкасов отправлю - черный пацан пишет больше вернет"
По идее даже рута необязательно получать если взломан аккаунт или рабочий комп разработчика. Можно от его имени коммитить в линух ядро замаскированные дырки :)
Тоже самое думаю можно провернуть и с Gitolite ...
> По идее даже рута необязательно получать если взломан аккаунт или рабочий комп
> разработчика. Можно от его имени коммитить в линух ядро замаскированные дырки
> :)
> Тоже самое думаю можно провернуть и с Gitolite ...Попробуйте хоть раз поучаствовать в разработке и тестировании большого проекта, тогда поймете, что в тех местах, где дырки ищут - их не встроить.
> разработчика. Можно от его имени коммитить в линух ядро замаскированные дырки :)Пробовали однажды, не прокатило - коммиты натурально читают и коммитеру надают по щщам ;)
На самом деле автор готов выплатить не тысячу долларов а сто:"Я не могу позволить выплатить награду в 1000 долларов, как djb, так что Вам придётся согласиться на 5000 рупии в качестве приза"
(ориг: "well I can't afford 1000 USD rewards like djb, so you'll have to settle for 5000 INR (Indian Rupees) as a "token" prize")
> Нынешние SSH-ключи отменены, а новые будут сгенерированы и отправлены разработчикам в ближайшее время.Ад какой-то.
А ничего, что все должно быть наоборот — ключи должны генерить сами разработчики и передавать их публичные части (либо по защищенному каналу, либо подписанными доверенными GPG-ключами) на кернельорк?
>> Нынешние SSH-ключи отменены, а новые будут сгенерированы и отправлены разработчикам в ближайшее время.
> Ад какой-то.
> А ничего, что все должно быть наоборот — ключи должны генерить сами
> разработчики и передавать их публичные части (либо по защищенному каналу, либо
> подписанными доверенными GPG-ключами) на кернельорк?По разному делают, на самом деле даже разработчики ssh говорят что одинаково это. Можно генерировать ключ локально и подписать его в центре, можно генерировать централизовано и раздать по защищенному каналу. Разницы нет, в любом случае риск перехвата одинаков.
Урок выучен! Это хорошо!
Странно, почему они gitolite раньше не использовали.
Гентушные оверлеи (git.overlays.gentoo.org) давно на нём.
Неосилятоам SELinux сюда: http://www.xakep.ru/post/56714/default.asp . Если и после подобных вводных статей непонятно зачем нужа технология SELinux, то, я думаю, вам лучше не стоит вообще подходить сколько-нибудь близко в серверам.
> Неосилятоам SELinux сюда: http://www.xakep.ru/post/56714/default.asp . Если и после
> подобных вводных статей непонятно зачем нужа технология SELinux, то, я думаю,
> вам лучше не стоит вообще подходить сколько-нибудь близко в серверам.Капитан намекает что хваленый selinux при эксплойтировании ядра - выпинывается первым делом.
>Капитан намекает что хваленый selinux при эксплойтировании ядра - выпинывается первым делом.0. Смысл выносить selinux если удалось получить root?
1. До эксплойтирования ядра еще нужно проскочить атакой через selinux (вариант атаки из-под локального аккаунта пока не рассматриваю так как .. см. третий пункт)
2. Есть же git-shell, зачем девелоперам давать полный shell ?вывод: капитан = лжекапитан
> 0. Смысл выносить selinux если удалось получить root?А чтоб не мешался своими останками.
> 1. До эксплойтирования ядра еще нужно проскочить атакой через selinux (вариант атаки
> из-под локального аккаунта пока не рассматриваю так как .. см. третий пункт)Да вон тут в новостях было несколько сплойтов, которые на этот селинукс с удовольствием клали. Не забывая потом мстительно его выпнуть, чтоб не мешался. Vmsplice например, и кто там еще - несколько было.
> 2. Есть же git-shell, зачем девелоперам давать полный shell ?Не знаю. ИМХО давать ssh аккаунт без реальной нужды - это в любом случае поиск проблем на свой зад. Через SSH сам по себе можно сильно дофига всего и раздавать аккаунты оного кому попало - хорошая заявка на поиск неприятностей.
> вывод: капитан = лжекапитан
Вывод на самом деле чуть иной: тут водится наивный аноним который не умеет искать по новостям опеннета.
>А чтоб не мешался своими останками.Мне непонятно. Как он может мешаться если получен root? Уточните.
>Да вон тут в новостях было несколько сплойтов, которые на этот селинукс с удовольствием
>клали. Не забывая потом мстительно его выпнуть, чтоб не мешался. Vmsplice например, и кто
>там еще - несколько было.Ошибки есть - их просто не может до тех пор пока софт будут и дальше писать в рамках существующих методов. Значит ли это что наличие selinux и тру администратора в системе равносильно его (selinux) остутствию?
>Не знаю. ИМХО давать ssh аккаунт без реальной нужды - это в любом случае поиск проблем на
>свой зад. Через SSH сам по себе можно сильно дофига всего и раздавать аккаунты оного кому
>попало - хорошая заявка на поиск неприятностей.Никто не спорит что ssh давать без реальной нужды не стоит. Но git-shell все равно есть (для тех, кто не в курсе: git-shell задается в качестве login-shell, и юзверь не может попасть в систему, но может работать с репо через ssh).
>Вывод на самом деле чуть иной: тут водится наивный аноним который не умеет искать по
>новостям опеннета.Ничего подобного. "Цыплят по осени считают".
> Мне непонятно. Как он может мешаться если получен root? Уточните.Честно говоря не въезжал в детали чем именно он так не угодил авторам сплойтов, но почему-то во всех более-менее похожих на "боевые" эксплойтах - нейтрализация selinux делается на раз, одной из первых операций. Стало быть мешался, раз выпиливают.
> Ошибки есть - их просто не может до тех пор пока софт будут и дальше писать
> в рамках существующих методов.А других методов и не будет. Даже если уповать на автоматическую верификацию, доказана теорема что одна программа не может верифицировать другую произвольную программу и вынести определенный вердикт для произвольно взятой программы.
> Значит ли это что наличие selinux и тру администратора в системе равносильно
> его (selinux) остутствию?Я полагаю что контейнерами/виртуалками изолировать части систем друг от друга контейнерами/виртуалками не в пример проще для понимания, аудита процессов в этом всем и по степени изоляции - не хуже (openvz/lxc) или даже лучше (kvm/xen). В свете этого selinux нужен в основном старперам из АНБ, ФБИ и прочих, у которых - регламент, в котором если написано что трава должна быть зеленой, а на дворе декабрь - ну значит вот вам ведерко зеленой краски и кисточка. Поскольку регламенты я видал в гробу, а вот фактическая эффективность меня очень даже интересует - я позволяю себе нескромность решать задачи так как мне удобно. А с этим вашим селинуксом сами сношайтесь. Гемора много а толку мало, судя по сплойтам. Тогда как пролом до рута в машине на xen/kvm атакующему ничего особо не дает.
> Никто не спорит что ssh давать без реальной нужды не стоит. Но
> git-shell все равно есть (для тех, кто не в курсе: git-shell
> задается в качестве login-shell, и юзверь не может попасть в систему,
> но может работать с репо через ssh).SSH позволяет довольно много всего - опенбсдшники превратили его в какой-то непотребный комбайн, умеющий кидать впн, форвардить порты и что там еще. Проаудитить все возможные грабли при использовании такй монстрятины - редкий админ сможет, ихмо.
> Ничего подобного. "Цыплят по осени считают".
Так как раз осень. Самое время :)
>Честно говоря не въезжал в детали чем именно он так не угодил авторам сплойтов, но
>почему-то во всех более-менее похожих на "боевые" эксплойтах - нейтрализация selinux
>делается на раз, одной из первых операций. Стало быть мешался, раз выпиливают.Понятное дело что после получения рута selinux дизейблить - не проблема. И все же, целесообразность не ясна, так как при наличии прав суперпользователя selinux - не помеха.
>А других методов и не будет.
Будет. Сегодня нет - завтра есть. ИИ на подходе (гипотетически допустимо и то что новые методы также на подходе).
>Я полагаю что контейнерами/виртуалками изолировать части систем друг от друга
>контейнерами/виртуалками не в пример проще для понимания, аудита процессов в этом всем и
>по степени изоляции - не хуже (openvz/lxc) или даже лучше (kvm/xen). В свете этого
>selinux нужен в основном старперам из АНБ, ФБИ и прочих, у которых - регламент, в
>котором если написано что трава должна быть зеленой, а на дворе декабрь - ну значит вот
>вам ведерко зеленой краски и кисточка. Поскольку регламенты я видал в гробу, а вот
>фактическая эффективность меня очень даже интересует - я позволяю себе нескромность
>решать задачи так как мне удобно. А с этим вашим селинуксом сами сношайтесь. Гемора
>много а толку мало, судя по сплойтам. Тогда как пролом до рута в машине на xen/kvm
>атакующему ничего особо не дает.SELinux, AppArmor отражают очевидное и нужное решение в сфере безопасности приложении. Вопрос, кстати был такой и по теме: "Значит ли это что наличие selinux и тру администратора в системе равносильно его (selinux) остутствию?"
Расскажите, причем же тут (в узком контексте вопроса) вообще контейнеры/виртуалки. И раз уж пошла такая пьянка, прошу учесть что контейнеры/виртуалки и SELinux/AppArmor как бы разного уровня решения. SELinux/AppArmor может работать внутри контейнера/виртуалки но не наоборот, поэтому их сравнивать несколько неуместно.> Никто не спорит что ssh давать без реальной нужды не стоит. Но
> git-shell все равно есть (для тех, кто не в курсе: git-shell
> задается в качестве login-shell, и юзверь не может попасть в систему,
> но может работать с репо через ssh).
>SSH позволяет довольно много всего - опенбсдшники превратили его в какой-то непотребный >комбайн, умеющий кидать впн, форвардить порты и что там еще. Проаудитить все возможные
>грабли при использовании такй монстрятины - редкий админ сможет, ихмо.Комбайн хорош и весьма удобен. Нормальный админ сможет, даже если не умеет/не работал/никогда прежде. Мне ли Вам это объяснять?
>Так как раз осень. Самое время :)
Времена совпали, но контексты нет. Поэтому незачет.
> Понятное дело что после получения рута selinux дизейблить - не проблема. И
> все же, целесообразность не ясна, так как при наличии прав суперпользователя selinux - не помеха.Поэтому не могли бы вы пояснить - чего все так про него орут в контексте новости о повышении прав из-за дырки в ядре? Есть какая-то уверенность что с selinux дырку с повышением прав поюзать не удастся? А откуда она проистекает?
> Будет. Сегодня нет - завтра есть. ИИ на подходе (гипотетически допустимо и
> то что новые методы также на подходе).Хм... человек, который любому ИИ фору даст - и то вон ошибается. Как-то пока не видно прорыва, тем более что математику так просто не обманешь. Как максимум - придумали пилить одну большую задачу на независимые модули, уйдя хотя-бы от квадратичной сложности отладки (местами). Ну ядро и попилено на кучу относительно независимых частей.И то не все так просто - возникают проблемы на границе стыковки оных, etc. Полная валидация всего этого перебором всех параметров невозможна по причине дикого количества комбинаций.
>>решать задачи так как мне удобно. А с этим вашим селинуксом сами сношайтесь. Гемора
>>много а толку мало, судя по сплойтам. Тогда как пролом до рута в машине на xen/kvm
>>атакующему ничего особо не дает.
> SELinux, AppArmor отражают очевидное и нужное решение в сфере безопасности приложении.Оно отражает всего лишь еще одну реализацию мандатного контроля доступа. В той же NT ACLы реализующие оный есть с середины 90х если не раньше, но почему-то никто в здравом уме не допирает козырять этим фактом (наглость хакерских взломов видимо не способствует).
> Вопрос, кстати был такой и по теме: "Значит ли это что наличие selinux
> и тру администратора в системе равносильно его (selinux) остутствию?"Если честно - я не вижу как SELinux может эффективно защитить в рассматриваемой ситуации (повышение прав из-за ошибки в ядре). По-моему в указанной ситуации - индифферентно. Т.к. сама возможность делать сисколы, вызвав какими-то параметрами проблемы у атакующего от наличия SELinux никуда не девается. Единственное что от SELinux не станет хуже, если вы действительно хорошо в нем и его простынках политик разбираетесь и действительно понимаете какой набор прав фактически будет действовать (imho при этом можно вывихнуть мозг, но вы можете быть и иного мнения). Может даже станет немного лучше (если действительно грамотно использовать). А может и хуже (если появится ложное чувство защищенности). Уж как повезет. Я - сторонник простых сущностей. Чтобы все было просто и прозрачно. А это imho не про политики SELinux, являющие собой довольно жутковатые простынки.
> Расскажите, причем же тут (в узком контексте вопроса) вообще контейнеры/виртуалки.Да примерно при том что и SELinux - изоляция частей системы друг от друга. При том в случае полновесных виртуалок - изоляция прочнее чем стандартными методами. В случае контейнеров - в разы проще в восприятии чем простынки политик SELinux и зарубает некоторые классы атак + на корню снижается возможность хакера шариться по системе и спереть что-то лишнее (особенно если где-то в конфигурации ошибка).
> И раз уж пошла такая пьянка, прошу учесть что контейнеры/виртуалки и SELinux/AppArmor как
> бы разного уровня решения. SELinux/AppArmor может работать внутри контейнера/виртуалки
> но не наоборот, поэтому их сравнивать несколько неуместно.Ну так легкие контейнеры - это тоже фича ядра, тоже по части изоляции. Просто чуть более кардинально - лепится отдельный неймспейс, и там живут себе сущности. Они вообще не видят ничего кроме своего загона, а потому не могут стандартными методами сильно напакостить. Да и рут в контейнере - фэйковый, его получение не дает возможность взгреть систему на хосте, только саму песочницу (что несколько отличается от SELinux в лучшую сторону, пожалуй). Потенциальная проблема которая остается в этом случае - это если атака на сискол позволяет выполнить код в ядре. Так хакер может прорваться и из контейнера в хост-систему. Если и от такого надо защититься - логично смотреть на полные виртуализаторы. Тем более что KVM в ядро встроен (что впрочем как достоинство так и недостаток одновременно, xen для параноиков получше будет). Кстати а чему противоречит запуск контейнера/виртуалки которые на хосте еще до кучи огорожены и SELinux'ом так или иначе? Тот же LXC - по сути вызов обычного clone() с хитрыми параметрами, указывающими ему что мы хотим отдельные неймспейсы и свой загончик. А почему SELinux перестанет действовать на это? И перестанет ли, собственно?
> Комбайн хорош и весьма удобен.
Удобство выходит боком когда встает вопрос о безопасности. Иногда ну вот натурально надо секурный туннель и ничего больше. А оно тут такой швейцарский нож с 120 лезвиями. Да блин! В секурити хорошо когда все просто и понятно, а такой пепелац обкусить до состояния только секурного туннеля - надо _сильно_ попотеть. Хотя по идее должно бы быть наоборот.
> Нормальный админ сможет, даже если не умеет/не работал/никогда прежде.
> Мне ли Вам это объяснять?Да, а еще как видим хакеры тоже смогут. Всякого лишнего понаделать. Хотя фактически был нужен то всего лишь секурный туннель до гита с авторизацией.
> Времена совпали, но контексты нет. Поэтому незачет.
:P
>Поэтому не могли бы вы пояснить - чего все так про него орут в контексте новости о
>повышении прав из-за дырки в ядре? Есть какая-то уверенность что с selinux дырку с
>повышением прав поюзать не удастся? А откуда она проистекает?Пояснять не вижу смысла, так как я уже говорил что в ситуации когда получен root, selinux не поможет. Но почему-то Вы мне упорно пытаетесь навязать беседу в этом контексте. Корректно настроенная политика SELinux на системе должна обеспечивать выполнение программы в ее рамках, не давая приложению выполнить больше дозволенного. На этом все. Надеюсь Вы обдумаете сказанное и не будете навязывать искусственный разговор с противопоставлением SELinux и дырок с недостаточной фильтрацией входных параметров в сисколлах, которые позволяют овладеть uid=0.
>Хм... человек, который любому ИИ фору даст - и то вон ошибается. Как-то пока не видно
>прорыва, тем более что математику так просто не обманешь. Как максимум - придумали
>пилить одну большую задачу на независимые модули, уйдя хотя-бы от квадратичной сложности
>отладки (местами). Ну ядро и попилено на кучу относительно независимых частей.И то не
>все так просто - возникают проблемы на границе стыковки оных, etc. Полная валидация
>всего этого перебором всех параметров невозможна по причине дикого количества комбинаций.Сегодня человек ИИ фору даст, а завтра - нет. Математику обманывать и не пондобится, так как случиться примерно то же самое что и ситуация с СТО и превышением скорости света. А полная валидация (брутфорс) параметров в принципе не нужна - а нужны нормальные методы разработки (существующие методы, как например объектная концепция, схожи с недоделанными свистелками).
>Если честно - я не вижу как SELinux может эффективно защитить в рассматриваемой ситуации
>(повышение прав из-за ошибки в ядре).Вы опять про ситуацию с ошибками в ядре. SELinux не для этого создавался. Зачем только Вы смешиваете все время SELinux и ошибки в ядре? Вы пишете как будто я говорил про то что SELinux защищает от ошибок в ядре. Я такое не писал а писал лишь только то что SELinux и его политика снижает потенциальные риски (и только в рамках своего контекста безопасности - тогда как вы мне приводите все время случай с эскалацией привелегии).
>[оверквотинг удален]
>систему на хосте, только саму песочницу (что несколько отличается от SELinux в лучшую
>сторону, пожалуй). Потенциальная проблема которая остается в этом случае - это если
>атака на сискол позволяет выполнить код в ядре. Так хакер может прорваться и из
>контейнера в хост-систему. Если и от такого надо защититься - логично смотреть на полные
>виртуализаторы. Тем более что KVM в ядро встроен (что впрочем как достоинство так и
>недостаток одновременно, xen для параноиков получше будет). Кстати а чему противоречит
>запуск контейнера/виртуалки которые на хосте еще до кучи огорожены и SELinux'ом так или
>иначе? Тот же LXC - по сути вызов обычного clone() с хитрыми параметрами, указывающими
>ему что мы хотим отдельные неймспейсы и свой загончик. А почему SELinux перестанет
>действовать на это? И перестанет ли, собственно?Еще раз пишу что контейнеры/виртуалки и SELinux/AppArmor как бы разного уровня решения. SELinux/AppArmor может работать внутри контейнера/виртуалки но не наоборот, поэтому их сравнивать несколько неуместно. Обдумайте еще раз написанное.
>Удобство выходит боком когда встает вопрос о безопасности. Иногда ну вот натурально надо
>секурный туннель и ничего больше. А оно тут такой швейцарский нож с 120 лезвиями. Да
>блин! В секурити хорошо когда все просто и понятно, а такой пепелац обкусить до
>состояния только секурного туннеля - надо _сильно_ попотеть. Хотя по идее должно бы быть
>наоборот.Для это и существуют стандартные политики.
Дайте же слово совершенному непрофессионалу. Поправьте меня если что.
Имея root-а на системе с настроенным (правильно для данного набора программ и функций системы) SELinux, нельзя вырубить SELinux без дыры в ядре?
Спасибо.
Да, теоретически нельзя. Потому что SELinux может ограничить полномочия рута. Только для этого нужна ну очень кастомная политика, которую всем лень писать.
> Пояснять не вижу смысла, так как я уже говорил что в ситуации
> когда получен root, selinux не поможет. Но почему-то Вы мне упорно
> пытаетесь навязать беседу в этом контексте.Наверное потому что тут рассматривалась дырень через которую и были повышены права с просто юзера до рута, что и является основной проблемой. Т.е. взлом мог выглядеть просто и обидно: кто-то пролюбил ssh-логин потребный для git'а а потом кто-то использовал оный, задрал себе права до рута через некую дыру, и порезвился, воткнув руткит.
> Корректно настроенная политика SELinux на системе должна обеспечивать
> выполнение программы в ее рамках, не давая приложению выполнить больше
> дозволенного.В теории все так. На практике - это не система фильтрации сисколов, поэтому эффективность selinux в защите от атак повышения привилегий довольно ограниченная (if any).
> недостаточной фильтрацией входных параметров в сисколлах, которые позволяют овладеть uid=0.
Ну так SELinux был посоветован в контексте этой новости, которая как раз об повышении прав до рута. На что я и возмутился что это по большей части будет мертвому припарка. Что-то не так?
> Сегодня человек ИИ фору даст, а завтра - нет. Математику обманывать и
> не пондобится, так как случиться примерно то же самое что и
> ситуация с СТО и превышением скорости света.Имейте совесть, там отличие от скорости света микроскопическое - это запросто может быть ненайденной систематической ошибкой измерения или просто недостаточной точностью замеров скорости света до этого момента. По логике вещей надо бы замерять скорость света на том же оборудовании при пускании фотонов тем же путем, но это не получится поскольку те господа пускали нейтрино прямо через землю. С фотонами так не прокатит. Поэтому к результату надо относиться осторожно и в любом случае бОльшая часть СТО видимо уцелеет: многие релятивистские эффекты подтверждены экспериментально и объяснять их в любом случае придется.
> А полная валидация (брутфорс) параметров в принципе не нужна
Тогда не будут проверены те или иные граничные состояния программы а значит не будут найдены и некие возможные баги.
> - а нужны нормальные методы разработки
Как известно не ошибается лишь тот кто ничего не делает. Наверное это единственный метод избежать ошибок на 100%, но это неспортивно :)
> (существующие методы, как например объектная концепция, схожи с недоделанными свистелками).
Ядро на сях писано - на сях объектная концепция вообще практически отсутствует.
>>Если честно - я не вижу как SELinux может эффективно защитить в рассматриваемой ситуации
>>(повышение прав из-за ошибки в ядре).
> Вы опять про ситуацию с ошибками в ядре. SELinux не для этого
> создавался.Так блин, новость об этом - некто повысил себе права до рута. А тут вылезли товарисчи с рекламой SELinux. Вроде бы логично что я не понял этот их маневр.
> Зачем только Вы смешиваете все время SELinux и ошибки в ядре?
Потому что об этом по сути и есть эта новость. Видимо имело место повышение прав через ошибку в ядре + тут сосватали SELinux с апломбом заявив что те кто его не пользует - ламеры. На что я и выразил недоумение - откуда из одного следует другое.
> Вы пишете как будто я говорил про то что SELinux защищает от ошибок в ядре.
Как минимум предыдущие ораторы сватавшие оный - говорили.
> (и только в рамках своего контекста безопасности - тогда как вы
> мне приводите все время случай с эскалацией привелегии).Ну а что я должен приводить в треде о новости в которой некто рут на атакуемом сервере получил?
[...]
> Еще раз пишу что контейнеры/виртуалки и SELinux/AppArmor как бы разного уровня решения.
> SELinux/AppArmor может работать внутри контейнера/виртуалки но не наоборот, поэтому их
> сравнивать несколько неуместно. Обдумайте еще раз написанное.Затвердила сорока якова одно про всякого. А вот объясните мне - что принципиально мешает SELinux на "хосте" завернуть некую операцию допустим со стороны LXC контейнера-"гуесте"? Как минимум фундаментальных причин по которым это никак не может работать я так сходу не вижу. Будет ли работать в фактической реализации - ??? (а вы это проверяли, чтобы утверждать что не работает и не будет работать?).
> Для это и существуют стандартные политики.
О, нормально - сперва мы создадим себе проблем наворотив фич, а потом героически заборем их заткнув щели политиками. И конечно же надежность всего этого будет понятно какая: две переусложненные подсистемы вместо одной тривиальной еще никого до добра не доводили. См. выкладки Берштейна, он в безопасном программировании явно знает толк.