SIMPLE RSBAC HOWTO - MY WAY. Author : sftf Started : 22.02.2006 Last edit: 10.03.2006 1. Disclaimer ------------- This document is under development!!! It will not allow you to construct fully-functional system!!! My native language - Russian, so my English is very bad. I am sorry for mistakes. Corrections are appreciated and welcomed. As my knowledge in security and linux administration are rather superficial, all that here will be stated is not say-so. "Use the concepts, examples and information at your own risk. There may be errors and inaccuracies that could be damaging to your system and you may lose important data." (from tldp.org HOWTO's) 2. Introduction --------------- In this text I shall try to state process of installation and configuration of the RSBAC on a real example (in sense: no "theory", only "practice"). The general attention will be given to protection file system objects (because all in linux is files :o) and because it's easier to me understand what I protect) with AUTH, ACL decision modules. RC and CAP modules will be used as required. Using all models (or even ACL+RC models) at the same time is EXTREMLY hard - very difficultly to plan and predict all rights effects, hold all things and accepted decisions in brains memory. My brains does not suffice. If more to take into account tons of files, network, processes, users, devices, that management of such system turns to a real nightmare! Target to protect - Linux office-internet gateway builded from sources (Linux From Scratch) with postfix mail system. RSBAC consist of kernel part and userland tools. So we need to compile RSBAC-enabled kernel, compile/install admin tools, and finally boot with RSBAC-enabled kernel. 3. Kernel compiling/needed packages ----------------------------------- All things starts here. I suppose you have working linux system with kernel's sources. I have linux-2.6.15.1. All RSBAC packages you can download from http://rsbac.org. So we need to download: kernelland patch-linux-2.6.15-rsbac-1.3.0pre1.diff.bz2 - kernel pacth to integrate RSBAC, rsbac-common-1.3.0pre1.tar.bz2 - actually RSBAC code, userland http://download.rsbac.org/dialog/dialog-0.9b-20020814.tar.gz and patch http://download.rsbac.org/dialog/dialog-0.9b-20020814.diff rsbac-admin-1.3.0pre1.tar.bz2 - userland admin tools to manage our RSBAC system. The dialog program is necessary for rsbac-admin. You can download my (simple)policy example: http://sftf.narod.ru/rsbac_policy.tar.bz2 I recommend you to keep all old compiled kernels you have intact - they may be necessary for you, if something will go wrong. Cd into /usr/src. Backup all previous kernel's src's. Remove them or move into the other location. Now we unpack kernel's src: tar -jxf linux-2.6.15.1.tar.bz2 Symlink dir linux-2.6.15.1 to "linux" or simply rename it to "linux". Copy: patch-linux-2.6.15-rsbac-1.3.0pre1.diff.bz2 rsbac-common-1.3.0pre1.tar.bz2 into /usr/src/linux Cd into /usr/src/linux. Next patch vanilla kernel: bzip2 -dc patch-linux-2.6.15-rsbac-1.3.0pre1.diff.bz2 | patch -p1 Unpack rsbac src's: tar -jxf rsbac-common-1.3.0pre1.tar.bz2 Remove patch-linux-2.6.15-rsbac-1.3.0pre1.diff.bz2 rsbac-common-1.3.0pre1.tar.bz2 from /usr/src/linux. Now we ready to configure our kernel: make menuconfig Configure all as you wish. And now let's pay attention to RSBAC. In the menu you will see: "Rule Set Based Access Control (RSBAC)->" Enter - you'll see: []"Rule Set Based Access Control (RSBAC)" Select it. Now you'll see: [*] "Rule Set Based Access Control (RSBAC)" "General RSBAC options->" "User Management->" "RSBAC networking options->" ------------------------- [ ] "RSBAC Maintenance Kernel (Use with care!)" ------------------------- "Decision module (policy) options->" "Softmode and switching->" "Logging->" [ ] "RSBAC symlink redirection" [ ] "Allow disabling of Linux filesystem access control" "Other RSBAC options->" In "General RSBAC options->" make selection like this: [ ] 'Initialize RSBAC in separate kernel thread' [*] 'RSBAC proc support' [*] 'Check on init' [ ] 'Disable RSBAC writing to disk' [ ] 'Allow attribute writing on MSDOS filesystems' (5) 'RSBAC auto write to disk interval in seconds' (32) 'Maximum number of list hashes' [*] 'Support transactions' (3600)'Maximum transaction time in seconds' [*] 'Randomize transaction numbers' [ ] 'Automatic list replication' [ ] 'RSBAC debugging support' [ ] 'Provide DEV and USER backup files' (400) 'RSBAC default security officer user ID' [*] 'Delayed init for initial ramdisk' (4) 'Number of GEN process lists' In "User Management" make selection like this: [*] 'User management' [*] 'Use Crypto API Digest SHA1' (2000)'Minimum auto user ID' (2000)'Minimum auto group ID' [ ] 'Exclusive user management' [8] 'Minimum password length' [ ] 'Require non-alphabetic character in password' [*] 'Remember password history' (8) 'Number of successive passwords to remember' In "RSBAC networking options" leave default selection: In "Decision module (policy) options" and below make selection like this: [ ] 'Support for Registration of decision modules (REG)' [ ] 'Build REG sample modules' [*] 'RSBAC support for AUTH policy' "AUTH Policy Options->" [*] 'AUTH module and attribute protection' [ ] 'Protect switching of other modules' [*] 'AUTH protection for User Management' [*] 'AUTH support for effective and fs owner control' [ ] 'Always allow setting to same id' [*] 'AUTH support for Linux group control' [*] 'AUTH support for effective and fs group control' [ ] 'AUTH learning mode support' [*] 'RSBAC support for RC policy' "RC Policy Options->" [*] 'RC protection for AUTH module' [*] 'RC protection for User Management' [*] 'RC protection for GENeral attributes' [ ] 'Provide RC backup files' [*] 'RC check access to UNIX partner process' (4) 'RC number of process lists' (4) 'RC number of role lists' (4) 'RC number of type lists' (999999) 'RC kernel process type' [*] 'RSBAC support for ACL policy' "ACL Policy Options->" [*] 'ACL protection for AUTH module' [*] 'ACL protection for User Management' [*] 'ACL protection for GENeral attributes' [ ] 'Provide ACL backup files' [ ] 'ACL learning mode support' [ ] 'RSBAC support for MAC policy' [ ] 'RSBAC support for PAX policy' [ ] 'RSBAC support for DAZuko policy' [*] 'RSBAC support for Linux Caps (CAP) policy' "CAP Policy Options->" [*] 'Support CAP process hiding' [ ] 'CAP protection for AUTH module' [ ] 'Log missing capabilities in capable()' [ ] 'RSBAC support for JAIL policy' [ ] 'RSBAC support for System Resources (RES) policy' [ ] 'RSBAC support for FF policy' [ ] 'RSBAC support for PM policy' In "Softmode and switching" make selection like this: [*] 'RSBAC soft mode' [ ] 'Toggle soft mode with SysRq-X' [*] 'Individual module softmode support' [*] 'RSBAC policies switchable' [ ] 'Switch AUTH policy' [ ] 'Switch RC policy' [ ] 'Switch ACL policy' In "Logging" make selection like this: [*] 'Individual file/dir/dev object logging' [*] 'Individual user logging' [*] 'Individual program logging' [*] 'Log program file' [*] 'Log full path' (512) 'Maximum path length (256 - 4000)' [ ] 'Pseudonymous logging support' [ ] 'Pseudonymize filesystem objects' [*] 'Syslog rate limit' (1000)'Default allowed message lines per second' [*] 'RSBAC own logging facility' [*] 'Allow to disable logging to syslog' [ ] 'Log to remote UDP network socket' In "Other RSBAC options" make selection like this: [ ] 'Support secure_delete' [*] 'Intercept sys_read and sys_write' [*] 'Intercept Semaphore IPC operations' [*] 'Control DAC process owner (seteuid, setfsuid)' [*] 'Control DAC process group (setegid, setfsgid)' [ ] 'Hide processes in /proc' [ ] 'Hide filesystem objects' [*] 'Support freezing of RSBAC configuration' [ ] 'Also freeze User Management' [ ] 'RSBAC check sys_syslog' [*] 'Generic check in sys_ioctl' [ ] 'Check CHANGE_OWNER on PROCESS against USER target' [ ] 'Make RSBAC data files visible' [ ] 'No decision on net mounts' [ ] 'X support (normal user MODIFY_PERM access to ST_ioports)' [*] 'Faked root uid' [*] 'RSBAC extra statistics' Now compile kernel as usual: make bzImage I don't use kernel modules (for security and perfomance), so I don't build them. And copy it to /boot: cp /arch/i386/boot/bzImage /boot/kernel-2.6.15.1-rsbac Some remarks about kernel options. General RSBAC options->'Delayed init for initial ramdisk' - select if you use initrd. I use it because of encrypted root partition. Other RSBAC options->'Faked root uid' - we need this for example for passwd program. passwd program from shadow suit checks uid == 0. If uid != 0 then passwd will not give you to change another's users passwords. To bypass this limitation we fake uid for this program. But don't boot with this new kernel!!! We should compile admin tools! 3. admin-tools compiling ------------------------ Uninstall all previous version of rsbac-admin, including libraries. Copy dialog-0.9b-20020814.tar.gz to /usr/src and unpack it: tar -zxf dialog-0.9b-20020814.tar.gz Copy dialog-0.9b-20020814.diff to /usr/srcdialog-0.9b-20020814. Apply patch dialog-0.9b-20020814.diff: cd /usr/src/dialog-0.9b-20020814 patch menubox.c dialog-0.9b-20020814.diff Compile/install: ./configure --prefix=/usr make make install-strip Copy rsbac-admin-1.3.0pre1.tar.bz2 to /usr/src and unpack it: tar -jxf rsbac-admin-1.3.0pre1.tar.bz2 Now cd into rsbac-admin-1.3.0pre1 compile and install into /opt/rsbac or /usr or anywhere you want): make PREFIX=/opt/rsbac make PREFIX=/opt/rsbac build make PREFIX=/opt/rsbac install-strip Add new user (for example 'secoff') with uid 400: useradd -u 400 secoff passwd secoff If you install rsbac-admin into non-standart location - include path to rsbac's bins into PATH variable and update /etc/ld.so.conf and /etc/ld.so.cache (run ldconf). Now you may add new entry into bootloader menu. I use grub, so something like this: kernel (hd0,5)/boot/kernel-2.6.15.1 rsbac_softmode root=/dev/sda6 boot Or you may type this command in grub command line. What is "rsbac_softmode"? This is kernel parameter. With it "all decisions and logging are performed, but the result that is returned to enforcement is always DO_NOT_CARE. This means that access control is effectively off!" In other words RSBAC only inform you about permissions violations, but everything working as it was. If you ommit this param, that you can't even log in, because AUTH module will restricts /bin/login (or any other process) from uid change. But Softmode will help us! Now we have kernel and admin tools and we ready to boot with RSBAC. And remember: if something will goes wrong you always may boot old non-RSBAC kernel!!! So keep the previous kernel (and know how to boot with it)!!! 4. First boot with RSBAC ------------------------ With RSBAC kernel and AUTH module enabled any process cannot change uid without permission. Even more - because we check 'Control DAC process owner (seteuid, setfsuid)' and 'Control DAC process group (setegid, setfsgid)' in kernel any process cannot change euid, fsuid, egid, fsgid. In other words - nobody (their processes) can't become someone else, for example root without permission granted. This breaks functionality of some programs which actively change their (e,fs)uids. But this protects us from rights escalation, buggy programs and intruders and so on. It is one of general protective RSBAC functions. With RSBAC in linux we have an security officer wich defines permissions. Intruder does not have way to get security officer rights, if in system no (buggy) processes runinning on behalf of security officer. So during the first boot we'll see messages about some processes try to change thier uids (request CHANGE_OWNER...NOT_GRANTED (Softmode) by AUTH). But as we in a softmode the RSBAC allows to change them. Now we'll try login as security officer. After entering password we'll see that the /bin/login changes uids to 400 (secoff id): request CHANGE_OWNER..prog_file /bin/login...NOT_GRANTED (Softmode) by AUTH request CHANGE_DAC_EFF_OWNER..prog_file /bin/login...NOT_GRANTED (Softmode) by AUTH request CHANGE_DAC_FS_OWNER..prog_file /bin/login...NOT_GRANTED (Softmode) by AUTH So first of all we should allow /bin/login to change uids to any user id. We can specify a range of allowable uids, or to specify allowable uids exactly by numbers. 5. Allow /bin/login (and other programs) to change to users ids --------------------------------------------------------------- It can be made with menu driven tools or with command line tools. I prefer bash scripts with command line tool. Commands for allow /bin/login to change to users ids will look like this: auth_set_cap -v FD add /bin/login 0 # allow setuid to root id auth_set_cap -v -e FD add /bin/login 0 # allow seteuid to root id auth_set_cap -v -f FD add /bin/login 0 # allow setfsuid to root id auth_set_cap -v FD add /bin/login 400 # allow setuid to secoff id auth_set_cap -v -e FD add /bin/login 400 # allow seteuid to secoff id auth_set_cap -v -f FD add /bin/login 400 # allow setfsuid to secoff id I don't need more users to login, so this enough. With other programs, which change uids at normal functioning, we must act in the same manner. For example, I see in boot screen) or logs): rsbac_adf_request(): request CHANGE_OWNER, pid 1034, ppid 1030, prog_name ravmd,prog_file /opt/rav/bin/ravmd, uid 0, target_type PROCESS, tid 1034,attr owner, value 0, result NOT_GRANTED (Softmode) by AUTH This is antivirus daemon process (ravmd) want to change uid (CHANGE_OWNER) to 0. So I hit command: auth_set_cap -v FD add /opt/rav/bin/ravmd 0 thus allowing to daemon change real uid to 0 (root). Or, for example, during shutdown procedure, we'll see somthing like this: rsbac_adf_request(): request CHANGE_OWNER, pid 1034, ppid 1030, prog_name shutdown,prog_file /sbin/shutdown, uid 0, target_type PROCESS, tid 1034,attr owner, value 0, result NOT_GRANTED (Softmode) by AUTH So we must hit command: auth_set_cap -v FD add /sbin/shutdown 0 to resolve this problem. And so on, until all such recognized requests (CHANGE_OWNER,CHANGE_DAC_EFF_OWNER,CHANGE_DAC_FS_OWNER) will be granted. 6. How RSBAC store their attributes ----------------------------------- All information RSBAC store in directory called /rsbac.dat Most important for us is that RSBAC store attributes of file systems objects per inode numbers, not file or directories names! For example we execute: auth_set_cap -v FD add /bin/login 0 After this RSBAC save somthing like "process executed from file with inode number 12345678 on device 08:05 may setuid to 0" in thier lists. No file names! Now, if you, for example remove 'login' file fron /bin directory, and then copy 'login' binary from backup, new 'login' file will not have the these rights. This is because of newly copied file will have new (in most cases) inode number in file system! So old record in RSBAC lists like "process executed from file with inode number 12345678 on device 08:05 may setuid to 0" is no longer valid. It's garbage. And after such manipulations we must execute auth_set_cap -v FD add /bin/login 0 again! But what about invalid lists entries? They should be forcibly deleted by periodical call of utility 'rsbac_check'. From rsbac_check man: "request the data structures to be checked for consistency. This can also reduce list sizes, because unnecessary entries and those with negative time-to-live are deleted. It is advisable to run this command regularly, e.g. once per week" Educt: remember about this RSBAC feature! And be attend! Theoretically permissions from on file can leak to another, if inode number from deleted file will be given by kernel to newly created file and record about this inode will not be deleted from RSBAC lists! 7. /etc/passwd, /etc/group, /etc/shadow, /etc/gshadow - obsolete solution!!! (recommended for studying and horizon expansion) ---------------------------------------------------------------------------- All that has been told above about inodes has the direct relation to these files. Our main goal with this files is to protect them from root (from others they are already protected by standart Linux filesystem DAC). So only security officer could manipulate these files and other (including root) only can read them. This is because first intruder's task - change user database. Problems begins when we want change this files by standart commands like useradd, userdel, usermod, groupadd and others. This programs recreate this files each time you use it. So inodes of this files change each time you add, edit or delete user or group! And in common case you cannot protect /etc by readonly permissions because some of /etc files must (or may) change during boot process (/etc/mtab,/etc/ld.so.cache). My first (and successful!) attempt was moving these files to new non-standart subdirectories under /etc. /etc/passwd, /etc/group,/etc/.pwd.lock goes under /etc/userdb and /etc/shadow, /etc/gshadow goes under /etc/shadowdb. But unfortunately you MUST have sources for Glibc, shadow, pam then RECOMPILE and REINSTALL THEM!!! In my case all is simple - I compiled all system from sources (LFS project) and have made necessary changes before compilation target system. You may downlowad src rpms for you own system, edit them and reinstall. But this not for beginners!!! I think that in gentoo it easiest to make. As a result we have passwd and shadow files under thier own subdirs and all permissions we'll establish on directories in which they are. Even in case of recreation with new inodes files will inherit permissions from directories - the problem is solved. How it can be made. We MUST deny WRITE in /etc/userdb and READ-WRITE /etc/shadowdb to all users except secoff: acl_grant -v -s USER root R FD /etc/userdb # set read-only /etc/userdb for root acl_grant -v -s USER root GET_STATUS_DATA SEARCH FD /etc/shadowdb # set dir name list only /etc/shadowdb for root acl_grant -v -s USER secoff RW FD /etc/userdb # set read-write /etc/userdb for root acl_grant -v -s USER secoff RW FD /etc/shadowdb # set read-write /etc/shadowdb for root But with this root still have access to /etc/shadowdb/ and /etc/userdb. What's wrong? Inheritance - /etc/shadowdb and /etc/userdb inherit default permissions from /etc. So we MUST disable this, for example thus: acl_mask -v -s GET_STATUS_DATA FD /etc/userdb acl_mask -v -s GET_STATUS_DATA FD /etc/shadowdb And now this work. But the secoff has no read-write access to /etc/userdb /etc/shadowdb files because of Linux DAC. We can disable Linux DAC for this dirs, grant sufficient permission to root group and include secoff and this files to root group. My solution - using CAP module! attr_set_user CAP secoff min_caps CHOWN DAC_OVERRIDE FOWNER FSETID After this secoff may ignore Linux DAC like root! Attention! CAP changes affect after logout/login. Next problem - /bin/login runs under uid 0 and with this configuration it has no access to /etc/shadowdb files. During a login you will see on the screen something similar to: rsbac_adf_request(): request SEARCH, pid 1090, ppid 1, prog_name login, prog_file /bin/login, uid 0, target_type DIR, tid Device 08:05 Inode 825 Path /etc/shadowdb, attr none, value none, result NOT_GRANTED (Softmode) by ACL rsbac_adf_request(): request READ_OPEN, pid 1090, ppid 1, prog_name login, prog_file /bin/login, uid 0, target_type FILE, tid Device 08:05 Inode 374372 Path /etc/shadowdb/shadow, attr open_flag, value 1, result NOT_GRANTED (Softmode) by ACL rsbac_adf_request(): request READ, pid 1090, ppid 1, prog_name login, prog_file /bin/login, uid 0, target_type FILE, tid Device 08:05 Inode 374372 Path /etc/shadowdb/shadow, attr none, value none, result NOT_GRANTED (Softmode) by ACL rsbac_adf_request(): request CLOSE, pid 1090, ppid 1, prog_name login, prog_file /bin/login, uid 0, target_type FILE, tid Device 08:05 Inode 374372 Path /etc/shadowdb/shadow, attr f_mode, value 4154523661, result NOT_GRANTED (Softmode) by ACL How to be in this case? We can't allow read-write access to /etc/shadowdb/shadow to uid 0. This problem can't be solved only with ACL module. From RSBAC documentation: "Access Control Lists specify, which subject (user, RC role or ACL group) may access which object (of an object type) with which requests (usual RSBAC requests and ACL specials)." In other words, PROCESSES cannot be subjects in ACL model. In ACL model we cannot tell : "THIS PROCESS MUST have read-only access to THIS FILE". Do not confuse: ACL module allow only define what USER (or ROLE or GROUP) can do with PROCESSES (or other targets), instead of what PROCESSES can do with FILES (or other targets)!!! We need RC module. From RSBAC documentation: "This model should be used whenever subjects and objects can be easily grouped into roles and types, if you need a strong separation of duty, or if you need access control based on processes, and not only on users." Key words here: "or if you need access control based on processes". | Even more precisely: we need ability of RC module to assign ROLE to PROCESSES. | And then, through a role we can control access to objects as in RC and in ACL models. | Both modules "seeing" RC roles. 7.1 /bin/login and ACL+RC module ---------------------------- Caution!!! Choose ROLES ID NUMBERS (ROLE_ID) appropriately or you may overwrite existing roles. By default up to number 3 and number 999999 roles exists. In default configuration you may start with 10 or 4. (Question to Amon: how avoid manual roles numbering?) I specially shall not put role's numbers in commands. Keep in mind: "$auth_login" it is number(ID) you select for this role. In commnads simply replace it with number. First we create ROLE with name : rc_set_item -v -a ROLE $auth_login name "auth_login" Then we set to login this role as initial role: attr_set_file_dir -v RC FILE /bin/login rc_initial_role $auth_login Why rc_initial_role ? In RC model files or dirs have "Force Role" and "Initial Role" attributes. "Force Role" specifies what role will have process at startup of the given file. And process will have this role up to the end of lifetime (or till the moment of explicit switching to other role). But our task is that each user after a login had it's own role without explicit switching. "Initial Role" - just what we need. This attribute specifies what role will have process at startup till first setuid() call. Thus login proceess will have ROLE "auth_login" till it switched to user id. After switching to user id, process will have another role which is granted to user via "Force Role" attribute. Next we grant necessary permissions. Remember - our files is protected by both ACL and RC modules and both modules overlapped each other (that in general it is redundant). But the truth is that not only files are protected. RC module protect devices, processes, users, scd's and so on. So we are simply forced to be engaged not only files but also all other types (devices, processes, scd's). All files have General_FD type by default. In commands simply raplace $General_FD,$General_Device,$rlimit,$General_Process and other variables with numbers from "Types IDs table" (see at the this file bottom). Thus for RC model I simply grant all rights by next commands: ## for FD rc_set_item -v ROLE $auth_login type_comp_fd $General_FD A ## for DEV rc_set_item -v ROLE $auth_login type_comp_dev $General_Device RW ## for SCD rc_set_item -v ROLE $auth_login type_comp_scd $rlimit MODIFY_SYSTEM_DATA ## for Process rc_set_item -v ROLE $auth_login type_comp_process $General_Process GET_STATUS_DATA Certainly, it is desirable to limit permissions of role more precisely. As I make the main emphasis on the ACL module it is not necessary. Besides so uneasily to find out to what objects program need what access. (Question to Amon: how to simplify this?) And more "worse": we need to think up new RC FD (types for files) and assign these types to appropriate files. In ACL model we may do this with more straightforward way (without creating intermediate TYPES). By ACL model we restrict access up to necessary: acl_grant -v -s ROLE $auth_login R CHANGE_OWNER MODIFY_PERMISSIONS_DATA FD /dev acl_grant -v -s ROLE $auth_login R FD /etc/shadowdb acl_grant -v -s ROLE $auth_login R EXECUTE MAP_EXEC FD /lib acl_grant -v -s ROLE $auth_login RW FD /var acl_grant -v -s ROLE $auth_login RW FD /var/log/lastlog acl_grant -v -s ROLE $auth_login SEARCH FD /var/log acl_grant -v -s ROLE $auth_login W FILE /var/log/wtmp acl_grant -v -s ROLE $auth_login APPEND_OPEN FILE /var/log/btmp It is more convenient to make a file with role's and type's IDs assigned to variables and use this variables in commands or scripts. (Question to Amon: whether it is possible to specify role's and type's names instead of ID's in commands?) 7.2 Changing passwords only by security officer ----------------------------------------------- Next problem is changing user's passwords. Now root can't do this. Only the security officer should change passwords to all users. But passwd check uid and ordinary user can change only his(her) password. You should have uid = 0 to change other users passwords. To solve this we use 'Faked root uid' feature: attr_set_fd GEN FILE fake_root_uid 3 /usr/bin/passwd Caution!!! Now anybody who have read and execute rights to /usr/bin/passwd can change any password!!! Keep /usr/bin/passwd far away from all except security officer. Or better you may copy this file to secoff home and setup fake_root_uid on it: cp /usr/bin/passwd /home/secoff/bin attr_set_fd GEN FILE fake_root_uid 3 /home/secoff/bin/passwd So all other users will continue to use "normal" passwd. And secoff will use his "faked" variant of passwd. And keep out root from /home/secoff !!! With user database we almost got over. Now you may reboot without rsbac_softomode and check that everything work. But exist more suitable and secure way to solve /etc/passwd problems. It is... 8. RSBAC User Management - better way -------------------------------------- Since version 1.2.4 "User Management" exist. It (must) solve many problems with "Traditional Linux user management subsystem". With it, all these tricks from clause 7 no longer necessary - all occurs in kernelspace. Read this http://rsbac.org/documentation/different_models/um for details. First of all, after booting RSBAC-enabled kernel, we need to import users and groups into RSBAC: rsbac_useradd -v -O # import all users from /etc/passwd rsbac_usergroup -v -O # import all groups from /etc/group Next replace in /etc/nsswitch.conf: passwd: compat group: compat shadow: compat (or what you have) to passwd: rsbac group: rsbac shadow: rsbac Next set new passwords for all imported users (and groups if necessary) (use -n option for that the old password was not asked): rsbac_passwd -n root rsbac_passwd -n secoff and so on... At passwords changing you will see something similar to: rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 1108, ppid 1101, prog_name rsbac_passwd, prog_file /opt/rsbac/bin/rsbac_passwd, uid 400, target_type SCD, tid mlock, attr none, value none, result NOT_GRANTED (Softmode) by RC It is the rsbac_passwd tries to block a memory with password you enter. We'll allow do it to ROLE "Role_Admin" (see "Role's IDs table" at file bottom): rc_set_item -v ROLE $Role_Admin type_comp_scd $mlock MODIFY_SYSTEM_DATA Next, replace standart /bin/login with rsbac version. Backup original /bin/login and reaplace /bin/login with rsbac version: cp /usr/bin/rsbac_login /bin/login Try to login in another console - you'll see "login:" and "RSBAC password:". After login you'll see: request CHANGE_OWNER, pid 1083, ppid 1, prog_name login, prog_file /bin/login, uid 0, target_type PROCESS, tid 1083, attr owner, value 0, result NOT_GRANTED (Softmode) by AUTH For this we execute: attr_set_file_dir -v AUTH FILE /bin/login auth_may_setuid 3 Now, when, for example I run mc I see: rsbac_adf_request(): request READ, pid 1115, ppid 1083, prog_name mc, prog_file /usr/bin/mc, uid 0, target_type GROUP, tid 0, attr none, value none, result NOT_GRANTED (Softmode) by RC ACL I.e. root and System_Admin ROLE does not have access to Linux groups. For this grant it to root and System_Admin: acl_grant -v USER root READ GROUP :DEFAULT: rc_set_item -v -a ROLE $System_Admin type_comp_group $General_Group READ That's all (for now). I'll use this variant as the main. 9. /dev/mem and /dev/kmem devilry --------------------------------- From "Linux on-the-fly kernel patching without LKM" ("Phrack" magazine Volume 0x0b, Issue 0x3a, Phile #0x07 of 0x0e, http://www.phrack.org/archives/phrack58.tar.gz): "Imagine a scenario of a poor man which needs to change some interesting linux syscall and LKM support is not compiled in. Imagine he have got a box, he got root but the admin is so paranoid and he (or tripwire) don't poor man's patched sshd and that box have not gcc/lib/.h needed for compiling of his favourite LKM rootkit. So there are some solutions, step by step and as an appendix, a full-featured linux-ia32 rootkit, an example/tool, which implements all the techinques described here."... "Mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.".... "Since this device is mostly +rw only for root, you must be root too if you want to abuse it. Note that changing of /dev/kmem permission to gain access is not sufficient. After /dev/kmem access is allowed by VFS then there is second check in device/char/mem.c for capable(CAP_SYS_RAWIO) of process." Thus, intruder can change a running kernel even if you have compiled it without "Loadable module support". And... wow! In default RSBAC configuration nobody has access to memory except secoff. This is done through the SCD object "kmem". RC roles by default has no access to kmem. secoff has access to ACL SCD:DEFAULT:, but has no CAP_SYS_RAWIO capability. Summary: we have nothing to do with this ! Period. 10. Protecting files against undesirable changes/removals. ---------------------------------------------------------- Now we start the most bulk part of job. Our main procedure is DENY root's WRITE access to ACL FD :DEFAULT: (i.e. "root" for all filesystem objects from which all rights are inherited). secoff has SUPERVISOR right to ACL FD :DEFAULT: by default. It means that secoff has full access to all objects - that's ok. For all other users (builtin GROUP "Everyone") we DENY access to ACL FD :DEFAULT: FULLY! Then we grant only necessary rights for all users and used programs. For programs we'll use suitable ROLES and grant necessary ACL rights to ROLES. We'll grant RC rights not so precisely. You can download my (simple)policy example concerning to this document: http://sftf.narod.ru/rsbac_policy.tar.bz2 So all explanations for policy you may get from document you read now. Policy should be applied to an default RSBAC configuration. For very short instruction read "setup" file. Besides you'll find ID's values of many builtin TYPES and ROLES. To be continued... --END----------------------------------------------------------------------------------------- Type's IDs table -------------------------------------- ### FD Types General_FD=0 Security_FD=1 System_FD=2 ### DEV Types General_Device=0 Security_Device=1 System_Device=2 ### Process Types General_Process=0 Security_Proc=1 System_Process=2 Kernel_Process=999999 ### SCD Types time_strucs=0 clock=1 host_id=2 net_id=3 ioports=4 rlimit=5 swap=6 syslog=7 rsbac=8 rsbac_log=9 other=10 kmem=11 network=12 firewall=13 priority=14 sysfs=15 rsbac_remote_lo=16 quota=17 sysctl=18 nfsd=19 ksyms=20 mlock=21 capabaility=22 repl_partner=23 kexec=24 auth_administra=32 ### NETDEV Types General_NETDEV=0 Security_NETDEV=1 System_NETDEV=2 ### NETOBJ Types General_NETOBJ=0 Security_NETOBJ=1 System_NETOBJ=2 Role's IDs table ---------------- # built-in General_User=0 Role_Admin=1 System_Admin=2 Auditor=3 # auth_login=10