Mailinglist Archive: opensuse-security (49 mails)

< Previous Next >
Re: [opensuse-security] secumod like solution for SUSE 10.x?
  • From: Crispin Cowan <crispin@xxxxxxxxxx>
  • Date: Sun, 10 Dec 2006 15:58:39 -0800
  • Message-id: <457C9F2F.4070808@xxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-security+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References