Messages in this thread | | | Subject | Re: [PATCH] Capabilities, this time in elf section | Date | Sun, 11 Apr 1999 09:53:23 -0400 | From | Horst von Brand <> |
| |
Richard Gooch <rgooch@atnf.csiro.au> said: > Horst von Brand writes:
[...]
> 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.
There is no "root" in a capability based system...
> Suid-non-root binaries are different: they switch identity. The kernel > doesn't check the ELF CAP header.
What happens then to poor user whose UID is 0 by accident?
> 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.
This whole idea is way too complicated, IMHO. Capabilities are essentially refinements of the S[UG]ID bits for executables, and should be handled in a similar way. Sure, that screws tools that don't know about them. But you will need new tools anyway (see above). And the new tools have to be carefully designed, built and audited if the whole concept is to make any sense at all. This includes the kernel mechanisms to enforce the restrictions set out. Better if they are _simple_, there is exactly _one_ way of representing caps (i.e., either in the file (unsatisfactory, IMO) or in metadata for a capability-aware filesystem).
If you use a capability enhanced filesystem, you have a reasonable upgrade path: For now, SUID root is as today even with caps set. You can mount the filesystem with either caps, suid, sgid, or any combination enabled. If caps isn't there, some new executables that aren't SUID root break horribly since they haven't got the capabilities to do their jobs, but that is to be expected (and can be fixed making them SUID root for now). Old stuff works fine via S[UG]ID. After replacing the old SUID root affected binaries (a very few!) you get rid of the special meaning of root, and everything is fine again. Taking tar(1), cp(1) or such to the files is inocuous, as capabilities aren't being smuggled around (compare to "cp /bin/login ~").
Please do not screw up the capability handling forever for the sake of a temporary partial relief! Linux is characterized by doing things the _right_ way, even if it hurts.
What is needed for starters:
- fsck(8): Needs to be modified/rewritten anyway - dump/restore: Write from scratch anyway - mount(8): Needs modification anyway (shouldn't be hard) - setcap(8): Needs to be written anyway - ls(1), or lscap(1): Has to be done each way - find(1) needs to be capability-aware
Anything essential missing here? -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- 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/
| |