Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 19, 2006, at 02:56:28, [email protected] wrote:
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..

Here I'm talking about using SELinux to protect /etc/shadow both before _and_ after it's edited with vipw. A tool like vipw does creat () write() rename() to overwrite the /etc/shadow file, so any SELinux system relying _only_ on inode is guaranteed to break. In any case, the point here is to provide 2 clean semantics for protecting files: inodes and directory entries; They have entirely different use- cases. For an inode all you need is (<inode>), for a directory entry you need (<dir-inode>, <path-component>). The latter would only be used when referencing the file by name, if you already have a filehandle it would not be used.

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....)

/etc/gshadow matters because it's the group shadow file, no? If you're going to bother protecting the user shadow file, you should protect the group shadow file too.

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....

True, but that's why I address the following 2 items below:

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.

I _think_ SELinux provides a way to hook this, but I'm not entirely sure. If not, it should be added, but I suspect it does.

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.

Likewise, this should be solved with inode-based security if it's a problem. The use-case I'm addressing (legitimate use of /etc/shadow with vipw) doesn't care about that. For example, if I want to only allow vipw access to /etc/shadow, then associating that policy with the /etc/shadow inode is useless, because the first rogue program would just remove and rewrite /etc/shadow, getting a different inode. What I need to do is protect the "shadow" entry in the dentry for ("/etc") in the particular namespace I care about, right?

Cheers,
Kyle Moffett



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux