| LINUX-BG Адрес : http://www.linux-bg.org |
| Въведение в RSBAC, част III |
|
От: Н. Антонов Публикувана на: 3-12-2004 Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=367369318 |
|
Имаме поотделно две множества - множество от обекти О и множество от субекти S. Под обекти ще разбираме всякакви ресурси на системата като файлове, директории, позволена за заделяне памет, pipe файлове и файлове устройства. Субектите са потребителите, които пускат и използват тези ресурси. Субектите се опитват да получат достъп до обектите, а системата за защита на достъпа им позволява или отказва желания достъп. В мандатния модел на защита са необходими критерии, на базата на които да се извършва позволяването или отказът на достъп до даден ресурс. На всеки обект и на всеки субект се назначава мандатен маркер - ниво на достъп, чило L и категориално множество M. Последното ще представим във вид на множество от 64 елемента, където всеки елемент е 0 или 1. Ще приемем, че категориалното множество M1 се явява подмножество на категориалното множество M2, ако за всяка единица i в множеството M1 съществува единица i в множеството M2. В противен случай ще казваме, че множеството M1 и M2 не се пресичат. Да разгледаме множество от мандатни маркери, т.е. {Li,Mi} и да ги поставим като съотношения. А именно, ще считаме, че маркер {Li, Mi} доминира над маркер {Lj,Mj} и ще ги опозначим съответно {Li,Mi} > {Lj,Mj}, ако Li > Lj и Mi е надмножество на Mj. Необходимо ни е да имаме също така и т. нар. матрица на достъпа D, където при пресичането на i и j се посочва какви права на достъп има субектът i спрямо обекта j. Можем да имаме например права за четене, стартиране, промяна и стартиране. Дадената матрица носи наименованието Дискретизационен модел на достъп и в RSBAC се поражда от стандартните файлови права в Unix с оглед името на потребителя и неговата група. И така, в модела се въвеждат следните правила:
Както сигурно сте успели да забележите, даденият модел натрупва много сериозни ограничения. Работата с него не е така лесна и програми, които на се съобразени с него, почти винаги със сигурност ще получат отказ за достъп. Сега ще разгледаме какви параметрии за файлове и потребители управляват този модел. Да създадем един файл ~/mactest. Отново пускаме в директорията, в която се намира този файл централната програма за адимнистриране rsbac_menu. Всички настройки правим като secoff - отговорник по сигурността. Модулът MAC притежава следните параметри:
И така, файлът е засекретен и ако сега се опитаме да го отворим, нищо няма да стане, дори и стандартните UNIX права да ни позволяват да го сторим. В програмата rsbac_menu отиваме в менюто за управление на потребители ("User Attributes: Go to user attribute menu") и с немалко удивление откриваме, че за потребителя имаме не по-малко параметри отколокото за файла. Сега ни интересуват тези:
Избираме потребителя, в домашната директория на когото създадохме нашия файл mactest и да му зададем ниво не секретнст 2. Сега, след като този потребител влезе следващия път в системата, вече ще може да отваря този файл. Важен момент: Модулът MAC позволява да се извършва промяна на UID на потребителя, само ако нивото на секретност на текущия потребител не е по-ниско от нивото на секретност на новия. Основният проблем е в това, че администраторът (root) винаги има максимално ниво на секретност. Упражнение за разработчици: Модулът ACL Мандатният достъп е хубав, но имаме нужда от нещо повече. Имаме нужда да контролираме правата за достъп до файла с точност до милиметър, с точност до потребител или до група от потребители. С тази цел можем да включим модула ACL, който добавя към стандартните права списъци за контрол на достъпа. Да създадем директория ~/acltest. Стартираме програма rsbac_menu и избираме в менюто за управление на правата на този файл, след което посочваме "ACL Menu: Go to ACL menu". Там, за разлика от предишните случаи, няма да видим никакво изобилие от права, но цъкнете ли на "Change Mask" ще видите дълъг списък с възможности. Ето и някои от тях, от които може да се добие представа за какъв тотален контрол на достъпа може да се установи върху всички видове ресурси на системата:
Да изключим за директорията ~/acltest атрибута CHDIR. Сега вече никой не може да влезе в тази директория, независимо кой е. Дайте да го направим по-интересно: да речем, да направим така, че потребителят test все пак да влиза в тази директория. Връщаме се отново в основното меню на модула ACL и избираме "Add ACL Entry: Add group, role or user entry". Ще бъдем попитани какво искаме да добавим. Отговаряме, че искаме да добавим потребител от списъка. Включваме всички атрибути (в това число и CHDIR, отключен в основната маска) и се убеждаваме, че само test може да влиза в тази директория. По подобен начин можем да добавим и група от потребители. Освен това, когато овладеете и ролевия механизъм RC, можете да задавате индивидуални настройка на избраните от вас роли. Упражнение: Следва... << Въведение в RSBAC, част IV | Въведение в RSBAC, част II >> |
|
Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук,
но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора,
както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.
All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
|