On 2015-11-17 14:30, Al Viro wrote:
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.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.
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).
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.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".
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
