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@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
