Bug 32232

Kay proposed on IM to perhaps use /etc/filesystems so it's under the control of the administrator. For example, if a vulnerability is discovered in the vfat driver the admin can quickly comment out vfat in /etc/filesystem until a new kernel has been deployed.

I'd suggest to simply require admin authentication if a user wants to override the auto detected file system or add non-standard mount options.

(In reply to comment #2)
> I'd suggest to simply require admin authentication if a user wants to override
> the auto detected file system or add non-standard mount options.

Actually, I could imagine some non-UTF8-setups wanting to pass utf8=0,iocharset=ISO8859-5 for e.g. VFAT by default (Of course, it would be even better if these setups were UTF8 but that's another battle...).

Anyway, requiring user interaction for a common thing like mounting a filesystem is really annoying for the user (and most passwords dialogs are). In the extreme, it only helps undermine the user's confidence in the OS as a whole and thus makes the system as a whole less secure. We really should try to avoid doing that by default.

Checking what we pass to mount(8)'s -t option is not really that hard.

(In reply to comment #3)
> (In reply to comment #2)
> > I'd suggest to simply require admin authentication if a user wants to override
> > the auto detected file system or add non-standard mount options.
> 
> Actually, I could imagine some non-UTF8-setups wanting to pass
> utf8=0,iocharset=ISO8859-5 for e.g. VFAT by default (Of course, it would be
> even better if these setups were UTF8 but that's another battle...).

Those options are whitelisted so a user can specify them without having to authenticate as admin. You can't load arbitrary modules that way AFAICT as modules are prefixed with nls_.
 
> Anyway, requiring user interaction for a common thing like mounting a
> filesystem is really annoying for the user (and most passwords dialogs are). 

I didn't say that mounting hotplugged disks should require authentication in general. Just passing non-standard options. Non-standard in this case means different file system than what auto-detection found. I can't remember ever having to explicitly specify a file system when hal took care of mounting.

Note that CVE-2010-4661 has been assigned to this issue as per http://seclists.org/oss-sec/2011/q1/261

FWIW, I've been busy with other stuff. Will hopefully find some time to work on this next week...

Fixed with this commit:

 http://cgit.freedesktop.org/udisks/commit/?id=c933a929f07421ec747cebb24d5e620fc2b97037

This patch has introduced an issue, as fuse filesystems do not appear in /proc/filesystems, that would mean maintaining a list of fuse filesystems that are installed on the system. This doesn't sound like something many Operating System vendors would like to be doing. Is there a solution for this?

Please see https://bugs.freedesktop.org/show_bug.cgi?id=36361 (There is just a missing comma in the well_known_filesystems)

Really ! Nobody wants to fix the missing comma at line 5905 in device.c ?
It was fixed one week ago in ArchLinux package...

(In reply to comment #7)
> This patch has introduced an issue, as fuse filesystems do not appear in
> /proc/filesystems, that would mean maintaining a list of fuse filesystems that
> are installed on the system. This doesn't sound like something many Operating
> System vendors would like to be doing. Is there a solution for this?

The filesystems used for block devices are very rarely FUSE filesystems. Please don't reopen this bug; if you need to add concrete fuse filesystems to the udisks whitelist, then open a new bug instead of using this one. Thanks.