Re: HEAD'S UP: fusefs sysctls going away

On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
wrote:

>
> W dniu 06.04.2019 o 15:39, Alan Somers pisze:
> > On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta <
> > zarychtam_at_plan-b.pwste.edu.pl> wrote:
> >
> >> W dniu 21.03.2019 o 17:03, Alan Somers pisze:
> >>> 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).
> >> After recent changes in fusefs code I am getting such panics regularly
> >> on amd64:
> >>
> >>
> >> Fatal trap 12: page fault while in kernel mode
> >> cpuid = 3; apic id = 03
> >> fault virtual address    = 0x248
> >> fault code        = supervisor read data  , page not present
> >> instruction pointer    = 0x20:0xffffffff82d6250c
> >> stack pointer            = 0x28:0xfffffe005dc2c630
> >> frame pointer            = 0x28:0xfffffe005dc2c7b0
> >> code segment        = base 0x0, limit 0xfffff, type 0x1b
> >>             = DPL 0, pres 1, long 1, def32 0, gran 1
> >> processor eflags    = interrupt enabled, resume, IOPL = 0
> >> current process        = 2016 (mount_fusefs)
> >> trap number        = 12
> >> panic: page fault
> >> cpuid = 3
> >> time = 1554528396
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >> 0xfffffe005dc2c2e0
> >> vpanic() at vpanic+0x19d/frame 0xfffffe005dc2c330
> >> panic() at panic+0x43/frame 0xfffffe005dc2c390
> >> trap_fatal() at trap_fatal+0x394/frame 0xfffffe005dc2c3f0
> >> trap_pfault() at trap_pfault+0x49/frame 0xfffffe005dc2c450
> >> trap() at trap+0x29f/frame 0xfffffe005dc2c560
> >> calltrap() at calltrap+0x8/frame 0xfffffe005dc2c560
> >> --- trap 0xc, rip = 0xffffffff82d6250c, rsp = 0xfffffe005dc2c630, rbp =
> >> 0xfffffe005dc2c7b0 ---
> >> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfffffe005dc2c7b0
> >> vfs_domount() at vfs_domount+0xace/frame 0xfffffe005dc2c9e0
> >> vfs_donmount() at vfs_donmount+0x934/frame 0xfffffe005dc2ca80
> >> sys_nmount() at sys_nmount+0x69/frame 0xfffffe005dc2cac0
> >> amd64_syscall() at amd64_syscall+0x36e/frame 0xfffffe005dc2cbf0
> >> fast_syscall_common() at fast_syscall_common+0x101/frame
> 0xfffffe005dc2cbf0
> >> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp =
> >> 0x7fffffffe128, rbp = 0x7fffffffe730 ---
> >> KDB: enter: panic
> >>
> >> Last time I have checked it happened on FreeBSD 13.0-CURRENT #21
> >> r345948: Fri Apr  5 17:12:53 CEST 2019.
> >>
> >> As a workaround loading fusefs.ko and fuse.ko modules can be disabled.
> >>
> >> --
> >> Marek Zarychta
> > Thanks for the bug report.  This is probably fixed by r345419 (which
> hasn't
> > been merged to head yet).  If so, then it indicates that your fuse daemon
> > is doing something wrong.  What fuse file system are you trying to use,
> and
> > what command are you using to start it?
> > -Alan
>
> XFCE4 desktop environment seems to be the culprit of the whole anxiety.
> It has installed fusefs-libs-2.9.9 as a dependency. I get these panics
> during the XFCE session startup. Furthermore, I haven't any fusefs
> packages installed beside mentioned fusefs-libs.
>
> --
>
> Marek Zarychta


Then the culprit is probably /usr/local/libexec/gvfsd-fuse.  But on my
XFCE4 system, that command never runs.  I don't know why not.  Try this
patch:
https://reviews.freebsd.org/D19836

-Alan