HEAD'S UP: fusefs sysctls going away

[Shawn Webb]

On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote:
> On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> >
> > Hey Alan,
> >
> > Thank you very much for your work in maintaining fusefs. I only use
> > fusefs in very limited circumstances, so take what I'm about to say
> > with a grain of salt.
> >
> > On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote:
> > > fusefs has several sysctl knobs that seem to be workarounds for bugs
> > > in particular fuse daemons.  However, there is no indication as to
> > > which those daemons are, neither in the code nor in SVN.  All of the
> > > workarounds are at least 6.5 years old, so the original bugs may have
> > > been fixed already.  Since the original bugs aren't documented, I
> > > consider these workarounds to be unmaintainable, and I'm planning to
> > > delete them unless anybody objects.  Please pipe up if you still use
> > > them!
> > >
> > > vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also
> > > non-zero, enable mmap(2) of FUSE files
> >
> > I'm curious if the security impacts of removing the toggle to disable
> > mmap support for fusefs. Is there a per-fusefs replacement for
> > mmap_enable? From a security perspective, it would be nice to keep the
> > ability to disable mapping of files mounted on a fusefs.
> 
> As a matter of fact, there are three other ways to disable mmap:
> 1) Set vfs.fusefs.data_cache_mode=0.  This completely disables caching
> file data, which precludes mmap.
> 2) Use the undocumented -o no_datacache mount option, which does the
> same thing on a per-mount basis.
> 3) Use the undocumented -o no_mmap mount option, which disables mmap
> on a per-mount basis.

Awesome! I wasn't aware of these. Thanks!

> 
> Are you aware of any general security problems with using mmap?
> Anything that would apply to fusefs but not other filesystems?

Primarily because I trust the filesystems natively implemented in my
OS more than I trust some (potentially random) fusefs module.

For example, if I'm in a shared hosting environment, implemented with
jails, and I let the customer mount a fusefs module in the jail (which
is now possible, if I remember right), then I must trust that the
module's mmap integration is properly implemented. I'm not sure I
personally am okay with that level of trust.

However, the point is moot now that you documented the three ways to
disable mmap (two of which work on a per-mount basis).

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20190321/ad52c510/attachment.sig>