On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:Perhaps the SELinux model should be extended to handle (dir-inode, path-entry) pairs. For example, if I want to protect the /etc/ shadow file regardless of what tool is used to safely modify it, I would set
Some of us think that the tools can protect /etc/shadow just fine on their own, and are concerned with rogue software that abuses / etc/shadow without bothering to safely modify it..
o Protect the "/" and "/etc" directory inodes as usual under SELinux
(with attributes on directory inodes).
o Create pairs with (etc_inode,"shadow") and (etc_inode,"gshadow")
and apply security attributes to those potentially nonexistent pairs.
*bzzt* wrong. Why should "gshadow" matter? (Think carefully about what happens when a setUID program gets exploited and used to scribble on /etc/shadow - black hats rarely bother to do locking and other such niceties....)
I'm not terribly familiar with the exact internal semantics of SELinux, but that should provide a 90% solution (it fixes bind mounts and namespaces).
90% doesn't give the security guys warm-and-fuzzies....
The remaining 2 issues are hardlinks and fd-passing. For hardlinks you don't care about other links to that data, you're concerned with protecting a particular filesystem location, not particular contents, so you just need to prevent _new_ hardlinks to a protected (dir_inode, path_elem) pair, which doesn't seem very hard.
It's not. include/linux/security.h:
* @inode_link:
* Check permission before creating a new hard link to a file.
* @old_dentry contains the dentry structure for an existing link to the file.
* @dir contains the inode structure of the parent directory of the new link.
* @new_dentry contains the dentry structure for the new link.
* Return 0 if permission is granted.
For fd-passing, I don't know what to do. Perhaps nothing.
include/linux/security.h:
* @file_receive:
* This hook allows security modules to control the ability of a process
* to receive an open file descriptor via socket IPC.
* @file contains the file structure being received.
* Return 0 if permission is granted.
Already a solved problem.