[PATCH] [RFC] Always run hald as non-root

[David Zeuthen]

On Tue, 2005-02-08 at 16:59 -0500, David Zeuthen wrote:
> >   I think it's the right way to do things. There should be no reason to run
> >   hald as root ever and forcing it from the start of the development cycle is
> >   a good way of ensuring that :)
> 
> Sure, we've already agreed on this so, yeah, no probs. Your patch wasn't
> perfect though; it didn't change hald/hald.c:usage() and it didn't
> remove the libcap stuff from configure.in.
> 
> Also, for development, you want to run hald as root as otherwise you
> need to setuid root all your probers, callouts and addons all the time.
> So, I added the option --retain-privileges and added that to the
> run-hald.sh script.
> 

Actually, I been thinking a bit more about this. 

I'm really not happy about having to have all the probers, callouts,
addons setuid root because it makes it much easier to screw up packaging
and it makes tarball installs a pain. 

Also, hald needs to do '/bin/umount -l /dev/blah' once in a while, and
with this architecture we're kind of forced to provide some kind of ugly
hald-lazy-unmount script to do this.

However, I too want to run hald unprivileged. So, here's the deal:

  uid=0 +-------------+
        | hald_master | <---> spawn probers, callouts, addons,
        +-------------+       do lifecycle mgmt
           ^
           | D-BUS peer to peer  (methods Unmount, Exec, ...)
           V
         +------------+ uid=haldaemon
         | hald_slave |
         +------------+

When hald starts up it forks of hald_slave and setups up D-BUS in peer
to peer mode between hald_master and hald_slave. Also, hald_slave, where
all the action is, drops all privileges.

Now, when we want to exec a helper (probers, callouts, addons) we
normally use the following functions from hald/util.c

 hal_util_helper_invoke ()
 hal_util_terminate_helper ()

I think it's pretty easy to move the bulk of what they do to the master
and make stubs in the slave for the IPC. 

We're trading off some latency/processing for better default security
out of the box. I think it's worth it. Sjoerd, are you violently opposed
to this?

As a data point, most secure daemons (postfix etc.) today uses this
pattern.

----

Another thing is that we should limit what things we want to exec as an
extra security measure.

I'm thinking of having a directory /etc/hal/allowed-helpers.d where we
want to allow the invocation of a helper ONLY if there is a symlink in
that directory to the binary. 

So, out of the box we would have

 /etc/hal/allowed-helpers.d/
 |-- hald-probe-storage -> /usr/libexec/hald-probe-storage
 |-- hald-probe-volume -> /usr/libexec/hald-probe-volume
 |-- ..
 `-- fstab-sync -> /usr/sbin/fstab-sync

This is important because right now we allow things like

      <append key="info.callouts.add" type="strlist">fstab-sync --clean</append>

that is substituted as appropriate such that '--clean' is the first
parameter to fstab-sync [1] (yes, this callout is added to computer to
clean up the added entries to /etc/fstab). 

Right now, this is a can of worms as anyone can append the callout
'/home/mallory/bin/some-compiled-sh /bin/echo "you are owned"'.

Cheers,
David

[1] : Btw, it would really rock if someone wrote a patch to do variable
substitution, e.g. being able to have

      <append key="info.callouts.add" type="strlist">fstab-sync --add $block.device</append>


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal