Re: Need some security advice for systemtap

[David Smith <dsmith@redhat.com>]

David Smith wrote:
> Thanks for the response.  See stuff below.
> 
> Pavel Kankovsky wrote:
>> On Mon, 4 Jun 2007, David Smith wrote:
>>
>>> One of the complaints we get from users is that we require root access
>>> (using sudo) to install/remove the kernel module.  Large enterprise
>>> customers typically don't give out sudo access to all admins.  So, they
>>> would like a way to designate certain scripts/modules as "blessed", and
>>> allow admins/developers/etc. without root access to run those "blessed"
>>> scripts/modules.
>>
>> The easiest way to designate a certain script as "blessed" (and quite
>> difficult to goof it up) is to let a trusted user take the source of the
>> script, check it, make a kernel module, and install it into a designated
>> directory on the target system (or systems), perhaps under
>> "/lib/modules/$version".
> 
> That's my current thinking.  Seems easier from a user's point of view 
> and less fragile from a security point of view.
> 
>> If you are afraid of allowing "untrusted admins" run "sudo modprobe
>> the_probe" (but not afraid of allowing to run your own setuid root
>> program) you can create something like "sustaprun" that will make it
>> possible to load blessed modules (from the designated directory) only.
> 
> That's also my current thinking.  I'm trying to prototype this now.

After playing around with this a bit, here are my thoughts/plans.  We've 
basically got 2 problems:

(1) we want _certain_ non-privileged users
(2) to be able to run _certain_ compiled scripts

Solving both problems would look like this:

(A) A sysadmin would compile systemtap tap scripts into kernel modules 
and store the module in something like 
/etc/systemtap/authorized_modules/$kernel_version/foo.ko

(B) The sysadmin would add anyone needing to be able to run those 
modules to the new 'systemtap' group.

(C) We'll have a new program, staprun.auth, which would be owned by 
root, group systemtap, and file permission would be 04110.  Here's what 
a 'ls -l' would look like on it:

---s--x--- 1 root systemtap {size} {date} /usr/bin/staprun.auth

This would mean that only people in the systemtap group could run 
staprun.auth and it would give them root privileges.  staprun.auth would 
have similar arguments as staprun (more on that in a sec).  staprun.auth 
would make sure the module is coming from 
/etc/systemtap/authorized_modules/$kernel_version and then just exec 
staprun.

(D) staprun.auth will need to disallow certain staprun.auth command-line 
arguments, such as:

- "-c CMD" (Command CMD will be run and the staprun program will exit 
when CMD does).  We can't allow this since CMD would be run as root 
("staprun.auth -c xterm module" would be a quick way to a root shell).

- "-O FILE" (Send output to FILE).  Since FILE gets created as root, 
that could be used by an user seeking to overwrite a file he couldn't 
normally.


 From a users point of view, it would look something like this:

(as root, installing a new module)
# stap -k -p4 -m stap_foo foo.stp
Keeping temporary directory "/tmp/stapygupi1"
# cp /tmp/stapygupil/stap_foo.ko 
/etc/systemtap/authorized_modules/`uname -r`/stap_foo.ko

(as non-root user, running the new module)
$ groups
users systemtap
(ah, good, this user is in the 'systemtap' group, which means he should 
be able to run staprun.auth)
$ staprun.auth stap_foo.ko
(staprun.auth will make sure /etc/systemtap/authorized_modules/`uname 
-r`/stap_foo.ko exists, then exec staprun with that module)

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)