Re: hal privileges [was: Re: [Utopia] gnome-mount 0.3 is out]

[David Zeuthen <david fubar dk>]

On Thu, 2006-01-12 at 08:41 -0800, Artem Kachitchkine wrote:
> > I see. But this kind of circumventing user privileges (that is
> > traditionally defined in terms of group memberships and such) is
> > exactly the thing that makes an all-powerful hal so dangerous.
> 
> That's what has been tormenting me for weeks. As someone who has not 
> contributed code to hal (but about to), I feel I have no say in 
> fundamental issues like this and I am relieved to see this brought up 
> now. Privilege separation is very different from access control, D-BUS 
> can only provide the latter. In systems with explicit support for 
> privileges it's more obvious, although the principle applies to any 
> system, regardless of implementation.

Maybe I just fail to see the point.. but all that HAL does in this
respect is to provide privileged operations to users that are not
usually privileged. I think we do this in a secure way (do you
disagree?) as we have a tight and well-defined defined API (methods
Mount(), Unmount(), Eject()) and a message passing based system with
multiple checks along the chain:

 gnome-mount <-> system message bus daemon <-> HAL daemon <-> hal-system-storage-mount

(also keep in mind that the system message bus does comprehensive checks
of arguments and also has denial of service counter measures built-in)

You can even specify restrictions in the D-BUS policy configuration file
here http://cvs.freedesktop.org/*checkout*/hal/hal/hal.conf.in and
specify restrictions such as group membership, whether the user must be
at the console, whether the method invocation needs to come from a
process running a specify SELinux security context.

> E.g. in Solaris, the mount(2) syscall can be executed by euid!=0 code if 
> euid is granted mount privilege - that makes any suid-root mount 
> wrappers redundant (in general, the notion of a superuser is becoming 
> redundant). This is not to say policy-aware mount wrappers are 
> redundant, but with the way things are now, we'd have to disable mount 
> methods in Solaris and patch gnome-mount to invoke mount(1) instead of 
> methods (mount option limitations can also be built into privileges).

I guess I'm asking.. why is it better to use that specific mount(2)
Solaris syscall (the one that can be executed when euid!=0) than to just
invoke Mount() on HAL? Is it because the hal-system-storage-mount (the
helper for Mount() on HAL) would run with full privileges and thus
invoke mount(1) with full privileges? If so, what are the specific
problems and do you need something from HAL to fix this?

> I would like to take this opportunity and ask to keep Linux-specific 
> assumptions to a minimum when thinking about HAL architecture. It will 
> not only benefit other OSes, but also benefit Linux in the future, as it 
> rapidly evolves.

I hear your point, but in this specific case I fail to see what's so
Linux specific about this. In fact, I'd argue that the more methods we
provide the easier it should be to get the desktop software using HAL
running on various OS'es provided you have ported HAL to that platform.
Things like the gfloppy bug I posted earlier comes to mind.

David