> You need capabilities directly tied to the UID or you cannot
> securely eliminate root from the system.
No, being "tied to the UID" is most of the problem that capabilities
are designed to solve! If you tie capabilities to an admin account,
then you might as well call that account "root" and just forget about
all this screwing around.
> Whether program
> capabilities (which HAVE to be a subset of the capabilities
> of the owner)
Program capabilities could be greater (granted by an admin), as long
as the user is blocked from editing them.
> ***
> The possibility of creating a binary that
> posseses a capability that the owner does not
> is one definition of a security hole.
> ***
Duh. Don't even worry about that. Nobody would be that stupid.
> Any given user is going to have a set of "standard capabilities".
>
> - create and modify files owned by the user in directories owned by
> the user.
> - run binaries that the user/group permissions allow them to run.
These are not currently considered capabilities. That would require
starting normal users with capabilities by default.
> An ordinary user is _NOT_ going to be able to set any capabilities
> on binaries they create other than those. However, they _may_ create
> a binary that has one or both of those capabilities turned off.
Yes, but an admin user may add capabilities to a user's executable.
> A power/admin user may have additional capabilities, for example:
...
> And others.
>
> Many (all?) of these capabilities are currently part of "root", and
> are only usable by root or SUID-root programs. For capabilities
> to work properly they still need to be tied directly to a user or
> you still need root to own and control all binaries that have capabilities
> beyond what an ordinary user may do.
Mostly true...
Users can "ask" root to manage an executable.
The admin could grant extended privs on a setuid-foo executable,
even beyond what user foo would normally have.
The kernel can not tell what privs a user should have. That info is
stored in a file somewhere in /etc, /rsbac, or /tcb. (the kernel does
not read your /etc/passwd or /etc/group files either)
-
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/