lkml.org 
[lkml]   [2015]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 0/7] User namespace mount updates
From
Date
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.

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-11-17 22:01    [W:0.427 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site