Re: HEAD'S UP: fusefs sysctls going away

On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb <shawn.webb_at_hardenedbsd.org> wrote:
>
> 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.

Ah, well you needn't worry about that.  mmap is handled entirely
within the kernel.  The userland fusefs module only sees writes and
reads.  From userland's perspective, the only real difference is that
mmap()ed writes don't identify the pid of the originating process,
whereas direct writes do (except when vfs.fusefs.data_cache_mode==2).

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