Чего то вместо статьи выдается

502 Bad Gateway

Это и есть безопастность?

502 Bad Gateway
nginx/0.3.9

> Это и есть безопастность?

нет, это простая безграмотность

Какая-то попсня. Начало уже веселит.

> Suid-бит - большая головная боль системных администраторов,

Гыгы, может быть имелось в виду _тупых_ системных_администраторов_суидящих_какие_ни_попадя_файлы?

> Используемый в ней дискреционный метод предоставляет слишком широкие возможности: любая программа, запущенная от имени пользователя, обладает всеми его правами - может читать конфигурационные файлы, устанавливать сетевые соединения и т. д.

А нечего под рутом сидеть, тогда и памперсы чаще менять будете.

> Другой большой проблемой является наличие аккаунта суперпользователя (или администратора) с очень широкими полномочиями.

No comments. Подстолом.

> В этом смысле системные приложения равны в правах, хотя на самом деле каждому из них требуется "своя" часть прав суперпользователя - обращение к сетевому интерфейсу, чтение файлов с паролями, запись сообщений в системный журнал и пр. Стоит злоумышленнику взять контроль над одной из таких служб, и он получит неограниченный доступ.

Выполнения приложения не под рутом уже не модно? в крайнем случае - chroot? jail?
Автор - мудак.

>Гыгы, может быть имелось в виду _тупых_ системных_администраторов_суидящих_какие_ни_попадя_файлы?

Вот у меня в /bin 6 суидных програм. Причем полные права реально ни одной из них и не нужны. Находят дырку в /bin/ping - и получают полные права.

Вот например, зачем для настройки iptables/netfilter-а нужно обязательно иметь рутовый доступ? В идеале для этого нужно обладать лишь правами "изменить" на объекты ядра типа "netfilter tables". Ничего больше, вообще говоря, и не требуется.

>Выполнения приложения не под рутом уже не модно? в крайнем случае - chroot? jail?

Не спасет. При "традиционной" модели безопасности сСервис на привелигированный порт может повиснуть только имея права рута, а значит имея полные права. И никак от этого chroot-ом не защитишься.

Хорошая статья. Даже с картинками, а как подругому, без картинок нам тупым анонимусам не понятно.

>>В этом смысле системные приложения равны в правах, хотя на самом >>деле каждому из них требуется "своя" часть прав суперпользователя - >>обращение к сетевому интерфейсу, чтение файлов с паролями, запись >>сообщений в системный журнал и пр. Стоит злоумышленнику взять >>контроль над одной из таких служб, и он получит неограниченный >>доступ.

>Выполнения приложения не под рутом уже не модно? в крайнем случае - >chroot? jail?
>Автор - мудак.

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

Мудели безопасности.

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

А дествительно - обясните что такого решает SELinux, что не смог сделать RSBAC? Он ведь был уже когда SELinux под стол пешком ходил?

Хорошая статья для тех, кто хочет узнать, что такое SELinux и для чего он нужен, т.е. и для меня в т.ч. :) А дальше, по мере необходимости - руководство пользователя, добро пожаловать! :)

>Не спасет. При "традиционной" модели безопасности сСервис на привелигированный порт может повиснуть только имея права рута, а значит имея полные права. И никак от этого chroot-ом не защитишься.

курить про chroot`нутый named в качестве примера до просветления

хорошая статья - нечего тут трындеть

Классная статья. Захотелось попробовать SELinux. Зачем он нужен уже понял :)

Тупой ныне анонимус пошел, на мормышку берет...

Статья очень даже неплохая, стимул почитать побольше по данной теме.

да ну, очень уж навороченная система.
где её использовать с тысячами правил?
на одном компе внедять такую систему - нафиг не надо.
в серьёзной организации - чтобы всем этим рулить нужен не один специалист, занимающийся конкретно этим. Постоянное развитие, изменение требуют постоянной отладки правил, добавления, удаления и создания.
Пока что слишком наворочено, не стоит оно того.

2GladAlex ** (*) (26.04.2006 20:07:33):

прежде чем ты потратишь кучу времени на изучение SELinux прочитай здесь http://www.rsbac.org/documentation/different_models

Для тех кто всё же решился начинаем курить http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ind... )

> Автор имел в виду - что незачем проге, обращающейся например к сетевому интерфесу и только к нему иметь все рутовые права - это существенно снижает безопасность.

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

P.S. Пришло в голову "полурешение" "для бедных"ю Есть служба, которая висить на привелигированном порту, а пускать её от рута не хочется. Например, bind. ;-) Что можно сделать? Вешаем её на непривелигированный порт и настраиваем локальные редирект с привелигированного на него, средствами iptables... ;-)

а здесь http://marc.theaimsgroup.com/?l=selinux&m=98624460912706&w=2 сравнивается RSBAC с SELinux

здесь http://www.cs.utah.edu/flux/fluke/html/flask.html про Flask (роданачальник SELinux)

>курить про chroot`нутый named в качестве примера до просветления

Во всех примерах, которые я видел, named (либо другой какой-нибудь сервис) запускается из-под рута, просто потом скидывает "лишние" привилегии. Если ты имел ввиду другой способ - ткни меня носом.

Причем если подходить формально, named-у кроме как возможности биндится на 53 порт других привилегий и не нужно вовсе.

А, ну кстати, вариант с редиректом на непривилигированный порт тоже сработает, только это все-таки костыль :)

P.S. Причем костыль с дыркой, насколько я понимаю. Если каким-нибудь образом "завалить" bind, то можно спокойно прибиндить на этот порт вредоносную программу, причем никаких особых привилегий не потребуется.

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

Согласен.
Краткий введенеие в тему, ничего более. Кому интересно, пусть копает дальше.
Крики анонимов от безграмотности. SELinux решает задачи более гибко и при правильной настройке сможет решить кучу проблем.
Вероятно, политики безопасности дожны формировать создатели серверного ПО.К сожалению использовать зависимости RPM пакетов и их состав для формирования политик не получится - не оправданно длинные цепочки зависимостей и нет точного указания типа файла и режима использования. Но если политики будут поставляться в RPM, то проблем с безопасностью станет много меньше даже с нулевой квалификацией админа.

>> Это и есть безопастность?

>нет, это простая безграмотность

нет! это ngnix!

уже который раз замечаю, что не сайт с глюками - то ngnix :)))

Одно дело _запускаться_, а другое _выполняться_. Читайте мой сообщения внимательнее.
Цитата:
"Выполнения приложения не под рутом уже не модно?"

Статья хороша не содержанием а выбраной темой Это Вам не "Когда же линукс займет десктоп"

Когда была нужна была инфа по SELinux, IDC и тп нашел только разрозненые обрывки - статьи про безопасность в линуксе нужны

RSBAC не смог пролезть в vanilla kernel, ибо за ним не стоял RedHat и военные США.