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: <m1sjig1xrp.fsf@fess.ebiederm.org>
Date:	Sat, 11 Feb 2012 20:27:54 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	Andy Whitcroft <apw@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Hansen <haveblue@...ibm.com>,
	linux-security-module@...r.kernel.org,
	Linux Containers <containers@...ts.osdl.org>,
	St?phane Graber <stgraber@...ntu.com>,
	Daniel Lezcano <daniel.lezcano@...e.fr>
Subject: Re: prevent containers from turning host filesystem readonly

"Serge E. Hallyn" <serge@...lyn.com> writes:

>> Serge let me respectfully suggest that getting the user namespace done
>> will deal with this issue nicely.
>> 
>> In the simple case you simply won't be root so remount will just be
>> denied.
>> 
>> When/if we allow a limited form of unprivileged mounts in a user
>> namespace your user won't have mounted the filesystem so you should not
>> have the privilege to call remount on the filesystem.
>
> Hm, that's a good point.  Though note it'll require the userns code to
> distinguish between the a bind remount and superblock remount.  The
> last time we seriously discussed this, that wasn't even on the roadmap.
> It was only going to support fully assigning the whole filesystem to
> a user namespace.  In that case, the remount issue doesn't apply anyway
> as the fs isn't shared with another container.

Come to think of it unmounting and remounting is a bit tricky, and
it is a bit parallel to having a disk base filesystem being in one
user namespace.  Currently my patches have the rule that everything
maps to the initial user namespace, so using a filesystem from multiple
user namespaces is not a problem.

Unmounting is pretty safe if the rule is that you control the entire
mount namespace.

Remounting though that does become tricky in the unprivileged situation.
I honestly haven't thought through what that permission check should
look like yet.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ