lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Capabilities
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.175 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site