Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
MAC vs DAC 02.07.02 10:37
Автор: cybervlad <cybervlad> Статус: Elderman
|
То, что мандатная модель доступа "секьюрнее" дискретной, понятно. Но, прочитав очередной опус (см. ссылку) про рулезность реализации MAC в SELInux, задумался: а оно вообще "в мирных целях" сильно часто надо? Сходу как-то и не нарисовалось ни одного применения для меточной системы, кроме госструктур и соответствующих грифов секретности. Что думает общественность?
NSA
|
|
MAC vs DAC 02.07.02 23:41
Автор: qq Статус: Незарегистрированный пользователь
|
имхо:
разграничение ролей и доступа "живых" пользователей - не единственное применение данной системы.
В "мирном" использовании, если хочется особой секьюрности, ограничение доступа к базе данных только из процесса веб-сервера, например, может сослужить хорошую службу, если злоумышленник смог проникнуть в систему другим путем (не через веб-сервер)
он не сможет внедриться в процесс веб-сервера (не получив повышенные права в системе), не сможет самостоятельно подключиться к базе данных (ограничение на использование сокетов), не сможет изменить данные веб сервера (ограничение доступа к данным, обеспечение целостности)
в сеории выходит очень неплохой толк из MAC.
даже для обычного применения, если боишся за сви данные.
|
| |
MAC vs DAC 03.07.02 07:22
Автор: cybervlad <cybervlad> Статус: Elderman
|
> имхо:
> разграничение ролей и доступа "живых" пользователей - не
> единственное применение данной системы.
это понятно ;) тоже самое можно сказать про любой AC
> В "мирном" использовании, если хочется особой секьюрности,
> ограничение доступа к базе данных только из процесса
> веб-сервера, например, может сослужить хорошую службу, если
> злоумышленник смог проникнуть в систему другим путем (не
> через веб-сервер)
это тоже понятно. и, кстати, тоже не менее просто реализуется в дискретной модели.
> он не сможет внедриться в процесс веб-сервера (не получив
> повышенные права в системе), не сможет самостоятельно
или наоборот: усадить BIND в chroot() с правами какого-нибудь псевдоюзера типа games и все эксплоиты с ремотным рутовым шелом обломятся.
> (ограничение доступа к данным, обеспечение целостности)
> в сеории выходит очень неплохой толк из MAC.
> даже для обычного применения, если боишся за сви данные.
;))
никто не говорит, что MAC неприменим. речь о том, что "в мирных целях" обычно за глаза хватает дискретной модели, которая по умолчанию есть во всех системах - винде (кроме 9.х конечно), юниксе, нетвари.
мандатная модель (на основе меток безопасности) или модель Белла-ЛаПадулы изначально была предназначена для секретных систем с информацией нескольких уровней секретности. ее можно использовать и в мирных целях, спору нет. но обычная дискретка делает это не хуже ;)
|
| | |
MAC vs DAC 17.07.02 15:16
Автор: qq Статус: Незарегистрированный пользователь
|
хмм... я вот подумал.. как бы мне в рамках дискретной модели запретить одному отдельному пользователю запускать suid программы, или вызывать определенные системные вызовы?
это было бы чрезвычайно полезно для не-интерактивных юзеров, область действия полномочий которых должна быть ограничена, тогда компрометация такого пользователя не открывала бы такой широкий путь к поимению всей системы...
|
| | | |
MAC vs DAC 17.07.02 15:20
Автор: qq Статус: Незарегистрированный пользователь
|
|
можно конечно сказать о вещах вроде jail в freebsd.. но у такого подхода есть свои преимущества и недостатки, не всегда он применим или удобен
|
| | | |
MAC vs DAC 17.07.02 15:20
Автор: cybervlad <cybervlad> Статус: Elderman
|
> хмм... я вот подумал.. как бы мне в рамках дискретной
> модели запретить одному отдельному пользователю запускать
> suid программы, или вызывать определенные системные вызовы?
насчет суид-программ просто. делаешь rwxr-x--- на них и нужных юзеров включаешь в группу. мы же о юниксе говорим? с ситемными вызовами сложнее...
хотя, поставь RSBAC, он обе модели реализует и рули как угодно ;)
> это было бы чрезвычайно полезно для не-интерактивных
> юзеров, область действия полномочий которых должна быть
> ограничена, тогда компрометация такого пользователя не
> открывала бы такой широкий путь к поимению всей системы...
а зачем для этого мандатка? усадиьт его в chroot/jail и всех делов...
|
| | | | |
MAC vs DAC 17.07.02 15:28
Автор: qq Статус: Незарегистрированный пользователь
|
> > хмм... я вот подумал.. как бы мне в рамках
> дискретной
> > модели запретить одному отдельному пользователю
> запускать
> > suid программы, или вызывать определенные системные
> вызовы?
> насчет суид-программ просто. делаешь rwxr-x--- на них и
> нужных юзеров включаешь в группу. мы же о юниксе говорим? с
все же это дополнительный гимор...
надо делать каждый раз
find / -prem blabla -exec chmod \{\} \; после обновления системы... следить чтобы все нужные пользователи имели эту группу итд..
а если я хочу например определенному пользователю дать доступ только к 10 специальным прогам? ради него заводить группу и засовывать в нее остальных? (например хочу чтоб юзер qmailq мог запускать только из /var/qmail/bin)
да и на файл можно поставить только одну группу...
> ситемными вызовами сложнее...
> хотя, поставь RSBAC, он обе модели реализует и рули как
> угодно ;)
ну вот, а вопрос то о чем был: а стоит ли заморачиваться с MAC ?
выходит есть ситуации, когда стоит
>
> > это было бы чрезвычайно полезно для не-интерактивных
> > юзеров, область действия полномочий которых должна
> быть
> > ограничена, тогда компрометация такого пользователя не
> > открывала бы такой широкий путь к поимению всей
> системы...
> а зачем для этого мандатка? усадиьт его в chroot/jail и
> всех делов...
про jail я сказал в отдельном посте, а chroot это все же не то... syscalls не ограничены
|
| | | | | |
MAC vs DAC 17.07.02 15:42
Автор: qq Статус: Незарегистрированный пользователь
|
упс...
недостаточно просёк я че есть MAC
|
|
|
подробно о проекте
Анализ криптографических сетевых...
