Re: [PATCH v5] fuse: Add support for passthrough read/write

[Jann Horn <jann@thejh.net>]

[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]

On Wed, Feb 03, 2016 at 11:05:57AM -0800, Nikhilesh Reddy wrote:
> Hi
> Thanks for your review again :)
> >
> >Uh... how do you know at this point that the file is actually writable?
> >Normally, e.g. vfs_write() will ensure that the file is writable, and
> >e.g. generic_file_write_iter() won't check for writability as far as I
> >can tell. This might allow someone to use the passthrough mechanism to
> >overwrite a file he is only allowed to read, but not write, like
> >/etc/passwd.
> 
> I considered adding the checks ( the same ones that VFS does)  but not sure
> if we need to.
> So the user will need to construct a fuse filesystem ( that opens for
> O_READONLY even though the user asks for a O_RDWR from the FUSE open) and
> then mount it , with CAP_SYS_ADMIN  for which you need to be root but  once
> he has that he should be able to easily get to the files without needing to
> go through FUSE  right using CAP_DAC_OVERRIDE?
> 
> Am i missing something? Please do help me understand.
> 
> But yes if really needed I can add additional checks once i understand it

On most Linux desktop systems, and on many servers, the userland "fuse"
package is installed, which ships with a setuid root helper "fusermount":

$ ls -l /bin/fusermount
-rwsr-xr-x 1 root root 30800 May 21  2015 /bin/fusermount

This setuid helper allows any user to mount FUSE filesystems anywhere he
wants. This works as follows: main() calls mount_fuse(), which opens
/dev/fuse by calling open_fuse_device(). mount_fuse() then makes sure
that the caller has write access to the directory he is about to mount
over using check_perm(), then calls mount() via do_mount(). mount_fuse()
returns the /dev/fuse fd, which is then sent to the invoker of fusermount
through a unix domain socket.

(What the setuid binary does control are the mount options; those are
used to enforce that the user can't mount filesystems that are
accessible for other users.)

Note that at no point, any data is sent to or read from the FUSE control
fd by fusermount. Therefore, the init reply that is processed in
process_init_reply() and determines whether passthrough will be enabled
is controlled by the unprivileged caller.

This fusermount mechanism is used by pseudo-filesystems like sshfs in
order to allow unprivileged users to use them.

fusermount aside, there is also an (as far as I know) pending patch with
the intent to make FUSE usable in user namespaces, which is going to
allow unprivileged users to mount FUSE filesystems even without a
userspace helper: https://lkml.org/lkml/2015/12/2/472

(Note that this is very different from CUSE, which by design must never
be exposed to non-root code.)

> >Also, I think this might bypass mandatory locks, the
> >security_file_permission hook (which seems like a bad idea anyway
> >though), inotify/fsnotify and sb_start_write.
> >
> Can you please elaborate/clarify further? I am am not sure what you mean.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]