On Fri, May 18, 2018 at 10:51 AM, Dmitry Bogatov <kact...@gnu.org> wrote:
> Package: fuse
> Version: 2.9.7-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Is there any security or other concerns about enabling `user_allow_other'
> in /etc/fuse.conf by default?

There are security concerns with this.   For details see
Documentation/filesystems/fuse.txt in the linux kernel tree.  The
following paragraphs are relevant:

 B) If another user is accessing files or directories in the
    filesystem, the filesystem daemon serving requests can record the
    exact sequence and timing of operations performed.  This
    information is otherwise inaccessible to the mount owner, so this
    counts as an information leak.

    The solution to this problem will be presented in point 2) of C).

 C) There are several ways in which the mount owner can induce
    undesired behavior in other users' processes, such as:

     1) mounting a filesystem over a file or directory which the mount
        owner could otherwise not be able to modify (or could only
        make limited modifications).

        This is solved in fusermount, by checking the access
        permissions on the mountpoint and only allowing the mount if
        the mount owner can do unlimited modification (has write
        access to the mountpoint, and mountpoint is not a "sticky"
        directory)

     2) Even if 1) is solved the mount owner can change the behavior
        of other users' processes.

         i) It can slow down or indefinitely delay the execution of a
           filesystem operation creating a DoS against the user or the
           whole system.  For example a suid application locking a
           system file, and then accessing a file on the mount owner's
           filesystem could be stopped, and thus causing the system
           file to be locked forever.

         ii) It can present files or directories of unlimited length, or
           directory structures of unlimited depth, possibly causing a
           system process to eat up diskspace, memory or other
           resources, again causing DoS.

[...]

If a sysadmin trusts the users enough, or can ensure through other
measures, that system processes will never enter non-privileged
mounts, it can relax the last limitation with a "user_allow_other"
config option.  If this config option is set, the mounting user can
add the "allow_other" mount option which disables the check for other
users' processes.

Thanks,
Miklos

Reply via email to