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." -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
