Re: [PATCH 2/2] RFC: selinux: sysctl: fix selinux labeling broken bylast patch

[Lucian Adrian Grijincu]

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

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