Messages in this thread | | | Date | Fri, 9 Apr 1999 13:54:54 -0500 (CDT) | From | Dan Taylor <> | Subject | Re: [PATCH] Capabilities, this time in elf section |
| |
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/
| |