linux-kernel - Re: prevent containers from turning host filesystem readonly

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]

Date:	Sat, 11 Feb 2012 11:07:46 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Serge Hallyn <serge.hallyn@...onical.com>
Cc:	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 Hallyn <serge.hallyn@...onical.com> writes:

> Quoting Al Viro (viro@...IV.linux.org.uk):
>> On Fri, Feb 10, 2012 at 09:19:39PM -0600, Serge Hallyn wrote:
>> > When a container shuts down, it likes to do 'mount -o remount,ro /'.
>> > That sets the superblock's readonly flag, not the mount's.  So unless
>> > the mount action fails for some reason (i.e. a file is held open on
>> > the fs), if the container's rootfs is just a directory on the host's
>> > fs, the host fs will be marked readonly.
>> > 
>> > Thanks to Dave Hansen for pointing out how simple the fix can be.  If
>> > the devices cgroup denies the mounting task write access to the
>> > underlying superblock (as it usually does when the container's root fs
>> > is on a block device shared with the host), then it do_remount_sb should
>> > deny the right to change mount flags as well.
>> > 
>> > This patch adds that check.
>> > 
>> > Note that another possibility would be to have the LSM step in.  We
>> > can't catch this (as is) at the LSM level because security_remount_sb
>> > doesn't get the mount flags, so we can't distinguish
>> > 	mount -o remount,ro
>> > from
>> > 	mount --bind -o remount,ro.
>> > Sending the flags to that hook would probably be a good idea in addition
>> > to this patch, but I haven't done it here.
>> 
>> NAK.  This is just plain wrong - what about the filesystems that are not
>
> BTW, sorry - the patch clearly should've taken non-bdevs into account, but
> I accept that wouldn't have been enough to evade a NAK.
>
>> bdev-backed or, as e.g. btrfs, sit on more than one device?
>
> btrfs is actually one of my main motivators - to quickly snapshot containers
> with btrfs means that the containers all share one fs, but that means one
> container can mark them all ro.

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.

I think I will have a set of patches ready for serious scrutiny in
the next week or so.  So we aren't talking impossible pie in the sky
distance to see this happen.

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/