[...]
> 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/