Messages in this thread | | | Date | Fri, 9 Apr 1999 12:42:27 -0700 (PDT) | From | Jonathan Walther <> | Subject | Re: [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/
| |