Messages in this thread | | | From | (Peter Benie) | Subject | Re: Capabilities | Date | Fri, 11 Feb 2000 00:56:23 +0000 |
| |
Chris Evans writes ("Re: Capabilities"): > On Thu, 10 Feb 2000, Peter Benie wrote: > > I haven't really figured out what the bounding set is for. It doesn't > > seem to do anything that couldn't be done trivially by using wrappers > > in inittab to remove capabilities from the inheritable set a la Irix. > > I think the inheritance mask is applied _before_ any forced capabilities > on a binary take effect. So you need a system wide catch-all so you can be > confident about your bounding set without having to trawl the disk.
Okay. Establishing a least upper bound for the cap_bound is hard so I suspect that in practice this will be left as the full set on many systems.
> > And I'm puzzled by the capabilities given to init. Why doesn't init > > run with all capabilites? cap_setpcap is a subset of cap_sys_admin > > (because of mknod and /dev/kmem) so I see no point in not making > > setpcap inheritable from init. > > I believe that's to discourage use of cap_setpcap rather than it being > perceived as "too powerful".
I've just taken another look at what it does and now I understand why he thinks that. It falls into roughly the same category as cap_sys_ptrace - it allows you to cross a boundary between different processes, even when those processes have different privileges (by virtue of having running under different uids or by being chrooted to different directories).
It's the kind of thing you want to give to the system administrator (when they login interactively as root), but you don't want to give to any system program. That's okay - whenever you start a system program, you need to throw away unused capabities, otherwise the program has full access to the system anyway.
On the grounds of orthogonality, is the any chance of having the kernel start init with all+eip, and make it init's responsibility to throw away undesirable capabilities? This moves policy from kernel- to user-space, and it removes the special case code for init in exec.c:compute_creds. If init then reads a configuration file for the default capabilities, you will have no policy set in stone.
> Andrew Morgan had some strong reasons for this, I'll see if I can > dig them out of my mail bucket.
Thanks - I'd appreciate that.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |