Messages in this thread | | | Date | Sat, 16 Sep 2006 00:52:13 +0200 | From | David Madore <> | Subject | Re: capabilities patch: trying a more "consensual" approach |
| |
Hi, Linux and LSM experts,
I would like to request some advice on how best to create an LSM for creating underprivileged processes in a way that will seem acceptable also to those Linux users and kernel hackers who don't want to hear about it (i.e., my patch should not mess more than necessary with the rest of the kernel).
In a nutshell, the goal is to do this: when the module is loaded, each task should have a "cuppabilities" variable, which is initially blank and, when certain bits are added to it (or removed, depending on your point of view), prevents certain system calls from succeeding. This variable should be inherited across fork() and exec(), and some interface should be provided to add more cuppabilities (i.e., make a process less-than-normally privileged).
Now, if I understand correctly, the various alloc_security() LSM hooks do not stack well: if I want my module to be stackable after SElinux (and I do), I can't hook task_alloc_security() to create my variable, so I need to store these "cuppabilities" in a globally visible task field. Do I understand correctly? How acceptable is this? (We can assume that 32 bits will be wide enough, so I'm not talking about adding huge amounts of data to the task struct.)
Second, what would be the cleanest and most acceptable way to provide an interface to these new "cuppabilities"? For example, should I add a new, dedicated, system call? If so, should I provide new hooks to it in struct security_operations? Or is, perhaps, prctl() a better path (then I would have to request a hook on that in SElinux)? How can I best avoid breaking causing any disruption to the rest of the kernel?
Any advice is welcome.
Happy hacking,
-- David A. Madore (david.madore@ens.fr, http://www.madore.org/~david/ ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |