LINUX.ORG.RU

SeLinux в сравнении с безопасностью OpenBSD


0

0

Недавно в списке рассылки OpenBSD-misc состоялась дискуссия на предмет сравнения безопасности ядра Линукса 2.6.x в виде подсистемы SeLinux с тем, что предлагается в OpenBSD. Общее мнение таково: политика безопасности SeLinux и язык, на котором она пишется, слишком сложна, что приводит к тому, что, цитата Damien Miller: "при развёртывании всех известных мне средних и крупных инсталляций Линукса, SeLinux был отключен. Как только вы делаете шаг в сторону от конфигурации по умолчанию, то предлагаемые политики, с которыми поставляется ваш дистрибутив, больше не работают, и затем всё просто ломается". Другой участник дискуссии просуммировал высказанное следующим образом: "проблема безопасности, которая опирается на какую-либо [предопределенную] политику, в том, что последняя всегда неверна".

Далее была высказана следующая [как мне кажется очень правильная] мысль: "Нельзя прививать безопасность - её нужно интегрировать в основной процесс разработки. Я уверен, что мэйнтейнеры накладывают все возможные патчи, но это не исправляет фундаментальный изъян этого процесса. Это не ошибка в их работе - это неотъемлемая часть ситуации. Но это всё равно изъян."

"Проблема с SeLinux в том, что это просто кнопка, которую можно нажать, оставив систему без сверхнадёжной защиты". OpenBSD имеет более универсальну систему защиты в виде propolice stack protection, random library mappings, proactive privilege separation, W ^X и systrace.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Резюме: БСДуны ниасилили.

А если серьезно все действительно так - стоит отойти на шаг от какой-от идеальной модели вебсервера так начинаются поблемы...

anonymous
()

Юзаю федору с 4й версии. Сколько их не устанавливал, однажды в один прекрасный день выяснялось, что селинукс не даёт какой-нибудь безобидной штуке (например OO.o от инфраресурса) работать. Соответственно оный отключался, хотя это и неправильно.

Вообще не понятно что он делает, как и когда. Читать на англицком не охота - есть дела поважнее.

Кто-нибуь на лоре осиливал настройку селинукса? Можно ли с его помощью решить чисто практическую задачу: запретить программе (например opera) открывать на чтение (и тем более запись) всех файлов ~/.* (кроме ~/.opera и ~/OperaDownloads само собой) и если можно, то насколько это будет трудоёмко.

legolegs ★★★★★
()
Ответ на: комментарий от anonymous

> в linux их надо внедрять при помощи патчей либо активировать опции в kernel config.

В линуксе вообще ничего нет, всё нужно активировать через опции kernel config. Пионерская паделка.

mv ★★★★★
()
Ответ на: комментарий от birdie

> Да, увы, я тоже часто (в половине случаев точно) отрубаю SeLinux, ибо до сих пор не хватает сил разобраться с этим монстром.

birdie, что делаешь во второй половине случаев, когда не отрубаешь?

Rubystar ★★
()
Ответ на: комментарий от Black_Shadow

> А например в ядре федоры SELinux тоже включен по дефолту

Самое удивительное, что у нас далёкие от IT люди пользуются этой Федорой со включенным selinux и в ус не дуют.

mv ★★★★★
()
Ответ на: комментарий от anonymous

> учатся на ошибках, но ты явно отказываешся видеть ошибки прикрываясь системой (опять же с потенциальными ошибками), следовательно ты не учешся, а это глупо.

Детское какое-то рассуждение... При большом количестве разработчиков закон распределения ошибок становится близким к нормальному, как и во всяких других _больших совокупностях _независимых_ явлений. Посему бороться с ошибками не всегда осмыленно: это снизит их вероятность, но не сделает её тождественно нулевой. Посему нужно проектировать системы, в которых _допускается_ наличие определенного количества ошибок (не надо как в известном анекдоте про IBM и заказ процессоров в Японии делать их _специально_), возможно, сделав какие-то предположения об их "тяжести" и относительной вероятности появления.

Вы знакомы, как CD-ROM прочитывается в приводе? А ведь при таком чтении _постоянно_ возникают ошибки, что, однако, не мешает считать с этого CD верную информацию. Это пример процесса, устойчивого к ошибкам.

Ядро Linux (да и любые другие современные ОС) также допускаю наличие у прикладных программ определенных ошибок, кокторые не нарушают её (ОС) нормального функционирования. Это давно опробованный и оправдавший себя подход. SELinux естественно развивает и продолжает его, устраняя недостатки традиционной системы безопасности UNIX.

А ребята из OBSD занялись чем-то вроде коммунистичекой пропаганды: Делайте! Лучше! Качественнее! Бред, в общем какой-то, кроме, может, вполне здравого замечания, что язык описния политик слишком сложный.

annoynimous ★★★★★
()
Ответ на: комментарий от anonymous

> Linux devs do NOT understand Security as a process.

Именно по этой причине появляется автоматический kernel code coverage и sparse?

mv ★★★★★
()
Ответ на: комментарий от anonymous

> встроено это когда приварили, и что-бы отклучить то надо вырезать.

Т.е. когда выйдет более совершенный вид "этого", то старый код проще будет переписать с нуля, чем вырезать менее совершенное "это"?

mv ★★★★★
()
Ответ на: комментарий от mv

вырезанием займется "хирург", знающий тело "пациента" и знающий что делать.

anonymous
()
Ответ на: комментарий от annoynimous

прогресс собственно в том и состоит что-бы делать лучше и качественней, иначе это просто переливание из пусто в порожни.

а пример с CD-ROM суда не подходит. речь идет о ошибках человека, а не алгоритма.

anonymous
()
Ответ на: комментарий от mv

я не думаю что linux devs особо хорошо тестируют свой код. иначе бы небыло многочисленных kernel root exploits :P

anonymous
()
Ответ на: комментарий от anonymous

SeLinux - это монстро-образный и тормозной костыль

kto_tama ★★★★★
()
Ответ на: комментарий от mv

да и вообще достаточно взглянуть на то как написаны device drivers BSD vs. Linux, и все становится понятно у кого уровень в написании выше сказанных ниже.

anonymous
()
Ответ на: комментарий от anonymous

именно из-за этого и требуется SELinux. муахахахаха.

anonymous
()
Ответ на: комментарий от anonymous

>становится понятно у кого уровень в написании выше сказанных ниже.

Мне даже смысл этой фразы с трудом понятен.

kss ★★★★★
()
Ответ на: комментарий от anonymous

>значет не дано. bug in DNA-code. install SELinux to eliminate it.

Нет, скорее у кого-то с русской языкой проблемы. Зато становится понятным обилие английских слов.

kss ★★★★★
()
Ответ на: комментарий от anonymous

> И вообще-то BSD - R.I.P.

Присоединяюсь. По ссылке (ЛОРовец?):

September 25, 2007 - 7:18pm PiotrowskiM

LOL, OBSD trolls talk about SELinux...

anonymous
()
Ответ на: комментарий от annoynimous

> Чего-то мне не нравится, что товарищи из OBSD начали оправдываться, дескать наше лучше вашего. ИМХО, это свидетельствует как раз об обратном - что selinux лучше по всем параметрам, кроме, быть может, сложности описания политик.

Нет, это значит, что в чем то они обогнали Linux и теперь могут открыто заявить об этом.

А SELinux я много от кого слышал, что отключали, потому что не смогли разобраться с ним, в том числе и от умудреных опытом админов.

saper ★★★★★
()
Ответ на: комментарий от kss

возможно. пишу на русском редко, в основном только читаю художественную литиратуру и разговариваю на обыденном языке.

anonymous
()

Эхма , часть правды тут есть. Я не осилил SELinux (если честно, просто лень ломать башку) и пользуюсь дефолтными настройками дистрибутива. На мои скромные запросы их хватает.

Eugeny_Balakhonov ★★
()
Ответ на: комментарий от kss

Не знаю а помоему все достаточно просто процесс --> фаил,

есть доступ на конкретный файл у процесса или нет задается через chcon

The security context can bbe changed with command: chcon The chcon command can *only* use types that are defined in the policy. Поменять security context определенного файла можно, задав security context от другого файла

# chcon --reference /etc/shadow anaconda-ks.cfg # ls -z anaconda.cfg -rw------- root root system_u:object_r:shdow_t anaconda.cfg

To restor the default security context use: #restorecon /root/* #ls -Z /root -rw------ root root root:object_r:user_home_t anaconda.cfg

#chcon -t tm_t /etc/hosts

Set the context policy on the directory

# chcon -R --reference=/var/www/html /virtual

Есть уже готовая база заготовок

The policy allows certain features to be controlled through a set of booleans.

We can see them by command:

# getsebool -a -> list of polices with status of booleans

Стандартные все сервисы описаны

anonymous
()
Ответ на: комментарий от Eugeny_Balakhonov

именно поэтому элементарные фишки, не требующие настроек, надо включать в vanilla kernel, а не пихать patches.

anonymous
()
Ответ на: комментарий от annoynimous

> А ребята из OBSD занялись чем-то вроде коммунистичекой пропаганды: Делайте! Лучше! Качественнее!

Кстати все эти лозунги очень созвучны опусу M$ Writing Secure Code. (в нем кроме этих лозунгов еще помню решения предлагались типа запрашивать приложение при первом же SYN, нужно ли принимать ли входящее соединение TCP - "здравствуй, DOS от SYN FLOOD")

sv75 ★★★★★
()
Ответ на: комментарий от sv75

но подход я думаю не одинаковый. с этим нельзя не согласиться.

anonymous
()

>>политика безопасности SeLinux и язык, на котором она пишется, слишком сложна, что приводит к тому, что, цитата Damien Miller: "при развёртывании всех известных мне средних и крупных инсталляций Линукса, SeLinux был отключен."

А сколько ему известно средних и крупных инсталляций openBSD, хочется мне спросить? Действительно _крупных_, а не пары роутеров.

Далее - ничего там экстремально сложного нет и любой вменяемый админ, осиливший документацию, может её настроить. Да, не всё будет работать. Будут проблемы с X`ами, вот человек на OO жалуется. Но может сравнить в абсолютном соотношении то, что работает в linux и то, что в openbsd? Взять тот же самый оракл.. монстр ещё тот, но ведь работает...

По поводу прочего: взгляните хотя бы сюда: http://www.gentoo.org/proj/en/hardened/index.xml . Pax, GrSecurity ,RSBAC,hardened toolchain (и тот же propolice).

Быть может стоит сравнить с этим? А не чесать язык о том, что по дефолту безопаснее всех. Только с дефолтом никто не работает. А сложные системы требуют сложных средств для своей настройки.

deadman ★★
()
Ответ на: комментарий от deadman

Oracle DB was ported to Linux by Oracle Corp. и не так давно это было сделано.

PaX, GRSec, RSBAC опять же только patches. База на которой они все основаны не внесена в vanilla kernel.

anonymous
()
Ответ на: комментарий от sv75

> SELinux зло в любом случае, его же NSA делала

примитивные рассуждения о добре и зле от недостатка понимания.

> которая имеет право получать секретные неустаревающие патенты.

Бред.

> Если его интегрировать намертво, то чеерз годик выяснится что патенты NSA 0wNes Linux.... по крайней мере в штатах :)

NSA официально выдала свои идеи в коде по лицензии GPLv2. Если вы не знаете какие права дает GPL - советую внимательно прочитать.

szh ★★★★
()
Ответ на: комментарий от anonymous

а вот obsd приварило базу PaX. :P

anonymous
()
Ответ на: комментарий от Rubystar

> birdie, что делаешь во второй половине случаев, когда не отрубаешь?

Использую политики по умолчанию. По русски говоря, это только серверы, где нет извращений с запуском скриптов, которые из под apache всякую хрень вытворяют (так надо). Короче, я уже написал - если ваша платформа позволяет не делать шаг в сторону от политик, то SeLinux живёт.

Иначе я его сношу.

PS Даже в default installation RHEL/Fedora audit лог _постоянно_ растёт. Это говорит о том, что разработчики, ЧЁРТ ПОБЕРИ, не могут до конца настроить policy, чтобы не было ошибок MAC'a.

Подход OpenWall Linux и OpenBSD мне куда больше по душе. Хотя, нужно отдать должное, SeLinux систему даже без обновлений взломать практически невозможно.

Может ЛОР'овцы смогут разработать человеческий MAC систему для Линукса?

birdie ★★★★★
() автор топика
Ответ на: комментарий от Sikon

> И кто после этого скажет, что Птичка - не провокатор флейма? :)

ДА, я ХОТЕЛ здорового, технического, обоснованного флейма. Пока, увы, ни с чьей стороны не было ни одного нормального аргумента в пользу какой-либо системы.

birdie ★★★★★
() автор топика
Ответ на: комментарий от anonymous

подводим итоги обсуждениая:

Linux devs missing the point of all sec.projects, like PaX and grsec. OpenBSD devs sees it and implements it as default features in their OS of choice.

пойду-ка я книгу хорошую почитаю.

anonymous
()
Ответ на: комментарий от birdie

> ДА, я ХОТЕЛ здорового, технического, обоснованного флейма.

Слишком узкая тема, слишком мало людей в ней разбираются, практически нет людей, хорошо знакомых с обеими обсуждаемыми системами.

> Может ЛОР'овцы смогут разработать человеческий MAC систему для Линукса?

Нет.

tailgunner ★★★★★
()
Ответ на: комментарий от zort

> Мечты и надежды разбились об стену ;-)

> какое неромантичное отношение к ЛОР'овцам... ;)

Я объективен. Среди всех интересных флеймов на ЛОР не было ни одного на тему security.

Я вообще думаю, что на просторах ex-USSR нет ни серьезных исследований/разработок в этой области, ни серьезных применений (ну, может, совсем немного).

tailgunner ★★★★★
()
Ответ на: комментарий от szh

>> SELinux зло в любом случае, его же NSA делала > примитивные рассуждения о добре и зле от недостатка понимания.

Вижу, одного смайлика не хватило. Поставлю пять в следующий раз, хорошо.

>> которая имеет право получать секретные неустаревающие патенты. > Бред.

http://en.wikipedia.org/wiki/National_Security_Agency#Patents

Unlike normal patents, the NSA's are not revealed to the public and do not expire. Неужто все врут календари?

> Если его интегрировать намертво, то чеерз годик выяснится что патенты NSA 0wNes Linux.... по крайней мере в штатах :) > NSA официально выдала свои идеи в коде по лицензии GPLv2. Если вы не знаете какие права дает GPL - советую внимательно прочитать.

Я вполне могу лицензировать по GPlv2 код, включающей что-то запатентованое (мной или не мной). К чему это может привезти в теории и практике - давно известно, из-за этих опасений FSF шарахается от zip, gif, mp3 etc.

sv75 ★★★★★
()
Ответ на: комментарий от tailgunner

>Я объективен.

я с тобой в принципе согласен. поэтому именно не романтичное, а не неверное...

zort
()
Ответ на: комментарий от sv75

>лицензировать по GPlv2 код, включающей что-то запатентовано

лучше опасаться того, что они оставили в SeLinux известную только им дырку.

zort
()
Ответ на: комментарий от birdie

"Поддержка в современных операционных системах

* Частичная поддержка принудительного контроля доступа в операционных системах Windows (при наличии Active Directory) может осуществляться с использованием групповых политик, списков контроля доступа с запретом пользователю на изменение владельца и прав доступа к файлу."

И ничего больше. А MAC в Windows'е самый ненадёжный (я вообще его не заметил ... честно ... может покажите ... и AD я гоняю уже лет шесть, наверное ... не замечаю). Security Clearance 4 уровня имеет, например, RHEL5, а вот Windows - в пролёте.

Русская Wikipedia просто sucks.

birdie ★★★★★
() автор топика
Ответ на: комментарий от zort

(на всякий случай)это я типа иронизировал...

zort
()

birdie -- респект. ;)

km ★★★
()
Ответ на: комментарий от birdie

> Да, увы, я тоже часто (в половине случаев точно) отрубаю SeLinux, ибо до сих пор не хватает сил разобраться с этим монстром.

Да не так там все сложно. Достаточно внимательно прочесть доку на http://fedoraproject.org/wiki/SELinux (хотя там немало информации) и "пощупать" на практике утилитами, как это работает. А потом несколько дней следить за аудитами и реагировать на них (вначале чуть подумав, потом уже на автомате). Через пару неделек все пойдет отлично.

Я тоже selinux'а долго боялся, натерпелся из-за него проблем в ранних федорах, но вот сейчас вижу на десктопе людей, при установке 7 федоры не отключащих его - и все у них работает. Сам с восьмой попробую включить на основном десктопе.

Так же на новых машинах с centos 5 включаю - на всех все отлично, может на паре приходится пару правил в локальную политику добавить. На одном "многоцелевом" домашнем сервере побольше пришлось работать - squid + rejik требует нескольких правил, spamassassin в виде демона (читает/пишет пользовательские bayes-фильтры), общается с razor/pyzor/dcc, которые тоже читают конфиги и пишут состояние требует уймы правил, больше двух десятков. К счастью, с современными инструментами для работы с selinux очень просто отловить, что "что-то нужно сделать", понять, о чем идет речь и создать/внести несколько разрешающих условий в локальную политику. Все производится автоматически, кода писать не надо и руками лазить тоже не надо, но чтобы хорошо все получилось, нужно немного контролировать процесс и думать над тем, что предлагают.

На той машине исходник локальной политики получился около 90 строк. Постепенно накапливался по мере настройки сервисов недели две. Потом еще неделю изредка дополнение, с тех пор несколько месяцев полная стабильность. selinux работает как часы, никаких проблем, все очень просто.

В общем, selinux совершенно нестрашная штука при конфигурациях любой сложности - во всяком случае в rhel/centos и fedora. Главное только понять, как оно работает и как этим управлять и узнать, какие утилиты есть для управления. А дальше только заглядываение раз в месяц в аудит-лог и если там появляется запрещение (а утилита человеческим языком объяснит, что именно попыталась сделать такая-то программа), после размышления - положено ей такое делать или нет добавление сгенеренной другой программой строчки в файл локальной политики и "make" для выполнения трех команд по компиляции новой локальной политики, создания пакета и интеграции его в selinux. После этого все проблемы решаются, вопросов не остается. Времени требует 5 минут в месяц (если не ломают активно, конечно же - тогда трудно предсказать, но тогда оно того точно стоит).

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.