On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote: > "Theodore Y. Ts'o" <tytso@xxxxxxx> writes: > > > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote: > >> > >> Very slowly the work has been progressing to ensure the vfs has the > >> necessary support for mounting filesystems without privilege. > > > > What's the thinking behind how system administrators and/or file > > systems would configure whether or not a particular file system type > > will be allowed to be mounted w/o privilege? > > The mechanism is .fs_flags in file_system_type. If the FS_USERNS_MOUNT > flag is set then root in a user namespace (AKA an unprivileged user) > will be allowed to mount to mount the filesystem. > > There are very real concerns about attacking a filesystem with an > invalid filesystem image, or by a malicious protocol speaker. So I > don't want to enable anything without the file system maintainers > consent and without a reasonable expecation that neither a system wide > denial of service attack nor a privilege escalation attack is possible > from if the filesystem is enabled. > > So at a practical level what we have in the vfs is the non-fuse specific > bits that enable unprivileged mounts of fuse. Things like handling > of unmapped uid and gids, how normally trusted xattrs are dealt with, > etc. > > A big practical one for me is that if either the uid or gid is not > mapped the vfs avoids writing to the inode. > > Right now my practical goal is to be able to say: "Go run your > filesystem in userspace with fuse if you want stronger security > guarantees." I think that will be enough to make removable media > reasonably safe from privilege escalation attacks. > > There is enough code in most filesystems that I don't know what our > chances of locking down very many of them are. But I figure a few more > of them are possible. I'm not sure we need to - fusefs-lkl gives users the ability to mount any of the kernel filesystems via fuse without us needing to support unprivileged kernel mounts for those filesystems. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
