linux-kernel - Re: unprivileged mounts git tree

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]

Message-ID: <m1od2r1l4p.fsf@frodo.ebiederm.org>
Date:	Sat, 13 Sep 2008 20:06:46 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	hch@...radead.org, viro@...IV.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: unprivileged mounts git tree

"Serge E. Hallyn" <serue@...ibm.com> writes:

>> > So in order for me as an unprivileged user to pin a dentry by mounting
>> > over it, I have to have write permission to the dentry to begin with
>> > as well as the dentry being under a user=hallyn mount.
>> 
>> That second condition is interesting requiring write permission of the
>> dentry.  I thought we had obviated the need for that when we added
>> ownership to the mounts themselves.  In this case at least it shouldn't
>> it be write permission on the directory containing the dentry.
>
> Oh no, it seems I'm wrong, that's not a condition.  Just tested it.

Ok.  I couldn't find Mikolos's code when I looked quickly.
What are the current rules?  It sounds like my original example could apply.

>> This seems to mess up things like revoke.
>
> Hey, do we have revoke now?  :)

Periodically someone works on revoke ;)

>> At a practical level it is a real annoyance, regardless of the security
>> implications.
>> 
>> As a point of comparison plan9 does not have that restriction.
>
> Why doesn't it have that restriction?  

I haven't heard the reason.

> Does it always allow you to rm a mounted-over file?

Yes.

The implementation of mounts in plan9 is a bit different.  In
plan9 mounts are looked up by mount namespace and qid (effectively
the inode number).  So the semantics are slightly different.
Requiring a new mount namespace if you want to see what a filesystem
looks like without a mount on top of a given file.

It also looks like plan9 is likely to have a unmountable and unusable mount
if you actually delete an file, from another mount namespace.

Linux actually has a very similar case where we can loose a mount if you rename
the directory that contains it to be somewhere higher in the mount hierarchy
than the location the mount was under.

All of that said there is a very good practical justification for it all.
In a filesystem where not all changes come through our local VFS the
VFS cannot prevent changes to a filesystem it can only cache and respond
to changes that do occur.

So things like sysfs_rename_dir and sysfs_move_dir routinely bypass
the VFS restriction against changes happening under mount points.  It
isn't a problem in practice because people don't mount on sysfs but the
problem is very much there today.

It looks to me like the right solution is very much to do the lazy
unmount we do for expired mounts, and purge everything that happens
and then we just don't have to worry about mounts causing a denial
of service attack and life gets simpler.

Rename is a bit trickier than unlink and rmdir in that we should allow
it on the underlying filesystem and only remove the directory if the
rename goes out of scope for the overlying mount.

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/