I retract my previous position. You are probably correct. This somewhat
flys in the face of the traditional UNIX model of having all
protection-related information in the inode but the benefits may outweigh
that.
Some food for thought:
1. When selecting a method to encode the capabilities into the ELF binary,
it should be a high priority to select something so that the information
can easily be retrived, preferably by file(1).
2. How bad is it that we're limited to ELF? Is it important to allow
things like capability-enhanced perl scripts, for instance.
set[ug]id perl scripts are fairly common now.
3. Remember that unlike ext2-level checks there will be no way for the
kernel to prevent the owner of the file from changing its capabilities.
Obviously it would refuse to honor them for non-suid-root files but
what about protecting from root? This works against the division-of-root
concept of capabilities. I'm not familiar enough with the eventual
direction of the capabilities stuff and how it will interface with
the traditional uid=0 to say whether this is bad or not. Make sure
that there aren't any security implications with allowing uid=0 to
implicitly set any capability on any binary, regardless of what
capabilities are currently in effect.
I think this idea needs some hashing out, but I now see that it has some good
potential.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu