(we need this in order to work properly for systems without something such as
pmount... like SuSE)

Created attachment 56040 [details] [review]
gnome-vfs-hal-mount.patch

A few months ago a SuSE guy wanted to package pmount.

<rant>Why suddenly everybody goes mad and wants to make hal the central, wide
open point of attack and failure (power management, mounting, etc.)? That is
just plain stupid and makes hal totally unsuitable for any half-way secure
desktop environment.</rant> (Sorry, but this drives me up the wall)

Please reconsider this approach.

besides, mounting should be done by an user, not by a system daemon. Otherwise
you will lose the ability to make files (on e. g. vfat partitions) private for
an user. This will render things like keeping your gpg key on an usb key, or
using encrpyted partitions totally impossible.

Martin, I think the mounting by user problem is solved with that commit to hal:

2005-12-14  Kay Sievers  <kay.sievers@vrfy.org>

        Add HAL_METHOD_INVOKED_BY_UID to the method-call environment
        and use it to mount FAT, NTFS and hfs volumes to make them available
        to the user who invoked the method.
        * hald/hald_dbus.c: (hald_exec_method):
        * tools/hal-system-storage-mount:

I acutally think its quite ok the let hal do that, I mean its the hadware abstraction layer after all. 
I am going to have a closer look by this evening.

So I'm not totally sure that this is the approach I like. 

Ideally I'd like gnome-vfs and gnome-volume-manager to invoke gnome-mount/gnome-umount/gnome-eject as described in this and surrounding messages

 http://lists.freedesktop.org/archives/hal/2005-December/004138.html

The thinking is that the gconf schemas for settings regarding mounting shall remain private to the gnome-mount tarball. Ideally gnome-mount would provide a Nautilus extension to tweak the settings / default policy. 

From a gnome-vfs/gnome-volume-manager point of view this is similar to calling e.g. pmount.

(btw, gnome-mount is work-in-progress)

Martin: I don't really appreciate comment 3 - I've asked you many times in public for specific attack vectors with HAL and so far you failed to give any.

Btw, if you want to talk about concrete security issues, it is my point of view that doing mount/umount/eject via D-BUS messages (checked by the system message bus and all) is by far superior to using a setuid binary.

(In reply to comment #6)

> Martin: I don't really appreciate comment 3 - I've asked you many times in
> public for specific attack vectors with HAL and so far you failed to give any.

Since so many applications talk to hal, there are lots of them: dbus messages with specially crafted strings (buffer overlows), exploiting race conditions or special hardware to leave certain fields uninitialized (NULL dereference), specially crafted USB sticks that cause crashes in the file system/partition detection code, exploiting race conditions to hang hal, etc. So there are a lot of attack vectors in hal, and we had actual bugs that triggered all of these cases in the past. That these got solved does not mean that there aren't any left.

So far I was not overly concerned in putting much research effort into finding actual vulnerabilities, since hald has very little privileges. But if hal becomes the single central daemon that runs as root and has access to everything, it suddenly becomes a very interesting attack target. Centralizing things to a single point of failure does not really help to make systems more stable.

> Btw, if you want to talk about concrete security issues, it is my point of view
> that doing mount/umount/eject via D-BUS messages (checked by the system message
> bus and all) is by far superior to using a setuid binary.

I don't think that this general statement is true; it all depends on how wide/narrow the respective interfaces are. A small setuid helper to e. g. trigger suspend to RAM, or mount a drive only has a very narrow interface - it accepts a boolean, or a single device string; they do a single job, can be rigorously written for cautiousness, and are auditible. This is not true for hal, it's a huge application that is by far not written in a very defensive way; this is by far not intended to be a blame, just a matter of how life and software development works; applications and systems simply get less robust when they grow.

In this concrete case, I do not object at all against using dbus messages to trigger mount/power management/whatever operations; to the contrary, this would help to further decouple systems, and in fact that's what we currently do in Ubuntu to clean up power management. What I do object against is to put all the active elements into hald proper and let it run as root. Dbus services (or hal setuid callouts) were invented specifically for *de*coupling systems which is a very good thing to do both stability and security wise.

Thank you and have a merry christmas!

(Sorry for not CC'ing to the bug, did that now)

fwiw, I feel DavidZ is right about it being a better idea to simply have gnome-vfs use gnome-mount rather than incorporating my patch here.

I am thinking that gnome-mount could even incorporate some of gnome-vfs's mounting magic as far as volrmount and so on to simplify that code quite a bit.

We have davidz gnome-mount support in gnome-vfs HEAD so I guess this bug is obsolete.