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

[Sjoerd Simons]

On Fri, Feb 11, 2005 at 11:34:48AM -0500, David Zeuthen wrote:
> 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.

Currently we do this in debian and ubuntu by having a nice dev.d script. Which
works out really well (as it also works when hal is not running for some reason
etc)..  
  
> 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?

Nope, looks like a very nice design.. It should be possible to keep the 
hald_master process quite small, so it's easily auditable..
> 
> As a data point, most secure daemons (postfix etc.) today uses this
> pattern.

Yeah, always a good idea to look at how others do things :)
> 
> ----
> 
> 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"'.

Yep although it might be nicer to have some default location for helpers (like
/usr/lib/hal/), which don't need to be placed in allowed-helpers.d.. But that's
just because the symlink forest isn't alwas as easily managable package-wise..

  Sjoerd
-- 
Your mind understands what you have been taught; your heart, what is true.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal