formatting/partitioning methods in HAL

[David Zeuthen]

(adding dbus list to the mix as this is more a D-BUS issue)

On Fri, 2006-02-24 at 19:06 -0800, Artem Kachitchkine wrote:
> > D-BUS and HAL provides a very nice and secure way of allowing certain
> > unprivileged users to do very basic and *controlled* things through
> > D-BUS method invocations.
> 
> One thing I found with integraing D-BUS into a non-native OS (I'm I 
> allowed to say that? :) 

Heh, actually I think D-BUS on Solaris might be closer to D-BUS on
Fedora than D-BUS on Fedora is to D-BUS on Debian as I believe you guys
also use pam_console. Oh well :-)

> is that it's difficult to integrate with 
> existing security mechanisms. D-BUS is limited in recognizing extended 
> security attributes (identity, authentication, privileges, etc) at the 
> other end of communication (methods and, more so, signals). UID is not 
> enough, even you recently hit the wall with the lack of session 
> identifier for ConsoleTracker.

Well, we can do with uid given the two caveats I posted. But having a
session identifier would be a lot better. I don't have any ideas on how
to do this though without making a lot of assumptions about the OS (I
think it's possible given SELinux).

>  In theory, D-BUS in expandable in this 
> area, but it has not been done in recent history, as far as I can tell.

Right [1]. I'm not even sure how to spell out the problem correctly. I'm
not sure, but I *think* the problem we're trying to solve is that of
denying / allowing an unprivileged process in a desktop session to
invoke (privileged) operations such as mounting a volume, formatting a
disk or configuring a device. 

I'm not convinced that we need to require anything else but requiring
the user to be at the console (or if you're Debian use group membership)
or become uid 0 [2] to allow such operations? I can't think of anything,
but I'm probably missing something central though.

Btw, specifically for HAL we also have an interesting constraint in so
far that the amount of privileges needed vary with the specific device.
In a way this is interesting and probably not something the D-BUS
authors anticipated in the current security model.

For example, while we may want to allow a console user to format his USB
pendrive we probably want to require some kind of auth (for example
require uid 0 thus requiring the user to input the root password) if he
wants to format a partition on the internal hard disk in his system.
Now, this is not really something D-BUS supports natively (could we?),
in this example we would need to check for uid 0 (or whatever) in the
code that is invoked by the method.

Another example in HAL may be to reject methods for devices we know
belong to a specific console, except for users logged in at that
console. Again, due to the dynamics of things, this is something we'll
need to reject at the HAL level instead of the message-bus level since
D-BUS does not have facilities for this.

The next question is then how vendors and admins can tweak the policy
(e.g. when do we require console user, when do we require uid 0) of HAL?
For example, a laptop oriented distribution might allow the console user
to do mostly anything while general purpose distributions might want to
bug the user with having to become uid 0 to format internal hard disks.
It seems to me that the answer to this question right now is partly
"tweak the /etc/dbus-1/system.d/hal.conf D-BUS policy file" and partly
"patch this or that shell script and/or program". In reality I think
we're long term going to end up with UNIX-style configuration file hell
in /etc/hal defining these policies :-(. Until we get a system-wide
configuration store or someone seriously slims down gconf at least.

Oh, sorry for all the rambling, it's Sunday after all :-)

Cheers,
David

[1] : Btw, as an aside I think that, on Linux, you can match on SELinux
security contexts, e.g. I can label /usr/bin/gnome-mount with the label
may_invoke_mount_t. Then I can write policy to reject all requests to
Mount() on the interface org.freedesktop.Hal.Device.Volume except those
originating from a processes originating from a process running in the
may_invoke_mount_t security context and is owned by a user at the
console. Of course, this is Linux specific and not all Linux-based OS'es
(only Fedora/RHEL at this point I think) ship with SELinux. Oh, I may
have the specifics wrong (Colin will know if he's still reading this
list) but I think the is the gist of it. 

[2] : or make the process assume membership of an 'admin' group but I'll
use uid 0 in the following