> Least astonishment in this case would mean that the binary has the
> capabilities available to its EUID. In the case of a SUID binary
> the EUID is the UID of the owner of the binary.
No, that's the _old_ school, where root can do anything and normal users
can do nothing (without the help of setuid binaries). Albert was
absolutely correct on this; in a capabilities-based system, uid and
capabilites are orthogonal. At login you may have caps raised depending
on 'getty' and 'login', but there is no _permanent_ mapping of
capabilities to uid that the kernel is aware of. (unlike the current
notion of setuid root)
> This is the reason for SUID binaries.
We're changing the notion of 'setuid root' for a capability-enhanced
definition. In a capabilities-based system, the old meaning of setuid
root doesn't apply; so we now use it in a nicely compatible way.
> Non-SUID binaries get their EUID from the UID of the user
> running the binary. So they can only have capabilities that
> are available to that user.
That will still be true! If I run a non-SUID binary, but I _do_ have some
caps raised, the kernel will still check the 'permitted' cap set from the
headers and 'AND' it with our current caps.
> 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 with
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.
> SUID binaries should _still_ be rare, but since they
> will not all be SUID-root the potential security
> risk will be reduced.
Agreed.
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/