Re: HEAD'S UP: fusefs sysctls going away

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