Re: [PATCH] System Wide Capability Bounding Set

[Serge E. Hallyn]

Quoting Eric Paris (eparis@xxxxxxxxxx):
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/