Messages in this thread | | | Date | Sun, 11 Apr 1999 09:48:49 +1000 | From | Richard Gooch <> | Subject | Re: [PATCH] Capabilities, this time in elf section |
| |
Horst von Brand writes: > "David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said: > > On Sat, 10 Apr 1999, Daniel Taylor wrote: > > [...] > > > > If a binary requires a capability to run to do its job > > > then it either needs to be run by a user that has that > > > capability or it needs to be SUID to a user that does. > > > No, the uid only supplies rights in the file system as currently; i.e.,= > if > > the process runs 'setuid jschmoe', it has the ability to muck about wit= > h > > files owned by 'jschmoe'. If jschmoe has the capability for setting > > capabilities (and some others), he can create 'setuid jschmoe' binaries > > with caps that are a subset of the caps he _currently_ holds.=20 > > Problem is that jschmoe can take a hex editor to any file she wants, > and make it "ALL CAPS" and then SUID it, or just wait for somebody > capable to run it. Even if she hasn't got the "set capability" > cap. That's why capabilities can not reside in the executable file > itself. But if they ar= e
No, because capabilities can only be granted by the sysadmin (root). Therefore capability-granting binaries are suid-root and the kernel looks at the ELF CAP header.
Suid-non-root binaries are different: they switch identity. The kernel doesn't check the ELF CAP header.
If some ordinary user wants to create a binary that grants capabilities *to others*, he must ask the sysadmin for permission. If the sysadmin agrees, he runs a tool to edit/audit the ELF CAP header and then chowns to root and chmod u+s.
Regards,
Richard....
- 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/
| |