Re: mount_service: possible implementation changes

> > From my attempt at this redesign, I now think that this "client-server" approach is
> > probably *not* a good idea to merge into libfuse, and that its best to keep as a
> > separate project.
> > This is primarily because there aren't good ways to implement the filesystem access
> > check that a setuid program has access to: installing defused allows programs
> > to mount over directories that an AppArmor rule would have otherwise disallowed.
>
> Er, why is that? Does AppArmor not enforce the same rules between an
> unprivileged process trying a direct mount() vs. a privileged process
> that has entered another process' mount namespace to call mount()?
>
> Can you setns more namespaces (e.g. enter the user namespace as well and
> then setuid to the socket client process' credentials?)

LSM security contexts are attached to task credentials, which I don't think you can emulate
(unless you do something insane like attach a debugger to the program).
You would also run into issues where by virtue of entering such a context, you lose
CAP_SYS_ADMIN and thus can't actually perform the move_mount().

Maybe there's a way to check that the file descriptor that was sent was opened O_WRONLY?
Because I control both sides of the protocol this could allow the client to perform the
check and simply pass the proof to the server.

> > Another is security: the system service calls `setns()` on the client's mount namespace
> > with root privileges, which can very easily become a security issue if libc lazily
> > loads any shared libraries. I solve this by installing an extremely strict seccomp
> > filter, but this is not something libfuse should have to worry about.
>
> Huh. So the defused daemon forks a child which adds its own seccomp
> filter, and only then does it enter the socket client's mount namespace
> to attach the mount?
>
> Clever. :)

This is actually something that I've been meaning to improve on, since the umount code
still needs access to openat2 which is a little iffy. I don't know the implications of
lazy unmounting, but if that option was always set then I could just have the client pass
a file descriptor pointing to the mountpoint itself rather than the parent fd + filename.
The fact that there is a race condition (even though I don't think it could ever be
exploited, and libfuse has the same 'issue') bugs me.