>>> 1. Put capabilities information in the executable header.
>>> 2. Mark the executable setuid root.
>>> 3. Have the kernel check for #1 if #2, and prefer #1 if present.
> Actually, that's not the worst of the problem. If the capabilities
> information is in the executable header, then it can be edited by the
> owner of the file. This is *not* a good thing --- think of capabilities
> as some of the various privileges of root split into separate
> privileges. For example, the right to open a port below 1024, the right
> to bypass filesystem access control checks, etc. The ability to edit
> capabilities *must* be reserved to the kernel, and by putting it into
> the executable header, it's subject to be edited by anyone with write
> access to the file.
Assuming you don't allow world-writable setuid executables...
Who can edit the file? root
What runs as root? nothing at all
Remember, this is supposed to be a system with capabilities.
Linux already lets you have a setup that makes root a normal user.
You don't login as root. You log in as an admin with specific privs.
If you like, require the immutable bit. (but you lose NFS then)
With capabilities in the filesystem, they are subject to being edited
by anyone with write access to the block device. Same "problem" there.
Question for any opponents: Do you plan to hack some non-standard
extension to NFS, tar, cpio, etc.? Do you expect your solution to
work on only one type of filesystem, and do you think that is OK?
How will you make backups?
I'm not at all opposed to _needed_ incompatible extensions.
Filesystem support just isn't needed though, and it could be
added later if I am seriously wrong. It is better to try the
simple and compatible method first.
-
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/