linux-kernel - Re: Selinux going crazy in 2.6.34-rc0

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] [day] [month] [year] [list]

Message-ID: <7e0fb38c1003071725t5b19d6bbtbedb46afd1d816f2@mail.gmail.com>
Date:	Sun, 7 Mar 2010 20:25:40 -0500
From:	Eric Paris <eparis@...isplace.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>, sds@...ho.nsa.gov,
	davidel@...ilserver.org
Subject: Re: Selinux going crazy in 2.6.34-rc0

On Sat, Mar 6, 2010 at 12:41 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Sat, Mar 06, 2010 at 09:27:27AM -0800, Dmitry Torokhov wrote:
>
>> > Interesting...  That smells like a selinux policy that needed recognition
>> > of inotify file descriptors and got b0rken by
>> > commit c44dcc56d2b5c79ba3063d20f76e5347e2e418f6
>> > that switched inotify to use of anon_inodes.  Could you check if that's the
>> > trigger?
>>
>> Yep, that was it. With this commit reverted selinux stays quiet.
>> Well, almost, it is never completely quiet ;).
>>
>> Thank you Al.
>
> Hrm...  Folks, does anybody have suggestions on what to do about that one?
> I can revert that thing, of course, but I wonder what's really going on
> in the policy that triggers that spew...

That is certainly an interesting little thing I never thought about
and I'm both an SELinux and inotify maintainer so no surprise noone
else thought about it either!  SELinux defines rules which label
different filesystem types with different default labels such as an
nfs filesystem would be nfs_t and an tmpfs would be tmpfs_t.  Inotify
was using it's own filesystem an applications which used inotify got
rules like so:

   allow policykit_t inotifyfs_t : dir { ioctl read getattr lock
search open } ;

Now that we switch inotify to use generic anon inode code rather than
duplicate creating it's own filesystem type for a single inode we
screwed up those rule types.  I'm trying to thing of a good solution
and the only two things come to mind:

a) revert the change and any others that switches things to anon
inodes from their own private fs (were there others?)
b) allow multiple anonymous inodes with differing security contexts,
possibly one inode per anon inodefs "class" would be sufficient to
allow for fine grained security controls over anon inode subsystems?
I haven't looked closely, but that seems like a reasonable trade off
between fine grained security and memory usage....

-Eric
--
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/