linux-kernel - Re: BUG: Securityfs and bind mounts (2.6.34)

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]

Date:	Wed, 14 Jul 2010 17:19:46 +0100
From:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
To:	Greg KH <greg@...ah.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: BUG: Securityfs and bind mounts (2.6.34)

On Thursday 08 Jul 2010 16:46:48 Greg KH wrote:
> On Thu, Jul 08, 2010 at 04:32:42PM +0100, Tvrtko Ursulin wrote:
> > On Thursday 08 Jul 2010 16:20:59 Greg KH wrote:
> > > > :) Well I do not know, but, it kind of smelled like a bug in the
> > > > : vfs/mount
> > > >
> > > > handling/securityfs area so I thought to let experts know. I _think_
> > > > I did nothing that much wrong. Just used the exposed API
> > > > (securityfs_remove) and some bind mount shuffling from userspace.
> > >
> > > securitfs just uses libfs underneath it, and really doesn't have any
> > > bindings for module ownerships, so I wouldn't recommend doing what you
> > > just did.
> >
> > Just do double check what you are saying, securityfs is not safe for use
> > from modules? If so I would then recommend removing the exports otherwise
> > it is an invitation to shoot yourself into the foot.
>
> Hm, did you properly set the module owner of the file_operations that
> you passed to securityfs?  That should protect if you have an open file,
> but I doubt anyone thought you would do crazy things like bind mounts on
> top of a ramfs and then think it was safe to unload a lower module :)

Hi again,

Here is the reproducer. Build the attached test module and put test.ko in the
cwd. Then run:

umount /sys/kernel/security
mount none -t securityfs /sys/kernel/security/
insmod test.ko
mount file --bind /sys/kernel/security/test/file
rmmod test
insmod test.ko
umount /sys/kernel/security/test/file
umount /sys/kernel/security # <-------- BANG:

It is a bit different than what I initially said. It looks like reference
counting on a dentry gets messed up once securityfs_create_dir() in second
insmod of test.ko fails with -EEXIST.

HTH,

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

View attachment "test.c" of type "text/x-csrc" (969 bytes)