Re: Selinux going crazy in 2.6.34-rc0

[Eric Paris]

On Sat, Mar 6, 2010 at 12:41 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/