linux-kernel - Re: [PATCH 2/2] RFC: selinux: sysctl: fix selinux labeling broken by last patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Jan 2011 16:14:33 +0200
From:	Lucian Adrian Grijincu <lucian.grijincu@...il.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@....de>,
	Dave Chinner <dchinner@...hat.com>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	selinux <selinux@...ho.nsa.gov>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 2/2] RFC: selinux: sysctl: fix selinux labeling broken by
 last patch

On Mon, Jan 31, 2011 at 3:59 PM, Stephen Smalley <sds@...ho.nsa.gov> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/