Messages in this thread |  | | Date | Thu, 27 Jan 2011 08:02:55 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH] System Wide Capability Bounding Set |
| |
Quoting Eric Paris (eparis@redhat.com): > At this point it seems to me like what I must do is add a way for a task > with enough priv to force caps out of the bset and pI of the kthread > which upcalls to run userspace programs. Thus when the kthread runs a > program it cannot give those privs....
Exactly, that's what I was envisioning.
How about adding an optional kthread-wrapper program which, when specified on the boot cmdline, will be the program to wrap any userspace programs which the kernel executes? Then that program can do the work it needs to remove capabilities from pI and X, set selinux context, etc. Just a thought, seems somewhat more elegant thatn hard-coding the behavior in the kernel, but not sure it's practical.
> Does this seem reasonable? What would such an interface look like? > (This is scarily like the old meaning of CAP_SETPCAP....)
I'm not sure it's unreasonable, but in one sense it seems like just walking one more step toward the end of the plank: next, you're going to have to worry about a kernel-spawned thread, from which you've denied cap_sys_module, writing to /boot/initrd* the malicious steps it wanted to take, to be executed at next boot when it still has cap_sys_module. (Fine, enter TPM :)
What is the attack vector you're actually envisioning? Does some trojan come in and overwrite a program which which it hopes the kernel will execute? Or is there just an existing vuln in such a program? Are there other ways we can address these? Can we find a way to classify the kernel-spawned userspace programs? Perhaps based on the selinux context assigned to the program, we can assign some level of trust that noone could have modified the source?
-serge
|  |