Модулът RC
Обичате ли театър? Ако е така, то разбирането на начина на работа на ролевия механизъм няма да ви се стори трудна задача.
Тук въвеждаме термините заявки и цели.
Субектите (тук вече процеси) правята заявки за достъп до целите. Заявките могат да бъдат най-разнообразни и да съвпадат с правата в ACL.
Целите могат да бъдат:
- FILE - Файл.
- DIR - Директория.
- DEV - Устройство.
- IPC - IPC обект: семафори, памет за заделяне и т.н.
- SCD - Системни данни като име на машина, дата, системен дневник. Всички те по правило са само за четене.
- USER - Потребители.
- PROCESS - Процеси.
- NONE - Празен обект.
- FD - Файлов дескриптор.
При това всеки вид цел може да си има свой подвид. Например, файлът може да бъде обикновен, секретен или системен.
Ролята определя даден клас от субекти, на които се задава какви правата ще имат по отношение на определен подвид цели и други класове. Да разгледаме тези параметри подробно.
- Name - Наименование на ролята.
- Role Comp - Съвместими роли. Роли, от които може да се преминава в други без смяна на потребителя.
- Admin Roles - Роли, чиито потребители могат да администрират.
- Assign Roles - Роли, чиито потребители могат да задават роля на потребител или процес.
- Type comp FD - Тук се посочва какви ACL права има дадена роля при обръщане към един или друг подвид FD.
- Type comp DEV - Аналогично за типа DEV.
- Type comp Process - Аналогично за типа Process.
- Type comp IPC - Аналогично за типа IPC.
- Type comp SCD - Аналогично за типа SCD.
- Admin Type - Остарял параметър, посочващ тип на роля: Системен администратор, Ролеви администратор (Отговорник по сигурността) или Обикновен потребител. Вместо него може да се ползват първите четири параметъра. Въперки това той е напълно работоспособен и може спокойно да се използва.
- Default FD Create Type - При създаване на обект от типа FD ще бъде използван съответен поттип. Например, може да бъде създадена роля само за секретните файлове и директории.
- Default Process CreateType - Аналогично за клониращите се процеси.
- Default Process Chown Type - Подтип на процеса след смяна на потребителя (setuid).
- Default Process Execute Type - Подтип на процеса след стартиране.
- Default IPC Create Type - Подтип на новите IPC обекти, семафори т.д.
Такова количество настройки позволява не само да си усложните живота, но и да настроите така сигурността на системата, че да постигнете фантастични резултати.
За да дам пример, ще ви разкажа как да настроите системата така, че администраторът да добавя потребители, да сменя пароли, да ги изтрива и въпреки това да не може ръчно да редактира /etc/passwd или /etc/shadow. Такъв фокус може да бъде полезен за организацията на уебсайт. Например никой друг освен Apache да не може да работи с файловете от определена директория. Съответно, даже и да има пробив, слосторникът не може да подмени първата страница на сайта.
И така, задаваме нов подтип за цел FD - Passwd FD. Това става с помощта на програмата rsbac_menu и подменюто "RC Types". Ще бъдете попитани какъв подтип да е целта. Изберете FD и давай те напред.
Следващият етап се състои в създаването на нова роля Admin Passwd. За целта отиваме в менюто "RC Roles". Избираме готова роля 'System Administrator" (от ''Rolelist: Choose role from list"), копираме съдържанието й в нова роля ("Copy Role (New Role)") и я наричаме "Admin Passwd".
Така сега, появяват се съответните ACL права за всички роли, които са по подразбиране празни. При това положение всички потребители от всички стари роли няма да могат да четат файлове от подтип Passwd FD. Настройваме новата роля така, че тя да може да прави всичко с файловете от този подтип. Включваме всички ACL права. Отлично. Формалната подготовка е приключена, сега остава само да зададем съответните атрибути на файловете и програмите, които са ни нужни.
Влезте в системата на едната конзола като root и на друга катоsecoff. Отиваме в настройката на основните параметри на файла /etc/passwd и намираме параметъра:
- RC Type FD - подтип на този дескриптор съгласно RC.
Променяме значението по подразбиране на Passwd FD. Сега root няма да може вече да отваря този файл. Затова влязохме предварително като root, защото иначе след тази промяна програмата login няма да има права да го прочете и да пусне когото и да било в системата.
Следващата стъпка е да зададем роля на програмата /bin/login:
- RC Force Role - Роля, която файлът ще приеме при стартиране независимо от ролята на този, който го стартира. Нещо като suid при стандартните UNIX права.
Променяме значението от старндартното на "Admin Passwd". След тази операция login ще работи нормално. Аналогичната процедура трябва повторим и върху всички програми, които работят с файла /etc/passwd. Това е всичко. Новата защитна бариера е готова.
Заключение
В това ръководство далеч не разгледахме всички модули. Това се обяснява първо с нежеланието да се затормозява мозъкът на читателите с излишна информация. Ако е необходимо, ще се появи нова поредица от ръководства. Въпреки това накратко ще се спрем на няколко интересни момента, предполагащи изучаване занапред.
- Оказва се, че можем да добавяме в движение собствени модули. Те се изпълняват под формата на драйвери за ядрото със специален интерфейс. Трябва да се включи модулът REG при конфигуриране на ядрото.
- Модулите могат в движение да се включват и изключват (вж. подменюто "Switch Modules"). Не забравяйте да включите съответната точка при конфигурирането на ядрото преди това.
- Можете да се опитате да местите директорията с базата данни и да я преименувате, като променяте името й във файла /usr/src/linux/include/rsbac/aci_data_structures.h. Не забравяйте след това да прекомпилирате ядрото. Освен това, използавйки различни наименования, можете да стартирате различни конфигурации на RSBAC.
- Можете да съзадедете и собствен модул за защита.
Пробвйте, разработвайте, разказвайте на света за своите резултати.
Цялата поредица от статии можете да изтеглите от адрес http://web.logos-bg.net/linuxbg/RSBAC.pdf (Н.А.).
добре
зле
Вариант за отпечатване
