If you can't understand it choose other language... [English] [Russian ] [French] [Czech] [Japanese] [Translate and add your language] RSBAC for beginners. Introduction. Before beginning to turn you computer into a fortress you should think of what you want. Any security system makes a lot of restrictions in your life, and a great security system makes great restrictions. Additional checks and authorizations lower productivity of a kernel, and such things as safe delete lower speed of file system. Forget about the superuser, it's one of the most serious security problems. Now you have separately System administrator and Security Officer. Both cannot influence against each other and even will compete for authority in system. System administrator can still operate the system, make settings, add and delete users, limit use by users of system resources. Security officer will limit all users (including the System Administrator) in access to any data, including system. For example, administrator can add/remove users, but cannot edit manually the files /etc/passwd and /etc/shadow if not allowed by the Security Officer. CAUTION!! Be careful at making the next changes, you may deny access to EVERYTHING in your system, at a point where even single user mode would not help you (against a kernel there is no reception). Your only rescue would be to boot a system with a standard Linux kernel. So, if you are not afraid of the problems mentioned above then let's go! Otherwise, stick to the classic UNIX security system... Kernel creation. What you need: 1. main tarball - rsbac-version.tar.gz or rsbac-version.tar.bz2 2. admin utils - rsbac-admin-version.tar.gz 3. kernel patch Download the latest RSBAC version (http://www.rsbac.org/). You need two archives: rsbac-current-version.tar.gz and rsbac-admin-current-versions.tar.gz. The first archive contains the kernel patches and the main RSBAC code, and the second contains the administration utilities. You need to add a new user, secoff with UID 400. Then during the first system boot he will automatically become the Security Officer. Unpack the kernel to /usr/src/linux, unpack rsbac-current-version.tar.gz in the same directory and apply RSBAC kernel patch to the kernel : patch -p1Lj and Mi dominates over Mj. With this definitions we also need some special rules. First, we need to use an access matrix D where Dij contains the permissions of the subject Si to the object Oj (read, write, execute and maybe others...). We don't have special access matrix in RSBAC and use standard UNIX rules. There are also the following additional decision rules (from main RSBAC documentation): 1.ss-property: Si dominates Oj, if x = r or x = w (x contains read access). 2.*-property: Si is trusted or 1.Oj dominates current level of Si, if mode = a 2.level of Oj is equal to the current level of Si, if mode = w 3.current level of Si dominates level of Oj, if mode = r 3.ds-property: x is in cell Mi,j of matrix M of authorized accesses As you see it's a very difficult model. In real life great part of programs will not work properly. So, I recommend that you use it, only if you perfectly know what you want to do. EXERCISE: Let's see MAC file and user attributes. Login as user "test". Create file /tmp/mactest, enter as security officer and run main administration program rsbac_menu. Go to "File/Dir Attributes menu". Choose /tmp/mactest file. There are MAC file attributes: * MAC security level - Set it into 2. * MAC categories - Don't touch it. * MAC trusted for user - Special case: the file can trust the user, despite his Security Level. It use only for executables. Now try to open the file (for example, using cat) under user "test". The security system rejects the access, despite the fact that you have an access conform with standard UNIX permissions. We need a higher security level to access this file. Run rsbac_menu and go to "User Attributes: Go to user attribute menu " menu... Oh, user has too many rights. Choose user "test". We need to check two of his rights: * Security Level - User can read document if his own level is not lower than the level of document. Set it to 2. * MAC Categories - Set of user categories. Now the user test can work with the file mactest. ATTENTION: MAC only allow to process change security level not higher then current one. So, if user Peter has level 0 and user John has level 2, then Peter's process cannot change UID to John's one. It's main reason root has maximum security level. EXERCISE FOR DEVELOPERS: Solve problem with root's security level. One solution may be to add a new "Enforced MAC security level" level attribute to file (like RC enforced role). ACL module Well you have enough knowledge for today?... No? Then go to ACL. Each file has one vector of permissions (wrxwrxwrx). Using a vector we can assign access permissions to the owner, to a group of users and to "others". But we want assign permissions to each users . For example, for user1 (wr-) , for user2 (w-x) and for group1 (--x). So, we need a list of permissions - access control lists (ACL). For these reasons we have included ACL module. It expands standard UNIX permissions. EXERCISE: Please, create /tmp/acltest directory, run rsbac_menu program, go to file rights menu and then to " ACL Menu: Go to ACL menu "... Where are the permissions ? Don't worry, press "Change mask" and ... * ADD_TO_KERNEL - for kernel modules (drivers). * ALTER - Change control information for IPC * APPEND_OPEN * CHANGE_GROUP * CHANGE_OWNER * CHDIR * CLONE-clone() or fork() call. * CLOSE * CREATE * DELETE * EXECUTE * GET_PERMISSIONS_DATA-get UNIX permissions. * GET_STATUS_DATA- stat() system call. * LINK_HARD * MODIFY_ACCESS_DATA-Modify access time. * MODIFY_ATTRIBUTE-Modify RSBAC attribute. * MODIFY_PERMISSIONS_DATA- Modify UNIX permissions. * MODIFY_SYSTEM_DATA- Change system data (ports,...). * MOUNT * READ * READ_ATTRIBUTE- Read RSBAC attribute. * READ_OPEN * READ_WRITE_OPEN * REMOVE_FROM_KERNEL- for kernel modules (drivers) * RENAME * SEARCH * SEND_SIGNAL-send signal to other process * SHUTDOWN * SWITCH_LOG-switch RSBAC log levels. * SWITCH_MODULE-switch RSBAC module. * TERMINATE- terminate process * TRACE- trace process (ptrace() call). * TRUNCATE * UMOUNT * WRITE * WRITE_OPEN Ohh... that is all. You can enable/disable each of the attributes, but we will test only one of them now. Disable for /tmp/acltest directory the CHDIR permission. Now nothing can change to this directory. We change the general mask, but we can add new (ACL entry) for certain user, group or role (about role see "RC module" chapter). Choose "Add ACL Entry:Add group, role or user entry" menu item and then say we want to add a user. Choose the user from the list (for example, user tttt). You can change the mask for this user now. Select this mask and enable all permissions in the vector. Test the result. The user tttt and only the user tttt can change directory to /tmp/acltest. (Security Officer can change dir too, but you can restrict his access by ordinary UNIX rights!) You can also add entries to group of users (ACL group) and RC-role. But you need to read the description of RC before. ATTENTION: If you remove all rights to all users from ACL mask of some file, security officer still will have access to this file. It's result SUPERVISOR right in mask. You can also remove SUPERVISOR in the /tmp/acltest mask under certain conditions: if enabled in kernel config and you have a personal user ACL entry with SUPERVISOR in it. EXERCISE: Another interesting feature in ACL is inheritance. You can change :DEFAULT: ACL rights to some types of targets: users, files, etc. Test it. Be carefull. If you remove some ACL rights to security officer you can lost all chances to change ACL settings. RC Module Do you like the theater?... Yes? Then it will be easy for you to understand the idea of role. Otherwise you must read the following text. First, the key words are targets and requests. A subject makes a request of access to a target. Requests have same ACL permissions (CHDIR, APPEND_OPEN, ....). Targets are: FILE, DIR, DEV, IPC (semaphore, message queue, pipe,...), SCD(System Control Data. For example, ports, kernel logs ...),USER,PROCESS,NONE(empty target),FD(file descriptor, FILE and DIR together). Each target has a type. You can use default type (System FD, Security FD,...) of create a new one. Role is a class of subjects. Role defines this class of permissions to defined targets and other roles. There are general role parameters: * Name -Name of the role * Role Comp- List of the roles this role can switch without change owner. * Admin Roles -List of the roles this role can administrate (change parameters). * Assign Roles -List of the roles this role can assign to users and processes (using administration utilities). * Type comp FD- ACL permissions of this role for all types of target FD.. * Type comp DEV-same, permissions for target DEV. * Type comp Process-same, permissions for target Process. * Type comp IPC-same, permissions for target IPC. * Type comp SCD- same, permissions for target SCD. * Admin Type- Type of role. You can also use the first four parameters (RC separation of duty facility) instead of this. Type may be : General User, System Admin or Role Admin. * Default FD Create Type - Type of target or inherit from ... * Default Process Create Type * Default Process Chown Type * Default Process Execute Type * Default IPC Create Type Is it difficult? Yes, it's difficult, but it very powerful too. You can make flexible settings and achieve fantastic results. For example, the administrator can add/remove users, but cannot edit manually the files /etc/passwd and /etc/shadow, after our settings. It may be very useful for a Web-site. Then intruders cannot remove the first Web-page, even though they have root access. Only Apache can work with this page. EXERCISE: First, create a new target type - Passwd FD. Make it using the "RC Types" menu. Then make a new role Admin Passwd. Go to menu "RC Roles", choose the role "System Administrator" (using "Rolelist: Choose role from list" menu) and copy to the new role (" Copy Role (New Role)" menu item). Rename the new role to Admin Passwd. Change the ACL permissions of this role to target "Passwd FD" (set full permissions, other roles has no rights to this target by default). Add to System Admin role the permission to read this target (read-only not read-write!). Well, the model is ready. Apply it to your real objects. Be very careful , you can loose access to your own system. A good idea is to try to login-in using one virtual console and make settings using another one. Run rsbac_menu. Go to the file attributes menu and find the parameter: * RC Type FD - Type of this target concerning RC model. choose the file /etc/passwd and set the value Passwd FD. Now root (System Admin) has read-only access to this file. DON'T logout for the moment! Choose the file /bin/login and find the following attribute: * RC Force Role- Role applied to process. It's the same as the SUID-bit in UNIX. The program will be run by root (System Admin), but the process will have another role. Set this value to "Admin Passwd". Now login has full access to /etc/passwd. You can also give full access to useradd and userdel programs. So programs has full permissions, but root can only read files. The system protected by RSBAC. Other interesting RSBAC modules. FF Module. There is another interesting RSBAC module -File Flags. Using this module you can eazy assign rights to whole directory trees. You can, e.g., assign "read_only" flag to /bin /sbin /usr/bin /usr/sbin Then all users can execute programs,they need, but nobody can destroy files. Interesting feature is FF inheritance. You can remove inheritance for selected file by turning off "add_inherited" flag. So, you can make "read_only" /etc directory with writable /etc/mtab file. File flags list: * no_execute -you can apply this flag to /home, so users cannot execute * self compiled programs without signing by secoff.. * secure_delete - enable secure deletion to file. * write_only - protect your files from reading (for example,log files) * search_only - usefull only for directories. * execute_only -no comments. * read_only-no comments. FF is very eazy and powerfull module. ATENTION: If you enable "FF Role Protection" feature during kernel config, you cannot login to system as security officer. FF will prevent CHANGE_OWNER from administrator to security officer. You will have to login as general user and make su to officer. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= NOTE:"Role Protection" comes from older RSBAC version when AUTH module not be written yet. This feature has all RSBAC modules (exluding AUTH) and works same in FF. But RC uses its own rc_role (instead system_role), and you can set the intermediate role (the one that must always be changed to or from) at compile time. Default is 0, the predefined General_User. This feature gives a lot of restrictions and still not really secure. This is the reason why the default config has Role Protection turned off, but AUTH turned on. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= RSBAC Distribution All things you seen you can eazy get by using ready RSBAC distribution. Now we have a beta of ALT Linux Castle - first RSBAC-based Linux distribution. See page http://people.altlinux.ru/inger/index-en.html for details Conclusion. We have discussed only some of the RSBAC decision modules. You can see others yourself and send questions to me or to RSBAC mailing list. I'm going to write new articles about this great Security System. In conclusion here are some exercises for you: * You can make own decision module and insert them inside the kernel as a driver (You should enable "REG module" feature during the kernel configuration) * You can switch modules on-the-fly (You should enable "Switch modules" feature during the kernel configuration) * You can move RSBAC ACI (Access Control Information) database from /rsbac to another directory. Change corresponding value in /usr/src/linux/include/rsbac/aci_data_structures.h. You can also use it for dufferent RSBAC configurations. * You can develop your own RSBAC modules. So, you can develop, improve, enjoy RSBAC and tell us your results! The show must go on... Stanislav Ievlev Translation from Russian into English by: Stanislav Ievlev Konstantin Volkov and Fabrice Marie