David Smith <dsmith@xxxxxxxxxx> writes:
> [...]
> 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
The suggestion of using /lib/modules itself is a great one.
> (B) The sysadmin would add anyone needing to be able to run those
> modules to the new 'systemtap' group.
Good idea.
> (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
OK.
> [...]
> (D) staprun.auth will need to disallow certain staprun.auth
> command-line arguments, such as:
> - "-c CMD" [...]
> - "-O FILE" [...]
Actually, it doesn't. A setuid program can drop its privileges after
performing the root-only operations (module loading), and invoke the
rest of the normal commands as the real userid.
> [...]
> $ 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)
> [...]
It would be better to have staprun.auth perform the module loading and
setup parts of current staprun, and defer the unprivileged work to
ordinary staprun.
Now, if only we could automate the sudo vs. setuid mechanisms...
Maybe even SYSTEMTAP_DIR=/lib/modules/`uname -r`/systemtap?
- FChE
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
