Re: HEAD'S UP: fusefs sysctls going away

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