On Mon, 2011-01-31 at 16:14 +0200, Lucian Adrian Grijincu wrote: > On Mon, Jan 31, 2011 at 3:59 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > - Don't remove the IS_PRIVATE() test from inode_has_perm(), as other > > inodes beyond just the /proc/sys ones are marked with that flag > > (original usage was for reiserfs xattr inodes). > > > Are you sure? I believe it was added here: > > [PATCH] selinux: enhance selinux to always ignore private inodes > > Hmmm...turns out to not be quite enough, as the /proc/sys inodes > aren't truly > private to the fs, so we can run into them in a variety of security hooks > beyond just the inode hooks, such as security_file_permission (when reading > and writing them via the vfs helpers), security_sb_mount (when > mounting other > filesystems on directories in proc like binfmt_misc), and deeper within the > security module itself (as in flush_unauthorized_files upon > inheritance across > execve). So I think we have to add an IS_PRIVATE() guard within SELinux, as > below. Note however that the use of the private flag here could > be confusing, > as these inodes are _not_ private to the fs, are exposed to userspace, and > security modules must implement the sysctl hook to get any access > control over > them. > > > http://thread.gmane.org/gmane.comp.security.selinux/341/focus=519 > > > In my patch I don't care about IS_PRIVATE, because I don't mark proc > inodes as PRIVATE any more. > > > This patch added S_ISPRIVATE to proc inodes: > [PATCH] sysctl: hide the sysctl proc inodes from selinux > 86a71dbd3e81e8870d0f0e56b87875f57e58222b > > This one added the IS_PRIVATE check: > [PATCH] selinux: enhance selinux to always ignore private inodes > bbaca6c2e7ef0f663bc31be4dad7cf530f6c4962 > > > I'll remove the check from my patch if you say it's used in other > places too, but the original usage does not seem to be "for reiserfs > xattr inodes". Ok, my mistake - you can leave that part alone. The original usage of the S_PRIVATE flag was for reiserfs xattr inodes, but it appears that you are correct that we don't need the IS_PRIVATE() guard within the selinux code for that use case. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.