Description of problem: Fuse in general and Fedora's way to let only members of the group fuse access and use fuse was discussed in https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00163.html and mails below in that thread. There we noticed that members of the group fuse can get access to devices which they normally should not have access to. See https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00163.html ; the relevant parts of it: $ ls -l /dev/sda3 brw-r----- 1 root disk 8, 3 14. Sep 16:10 /dev/sda3 $ groups thl fuse $ dd if=/dev/sda3 bs=512K count=1 | strings dd: opening `/dev/sda3': Permission denied $ mkdir ntfs $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/ $ touch ntfs/foo $ ls -l ntfs/foo -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo ntfs-3g IMHO should fail, as the users should not get access to random devices he has no access to. Quoting Alexander Larsson from https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00171.html >Thats quite weird. The way I undestand fuse is that you run the >filesystem as your user, and then that filesystem (via libfuse) spawns >fusermount to open the fuse device and attach to the mountpoint. >fusermount then passes the fd to the fuse device back the the filesystem >process (via a socket) which then handles all the requests. > >Reading the data source for the filesystem (if there is any) is only >done by the filesystem process, not by the setuid fusermount helper, so >it should not be able to read /dev/sda3. Further investigation showed that ntfs-3g gets installed SUID root: $ ls -l /sbin/mount.ntfs-3g -rwsr-xr-- 1 root fuse 40528 17. Sep 23:14 /sbin/mount.ntfs-3g That might be wrong as that afaics makes it possible for ntfs-3g to access devices which the user normally would not have access to. Quoting Alexander again, this time from https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00174.html >Oh. That seems like a bad idea to me. If this drops privs after opening >the device I think you can attach to the process using e.g. gdb and call >any read() operation on the device. If might even mean (with some >creative exploits) that any fuse group user can read any block on any >disk. Version-Release number of selected component (if applicable): ntfs-3g-1.913-1.fc8 Please note that I as ex-maintainer of fuse stumbled into this by accident -- I don't care much about fuse and ntfs-3g these days, but I think the behavior of ntfs-3g is a security bug.
I really think this is a security issue that needs dealing with.
It seems like the obvious fix here is to not have ntfs-3g setuid. Agree?
I think it makes sense to make any user user system-installed fuse file systems PROVIDED they have access to the underlying block device or whatever resource is backing the file system. E.g. if I use a FUSE module to access my gmail account, it should be possible for me to mount it somewhere under $HOME without having special privileges. This is much like we allow any user to use any kernel file systems PROVIDED they have access to the underlying block device (NFS, however, is special I believe). But the important part here is really that /sbin/mount.ntfs-3g is letting you use any block device you want just because you have access to /dev/fuse. That's the fundamental flaw; that program needs to also check that the invoking unprivileged user have access to the block device. I think the best solution is probably to avoid setuid and let pam_console manage permissions on /dev/fuse. That way /sbin/mount.ntfs-3g probably wouldn't need to run as root at all and mounting would only work if you have access to the underlying block device.
Thinking more about it making /dev/fuse mode 0666 and removing the setuid root bit from /sbin/mount.ntfs-3g is probably what we need to do. Shrug.
I just built and created an update for fuse and ntfs-3g (fuse-2.7.0-4.fc7, ntfs-3g-1.913-2.fc7). Please test these when they hit to ensure that this resolves the security problem and doesn't affect functionality.
The CVE identifier for this issue was requested.
(In reply to comment #6) > The CVE identifier for this issue was requested. In case it matters: it works the same way on Ubuntu 7.10/Gutsy afaisc -- if you are a member of the fuse-group there you as ordinary user can access devices which you normally would have no access to.
/sbin/fusermount should be setuid, as its required for opening the fuse device and attaching it to the mountpoint (similar to how /bin/mount is setuid) . It should imho not be setuid for the fuse group, but for anyone so that normal users can mount stuff in e.g. their own homedirs. However, that is a far cry from having mount.ntfs-3g being setuid. As far as I can tell the only reason for doing that is so that it can read the devices containing the filesystem. But this at the same time basically means any user in the fuse group can read any block device, which is horribly bad. Making it possible for ntfs to access the device as the user is better done in other ways, like the admin chowning the particular device, or the user being in the disk group.
davidz: Why should we change the ownership of /dev/fuse? I don't think that helps any. All that is needed is that fusermount is correctly setuid and executable by everyone. It opens the device, verifies permissions (via config files and whatnot) and calls the mount syscall. Then it hands over the resulting fd to the non-privileged filesystem process.
/dev/fuse was 660 before I changed it. I can change it back, if needed. Just let me know. :)
(In reply to comment #8) > /sbin/fusermount should be setuid, as its required for opening the fuse device > and attaching it to the mountpoint (similar to how /bin/mount is setuid) . It > should imho not be setuid for the fuse group, but for anyone so that normal > users can mount stuff in e.g. their own homedirs. > > However, that is a far cry from having mount.ntfs-3g being setuid. As far as I > can tell the only reason for doing that is so that it can read the devices > containing the filesystem. But this at the same time basically means any user in > the fuse group can read any block device, which is horribly bad. > > Making it possible for ntfs to access the device as the user is better done in > other ways, like the admin chowning the particular device, or the user being in > the disk group. Or just mounting it via HAL; that's how it works post-Fedora 7. E.g. if you have a dual-boot system your Windows partition should appear in Nautilus or KDE or whatever and if you try to mount it you may encounter a one-time-pain PolicyKit dialog asking for the root password. It's one-time-pain because you can select to keep the privilege forever. This is all configurable via PolicyKit.conf so it can be locked down any way the user desires.
(In reply to comment #9) > davidz: Why should we change the ownership of /dev/fuse? I don't think that > helps any. > > All that is needed is that fusermount is correctly setuid and executable by > everyone. It opens the device, verifies permissions (via config files and > whatnot) and calls the mount syscall. Then it hands over the resulting fd to the > non-privileged filesystem process. Right, it's probably better to make fusermount setuid root so it can access the /dev/fuse file rather than making the /dev/fuse file accessible to everyone. Alternatively (and maybe a bit more secure) make fusermount setgid fuse and make /dev/fuse 0660. All that matters is that fusermount can open /dev/fuse; pick whatever works and is most secure, right?
(In reply to comment #9) > davidz: Why should we change the ownership of /dev/fuse? I don't think that > helps any. Agreed. (In reply to comment #10) > /dev/fuse was 660 before I changed it. I can change it back, if needed. Just let > me know. :) Well, isn't making it 666 creating yet another problem? I'm not really sure, but if the device it 666 then the user afaics could compile his own fuse and use the device with it, thus circumventing the need to be a member of the fuse group to use fuse in general(¹)? Or am I missing something/got something really wrong now? (¹) -- which is afaik want we want for now, until "someone sits down and really does audit fuse", as jeremy wrote in https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00151.html
After thinking about it, /dev/fuse should be chmod 660 (not 666), and fusermount should be setuid root. I'm committing those changes now, and I'll respin the update.
fuse-2.7.0-5.fc7, ntfs-3g-1.913-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #15) > fuse-2.7.0-5.fc7, ntfs-3g-1.913-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. Hmmm. Lot's of users will likely run into problems now and will wonder how to make ntfs-3g work again -- wouldn't it be wise to do some formal announcement why the change was done and how users can make it work again?
How about just making /dev/fuse 666 and have no setuid/setgid bits set?
(In reply to comment #17) > How about just making /dev/fuse 666 and have no setuid/setgid bits set? Then fuse afaik doesn't work at all. BTW, we are discussing different things in this bug and that seems to become more and more confusing afaics. This bug was about ntfs-3g that could access hard disk partions it should have no access to because it was SUID root -- spot fixed that (BTW: thx spot). But that's afaics mostly (totally?) independent of the /dev/fuse files, it's permissions or the permissions of the fuse executables.
If mount(8) would execv euid=0 ntfs-3g (if the user has all the rights of course) and fuse would allow unprivileged fuseblk mounts then everything would work fine ntfs-3g non-setuid. Btw, I think users can not get uncontrolled access to any devices by suid ntfs-3g via this way, only to NTFS ones (which can be still more than it should be). If the device is not NTFS then ntfs-3g exits without dropping the privilege. Opening a device via strace/gdb/etc obviously fails.
CVE id CVE-2007-5159 was assigned to this issue.
I'm sorry to say but the Fedora and CVE advisories and security analyzes don't look technically correct as of today. First of all, this issue has nothing to do with FUSE. The reason why suid-root is needed in some cases is explained here: http://ntfs-3g.org/support.html#useroption Here is how suid-root ntfs-3g works: unprivileged initialization (parsing options, etc) gain privilege load fuse module, fix missing fuse device open(2) the device immediately read the NTFS boot sector (first 512 bytes of the partition) exit without dropping privilege if it's not NTFS. mount with FUSE if the partition is NTFS. drop privilege function as a file system driver Considering the above, could somebody please explain how a user, allowed to mount NTFS partitions via the ntfs-3g file permission settings, could gain read and write access to __arbitrary__ block device? What he can do are 1) gain information about if a device is NTFS or not 2) mount and read/write any NTFS partitions (file permission based, per device restriction is not possible until mount(8) is fixed if 'user' and 'users' mount option support is required). So it's true that they get read/write access to any __NTFS__ block devices if they were allowed to execute ntfs-3g but I fail to see how users could get access to __any__ block devices via the way the advisories talk about. Regards, Szaka -- NTFS-3G Lead Developer: http://ntfs-3g.org