lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Capabilities, this time in elf section

I think we need to be able to set capabilities on a per user and per
executable basis. This should not be hard: Simply `and' the capabilities
masks of the user and the program they're trying to execute. I personally
favor setting capabilities in the filesystem, but that they only are useful
on files set executable.

For instance, a user might have the capability set that allows him to access
graphics memory. But he might not want a particular program that he runs to
have that same capability.

Jonathan Walther
Digital Video Broadcasting Systems
http://216.100.231.12 (requires netscape)


On Fri, 9 Apr 1999, Dan Taylor wrote:

> We need to have per-user capabilities, "root" would be the
> ability to set these capabilities.
>
> If a program is SUID to a particular user, it _may_ have
> any capabilities assigned to that user. By having the capabilities
> defined in an ELF header you can run a non-SUID program whose
> capabilities do not exceed your own, or a SUID program which
> functions fully within its own capability.
>
> The capabilities could _also_ be defined from the filesystem.
>
> But all of the filesystem or executable capability code in the
> world means _NOTHING_ if root is the only user with capabilities
> beyond what an ordinary user has now, since any executable with
> expanded capabilities must then be SUID root.
>
> Of course this also allows for the creation of _less_ priviledged
> users that do not have filesystem write permissions or have restricted
> execution priviledges.
>
> This is also why we need to leave the SUID bit alone.
>
> John mentioned in the other thread that this data could be stored in
> /etc/passwd, there may be better ways to do it but that would work.
>
> Dan Taylor
> On Fri, 9 Apr 1999, Ingo Molnar wrote:
>
> >
> > On Fri, 9 Apr 1999, Ernest JW ter Kuile wrote:
> >
> > > > being able to set the setuid root bit is [should be?] a capability itself,
> > > > root does not ...
> > >
> > > no it isn't !
> > >
> > > that bit isn't a setuid *root* bit at all if the owner of the file isn't
> > > root.
> > > anybody should still be able to set that bit if he want. the capability
> > > you mean is the chown/grp capability.
> >
> > yes, this is what i ment by:
> >
> > > > This breaks symmetry a little bit but i dont think it's a problem.)
> >
> > > *don't* change the meaning of the setuid bit please.
> >
> > i dont think this is a problem. In the future setuid root will no more
> > have it's old meaning. So i can see no problem with changing _some_ of the
> > semantics. At some point there will be no extra rights attached to uid 0.
> >
> > > you can however remove root if there is somwhere a database of personal
> > > capabilities per user (ala passwd, shadow, etc...), then by setting
> > > setuid to
> > > any user, a binary could get a subset (or all) of *that* users
> > > capabilities and no more.
> >
> > i never said that setuid _nonroot_ should change. We obviously need it for
> > things like mail delivery, it's a feature. What i proposed was to handle
> > setuid root (and only setuid root) slightly differently. [since setuid
> > root is exactly the thing we want to redesign/replace by capabilities] Do
> > you see my point?
> >
> > -- mingo
> >
> >
> > -
> > 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/
> >
>
>
> -
> 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/
>



-
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:51    [W:0.030 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site