Environment
Novell SUSE Linux Enterprise
Server 9
Novell SUSE Linux Enterprise Server 10
Novell Open Enterprise Server (Linux based)
Novell SUSE Linux Enterprise Server 10
Novell Open Enterprise Server (Linux based)
Situation
Motivation
AppArmor can be used to create "roles" (in theRole Based Access Control 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 todo system log analysis looking for problems. They need root access to do this, but you don't feel comfortable trusting them; they might beevil, 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 notthe power to mess with the database, reboot the machine, etc.
AppArmor can be used to create "roles" (in theRole Based Access Control 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 todo system log analysis looking for problems. They need root access to do this, but you don't feel comfortable trusting them; they might beevil, 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 notthe power to mess with the database, reboot the machine, etc.
Resolution
Outline
To do this, you create a role using AppArmor with the following steps:
(Caveat: Concerning the last point, YaST prior to SLES10 is not able to deal with multiple duplicate user-IDs, so using duplicate uids willcause YaST user management to fail. However, coming soon in SLES10, SLED10, SL10.1, etc. is a YaST enhancement that works withmultiple duplicate user IDs. )
Creating The Profile
To create the profile:
Testing The Profile
To test the profile from the root shell:
To do this, you create a role using AppArmor with the following steps:
- Creating a "special" shell for this role, e.g. call it logbash for the role of syslog analyst.
- Create an AppArmor profile for logbash that restricts anyone running logbash to only do the necessary operations.
- Make logbash be the default login shell for people who will be operating in this role.
- 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.
(Caveat: Concerning the last point, YaST prior to SLES10 is not able to deal with multiple duplicate user-IDs, so using duplicate uids willcause YaST user management to fail. However, coming soon in SLES10, SLED10, SL10.1, etc. is a YaST enhancement that works withmultiple duplicate user IDs. )
Creating The Profile
To create the profile:
- Become root
- cd /bin
- 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.
- cd /tmp
a good working directory to train the policy for logbash, grants access to nothing important - In another root shell type genprof logbash, or use the AppArmor YaST module (Novell AppArmor>"Add a profile wizard" ) to create a profile for logbash
- back in our first window, run logbash as root
- exercise logbash doing things that
a syslog analyst might need to do:
â— Search syslog: grep FAILED /var/log/messages
â— Copy to temporary: cp /var/log/messages /tmp
â— Edit copy: vi /tmp/messages (make some changes and save it)
â— exit this shell - 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 -- it makes the proces faster, and does no harm for demos
â— 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
Testing The Profile
To test the profile from the root shell:
- From any root shell, run logbash
- 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.
â— Things that work:â—‹ Search syslog: grep FAILED /var/log/messagesâ—‹ Copy to temporary: cp /var/log/messages /tmpâ—‹ Edit copy: vi /tmp/messages; make some changes and save itâ— Things that don't work:â—‹ Edit the system copy of /var/log/messages; you can open it in vi, but you cannot write it backâ—‹ delete your copy of /tmp/messagesâ— Do not exit from this shell. Just leave it running for now ... - Learning from mistakes: you can re-run the AA log analyzer to
correct REJECTs that you meant to allow
â— In an alternate (non-confined) root shell run "logprof" or in the YaST AppArmor control window click "Update Profile Wizard"
â— It works just like initially building a profile, except that for REJECT events it recommends "Deny" as the default action.
â— Deny all events, except allow the request to run rm - Now try again
â— Without having to re-start the logbash shell session above, AppArmor has just adjusted policy out from under it.
â— Try rm /tmp/messages again, and it should work.
â— Note: try this next step only if you are SURE that you have done the above profiling correctly!!!â—‹ Now try rm -rf / (remove all the files in your root directory) and it will not work. It will not harm the machine.â— Experiment. - Last, you can try by logging from the user setup with the logbash shell.
Additional Information
Contrast with
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
On the other hand, if you grant sudo root access to rm, then it allows the user to remove any file
â— the AppArmor profile lets them rm only the files your policy says
This is based on a document written by Crispin Cowan.
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
On the other hand, if you grant sudo root access to rm, then it allows the user to remove any file
â— the AppArmor profile lets them rm only the files your policy says
This is based on a document written by Crispin Cowan.