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

[David Zeuthen <david fubar dk>]

On Thu, 2006-01-12 at 18:38 -0800, Artem Kachitchkine wrote:
> > 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?)
> 
> Well, you know what they say about ciphers: breach is rarely in 
> alrogithm, it's most often in the implementation. People have written 
> unix root daemons for years and have come to a conclusion that it's not 
> a good idea unless there is no way around. Withing limits, of course, 
> it's all about balance, you gain something, you lose something.
> 
> Writing root code requires more discipline, more peer review, more 
> auditing, more testing... It's like walking around with a loaded gun: 
> sure it's safe if you are a responsible person, but guess who's most 
> paranoid about that - that's right, folks who actually used firearms a lot.

Well, I definitely subscribe to this line of thought. Well put, btw.

Actually, to put a thought forward, I think that with the framework we
got today, adding the privilege of e.g. invoking the method Foo() for an
unprivileged user is very easy [1] in so far that you get a lot of the
auth checking for free. This code (both in D-BUS and HAL) of course
needs to be very carefully reviewed (like any other code) but it's the
same code running for all methods. Hence, eventually we'll get it right,
just like other pieces of code :-). 

However, there's no such thing as a free lunch so the actual binary or
script performing the method needs to do careful checking and/or drop
privileges. I'd still argue it's less code/work than with e.g. a setuid
approach and hence we should see less buggy / dangerous code.

Also, I do think it's a bit more slick, intuitive even, to provide
functionality this way in so far that you'll get the whole association
between the hal device object representing the hardware and the actual
method. Contrast this with e.g. a setuid mount helper; here you need to
figure out the device file and pass that. Also, all the D-BUS goodness
such as introspection (though we need that in HAL still), language
bindings etc. comes to mind... though this is a bad example for Mount()
et. al. since we wrap it in gnome-mount for other reasons (settings in
gconf) :-)

Finally.. sometimes you really need those extra privileges.. for
example, for the Mount() method we also create/destroy directory entries
in /media.

Walking the line between providing security and providing functionality
to the user is indeed a fine one.

[snip]

> In addition to the above, users will have more choice with respect to 
> automounters, they are not restricted to HAL. For instance, some control 
> frea... uh, experienced users, don't like automatic mounters and prefer 
> the standard /sbin/mount. Using mount privileges, Solaris doesn't need 
> suid-root /sbin/mount commmand nor any special fstab options - it just 
> works. Lowering the bar from HAL methods to the system call level makes 
> the system simpler and more flexible at the same time.

Well, some users of Linux based system are equally, heh, "experienced",
and they just turn off auto-mounting in g-v-m and do their perverse
thing in the terminal. More power to them. So, basically, I don't see
why you should disable Mount() et. al. in HAL just for this reason.

Cheers,
David

[1] : just add an fdi file like this

 http://cvs.freedesktop.org/*checkout*/hal/hal/fdi/policy/10osvendor/20-storage-methods.fdi

and define your policy in e.g.

 http://cvs.freedesktop.org/*checkout*/hal/hal/hal.conf.in

or another D-BUS configuration file.