Messages in this thread | | | Date | Sat, 10 Apr 1999 16:25:02 -0500 (CDT) | From | Daniel Taylor <> | Subject | Re: [PATCH] Capabilities, this time in elf section |
| |
You need capabilities directly tied to the UID or you cannot securely eliminate root from the system. Whether program capabilities (which HAVE to be a subset of the capabilities of the owner) exist in the executable or the filesystem does not change this. One of the capabilities in question is the ability to override UID/permission protections on files.
*** The possibility of creating a binary that posseses a capability that the owner does not is one definition of a security hole. ***
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.
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.
A restricted user may have one or both of those capabilities turned off.
A power/admin user may have additional capabilities, for example:
- chown a file not owned by themselves - run a file that they do not have explicit permission to run, - perform other file operations where there is not explicit permission, - open a TCP socket below 1024, - assign another user the ability to use capabilities that the assigning user has permission for, - mount/unmount filesystems
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.
- 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/
| |