Re: Need some security advice for systemtap

[Pavel Kankovsky <peak at argo dot troja dot mff dot cuni dot cz>]

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".

This is similar to keeping a list of allowed hashes as proposed on
Bugzilla but simpler. You need the compiled code to compute the hash
anyway.

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.

You might also exploit module autoloading (something like adding "alias
binfmt-1234 the_probe" to modprobe.conf and making an attempt to execute a
file starting with 1234) but it would make it difficult to grant different
users the ability to load different sets of modules and to remove modules.


On Tue, 5 Jun 2007, grundy wrote:

> I think a good way to handle it would be to have a configuration file
> like /etc/sudoers and setuid root stap (or staprun). The access control
> would then be built into systemtap. 

It is an attractive idea but I am afraid it will turn out to be a sort of
conceptual minefield when you start working on it.

> Here are my ideas of what would make a "good" set of controls:
> 
>  - level of tap script they can run, e.g. guru mode code or not

Guru mode means the ability to run arbitrary C code in the kernel space.
It is easier to give them the root password.

>  - sections of the kernel they can access (maybe this is
>    better represented as what tapsets may they use)

I think the history has taught us it is much better to express policy
rules in the terms of elementary operations than in the terms of
procedures, modules or whole programs. The latter choice turns the
procedures etc. into trusted components--correct enforcement of policy
relies on their correct behaviour, and this is a very bad thing.

Unfortunately, any block of embedded C code is a black box (and it 
has to power to turn anything in its vicinity into black boxes).

One reasonable approach might be to form a group of trusted tapsets
allowed to use embedded C code (and perhaps other kinds of privileged
operations) even without guru mode. They would form a kind of "TCB". The
policy would provide a set of trusted tapsets (and perhaps additional
restrictions) and the script and any untrusted tapsets it uses would have
to obey it.

>  - how much overhead are they allowed to put on the system

This is not a property of an individual script. A million of tiny 
lightweight scripts can kill the system as well as (and perhaps even 
better than) a single heavyweight script.

>  - are they allowed to look at data for other user's processes

You'd have to deal with the fact that many useful predefined functions
(kernel_string() just to name one example) appear to take arbitrary
numbers, interpret them as pointers, and fetch a value at that address,
making it possible to read all kernel memory.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."