Re: [PATCH v3 0/7] User namespace mount updates

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-bcache@vger.kernel.org, dm-devel@redhat.com,
	linux-raid@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH v3 0/7] User namespace mount updates
Date: Tue, 17 Nov 2015 15:39:16 -0500	[thread overview]
Message-ID: <564B9074.5030305@gmail.com> (raw)
In-Reply-To: <20151117193012.GX22011@ZenIV.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]

On 2015-11-17 14:30, Al Viro wrote:
> On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
>
>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>> To properly protect against attacks on mounted filesystems, we'd
>> need some new concept of a userspace immutable file (that is, one
>> where nobody can write to it except the kernel, and only the kernel
>> can change it between regular access and this new state), and then
>> have the kernel set an image (or block device) to this state when a
>> filesystem is mounted from it (this introduces all kinds of other
>> issues too however, for example stuff that allows an online fsck on
>> the device will stop working, as will many un-deletion tools).
>>
>> The only other option would be to force the FS to cache all metadata
>> in memory, and validate between the cache and what's on disk on
>> every access, which is not realistic for any real world system.
>
> Doctor, it hurt when I do it...
>
> IOW, the other option is to refuse attempting this insanity.  Fuse probably
> can be handled, but being able to mount (with kernel-space drivera) an
> arbitrary ext4 image is equivalent to being able to do anything and it's
> going to stay that way for the forseeable future.  You are talking about
> a large pile of code that deals with rather convoluted data structure,
> had not been written with validation in mind *and* keeps being developed.
> What's more, that code runs with maximal priveleges there are.
Without factoring in unprivileged mounts, for cases when mounting from a 
block device, you shouldn't have to worry about a malicious third party, 
because their ability to modify it under the filesystem implies that 
they either already have root privileges, or they have direct access to 
hardware, and in both cases, your system is already compromised to a 
degree that makes the reliability of your filesystem irrelevant.  Under 
the same circumstances with filesystem images, the same statement applies.

However, while unprivileged mounts make validation more important, there 
is still the fact that if you don't trust someone, then you shouldn't be 
letting them have access to your system.  No amount of sandboxing short 
of full isolation can solve that, period.  Yes people will try to crack 
the system, but no matter how much sandboxing there is, it will not be 
unbreakable unless nobody can access it.

The attack surface is already there, it's just hard to get to.  There's 
a reason I never mount anything I didn't create myself and can't prove 
chain of custody on without at least running fsck on it first, and then 
only mount it with the kernel if there isn't a FUSE driver for it that I 
trust (and GRUB provides a lot of those).
>
> This is absolutely insane, no matter how much LSM snake oil you slatter on
> the whole thing.  All of a sudden you are exposing a huge attack surface
> in the place where it would hurt most and as the consolation we are offered
> basically "Ted is willing to fix holes when they are found".
For the context of static image attacks, anything that's found _needs_ 
to be fixed regardless, and unless you can find some way to actually 
prevent attacks on mounted filesystems that doesn't involve a complete 
re-write of the filesystem drivers, then there's not much we can do 
about it.  Yes, unprivileged mounts expose an attack surface, but so 
does userspace access to the network stack, and so do a lot of other 
features that are considered essential in a modern general purpose 
operating system.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]