Malte Gell wrote:

older SUSEn had a secumod kernel module that allowed some nice security enhancements, e.g. I liked (needed...) prohibiting a user from running programs within his home directory (or any other directory) a lot. There is no such tool / module for SUSE 10.x, right? Can newer AppArmor versions do such things (I still use SUSE 10.0 and AA 1.2)?

Follow the confined-shell procedure described below, and it will allow you to control the set of programs a user can run in great detail. For instance, you could grant permission in the confined shell profile for "/bin/* ix" and "/usr/bin/* ix" which would give the user access to a lot of programs, but not allow them to execute commands out of their own home directory. Caveat: "execute" is a slippery concept. AppArmor will control what files you can access with the exec() system call, but a determined user can open any file they have read access to, and copy the bytes into an arbitrary chunk of memory and then jump to them. Just be aware that controls on what a user can *execute* (as distinct from what they can *read*) are modest, at best. This is true of AppArmor and most other access control systems. Crispin ---- Confined Shell Procedure: AppArmor can be used to create "roles" (in the RBAC sense) that operate as restricted shells in Linux. This even works on root shells. For instance, suppose you have some junior system administrators in your enterprise, and their job is to do system log analysis looking for problems. They need root access to do this, but you don't feel comfortable trusting them; they might be evil, or they might just make mistakes. So you want to allow them to only have *part* of root's privilege to access the system log, but *not* the power to mess with the Oracle database, reboot the machine, etc. To do this, you create a role using AppArmor. You do this by: 1. Creating a "special" shell for tis role, e.g. call it logbash for the role of syslog analyst. 2. Create an AppArmor profile for logbash that restricts anyone running logbash to only do the necessary operations. 3. Make logbash be the default login shell for people who will be operating in this role. 4. Change the UID of these people to 0 so that they have root's privilege, but use their own password and are restricted to run logbash, so you don't have to share root's password. An example: To create the profile: 1. become root 2. cd /bin 3. ln bash logbash * This creates the special shell as a hard link. AppArmor treats hard links with different names as being different programs, even though this is just bash. 4. cd /tmp * a good working directory to train the policy for logbash, grants access to noting important 5. In another root shell say "genprof logbash", or using the AppArmor YaST interface "add a profile wizard" create a profile for logbash 6. back in our first window, run logbash as root 7. exercise logbash doing things that a syslog analyst might need to do: 1. Search syslog: grep FAILED /var/log/messages 2. Copy to temporary: cp /var/log/messages /tmp 3. Edit copy: vi /tmp/messages * make some changes and save it 4. exit this shell 8. In the genprof shell or the YaST window, Scan the log to translate these events into policy * When it asks you "Inherit" or "Profile", choose "Inherit" for *everything*. * Grant most access requests. * When offered #includes for bash and usr-tmp, use them * *Deny* accesses to /root and children; you don't want the junior sysadmin to have access to the root account home directory * Finish profile generation To demonstrate the profile: 1. From any root shell, run logbash 2. You get a root shell prompt, but it is a confined root shell. You can try any command you like, but it will only allow you to do the things trained above. 1. Things that work: 1. Search syslog: grep FAILED /var/log/messages 2. Copy to temporary: cp /var/log/messages /tmp 3. Edit copy: vi /tmp/messages * make some changes and save it 2. Things that don't: 1. Edit the system copy of /var/log/messages; you can open it in vi, but you cannot write it back 2. delete your copy of /tmp/messages 3. *Do not exit* from this shell. Just leave it running for now ... 3. Learning from mistakes: you can re-run the AA log analyzer to correct REJECTs that you meant to allow 1. In an alternate (non-confined) root shell run "logprof" or in the YaST AppArmor control window click "Update Profile Wizard" 1. It works just like initially building a profile, except that for REJECT events it recommends "Deny" as the default action. 2. Deny all events, except *allow* the request to run rm 4. Now try again 1. *Without* having to re-start the logbash shell session above, AppArmor has just adjusted policy out from under it. 2. Try 'rm /tmp/messages' again, and it should work. 3. Now try 'rm -rf /' and it will *not* work. It will not harm the machine. 4. Ask the customer to try to hurt the machine from the logbash shell. They can't. In the above demo, I never actually created a new account for this role. You can demo that if you like, but it takes more time and is unnecessary. *Caveat:* YaST prior to SLES10 is not able to deal with multiple duplicate user-IDs, so giving some guy a uid of 0 will cause YaST user management to fail. However, coming soon in SLES10, SLED10, SL10.1, etc. is a YaST enhancement that works with multiple duplicate user IDs. Sudo: this is somewhat like sudo, but much better: * policy is much easier to build: it learns from watching * it can control what files can be affected: o if you grant sudo root access to rm, then it allows the user to remove *any* file o the AppArmor profile lets them rm only the files your policy says -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hacking is exploiting the gap between "intent" and "implementation" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org