linux-kernel - Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)

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: <E1JT0ME-0003rT-9N@pomaz-ex.szeredi.hu>
Date:	Sat, 23 Feb 2008 20:48:26 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@...IV.linux.org.uk
CC:	miklos@...redi.hu, hch@...radead.org, akpm@...ux-foundation.org,
	serue@...ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, haveblue@...ibm.com
Subject: Re: [patch 00/10] mount ownership and unprivileged mount syscall (v8)

> On Sat, Feb 23, 2008 at 06:33:13PM +0100, Miklos Szeredi wrote:
> > > 	c) just what is limited by that sysctl?  AFAICS, rbind is allowed
> > > if mountpoint is on user vfsmount and it seems to create vfsmounts without
> > > eating into that limit just fine...  What's the point of limiting the
> > > amount of vfsmounts marked user when you do not limit the number of vfsmount
> > > one can allocate?
> > 
> > The limit is there, so that unprivileged users cannot create insane
> > number of mounts.  It's just a safety thing, analogous to
> > /proc/sys/fs/file-max.
> 
> Can't they?  Looks like one can create any number of vfsmounts without
> getting more than one marked MNT_USER...

permit_mount() will set MS_SETUSER in flags, and do_loopback() will
set CL_SETUSER based on that flag.

> If you are trying to limit the number of superblocks (i.e. active instances
> of filesystems), then I'd say that vfsmounts make piss-poor proxies for
> those and it would be better to count the objects you really want to count...

I think I really want to limit vfsmounts.  But not because these take
so much memory or anything, just to be safe against a stupid users
playing rbind and propagation, and things like that.

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