Re: [PATCH v6 00/22] Support ext4 on NV-DIMMs

[Florian Weimer]

On 02/27/2014 05:29 PM, Matthew Wilcox wrote:

> > Some distributions use udisks2 to grant permission to local console
> > users to create new loop devices from files.  File systems on these
> > block devices are then mounted.  This is a replacement for several
> > file systems implemented in user space, and for the users, this is a
> > good thing because the in-kernel implementations are generally of
> > higher quality.
>
> Just to be sure I understand; the user owns the file (so can change any
> bit in it at will), and the loop device is used to present that file
> to the filesystem as a block device to be mounted?

Yes, that's a fair summary.

> Have we fuzz-tested
> all the filesystems enough to be sure that's safe?  :-)

It raised some eyebrows.  But I've looked at some of the userspace 
alternatives, and I can see why we ended up with this.

> > What happens if we have DAX support in the entire stack, and an
> > enterprising user mounts a file system?  Will she be able to fuzz
> > the file system or binfmt loaders concurrently, changing the bits
> > while they are being read?
> >
> > Currently, it appears that the loop device duplicates pages in the
> > page cache, so this does not seem to be possible, but DAX support
> > might change this.
>
> I haven't looked at adding DAX support to the loop device, although
> that would make sense.  At the moment, neither ext2 nor ext4 (our only
> DAX-supporting filesystems) use DAX for their metadata, only for user
> data.  As far as fuzzing the binfmt loaders ... are these filesystems not
> forced to be at least nosuid?

The kernel binfmt parser runs as root even without a SUID bit. :)

> I might go so far as to make them noexec.

Oh, that's an interesting idea.

> Thanks for thinking about this.  I didn't know allowing users to mount
> files they owned was something distros actually did.  Have we considered
> prohibiting the user from modifying the file while it's mounted, eg
> forcing its permissions to 0 or pretending it's immutable?

Perhaps like "Text file busy" for executables?  How reliable is that in 
practice?

Changing file permissions doesn't affected already open descriptors and 
might not always be possible (the file system might be mounted 
read-only, but still be modifiable beneath).

--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/