Some privilege reduction patches

[David Zeuthen]

On Sat, 2006-02-18 at 12:11 -0800, Artem Kachitchkine wrote:
> >>Last, a question: do you have any prefered strategy how to implement
> >>sanity checking in the hal-system-storage-* scripts? We don't
> >>currently ship them since they do not do any checking on their own
> >>(they just use the hal properties, which are unreliable in the current
> >>trust model). So, if the privilege separation code should have any
> >>sense, all callouts have to do input sanity checking on their own. I
> >>would like to work on this if you want, I just want to make sure that
> >>nobody else does ATM.
> 
> This sounds alarming. I mean, sanity checks are not a substitute. At the levels 
> below hald, the system device information and the fdi files are also trusted. 
> Above hald, we only allow SetProperty() for privileged callers, and we trust 
> D-BUS to reliably authenticate callers. No user is allowed to log in or run 
> processes as hal's user/group. Any of these assumptions are wrong or am I 
> missing something?

I think the attack vectors that Martin is thinking of includes 

 1. a potential buffer overflow triggered by our code that probes for
    file systems. Hence, you would be able to inject code that modifies
    properties in the hal database. Since our helpers (method calls / 
    callouts) run as root and the properties are passed as env variables
    expanding these give the attacker root, e.g. just set a property to 
    "`/path/to/evil/program`".

    The attack can be conceivably be carried out by just inserting a
    suitably formatted USB stick. Obviously this requires physical
    access to the box.

 2. D-BUS messages from any user causing buffer overflows in hald.
    Presumably any local user can attempt this advice but note that
    the system bus daemon blocks most calls unless you are a console
    user (at least on systems with pam-console).

I think 2. is pretty unlikely if you examine the way D-BUS works and I'm
not too worried about 1. as at least Fedora includes a bunch of
preventive measure (the propolice patches for gcc, no exec stack, stack
randomization, other). 

However, it's still good practice to be paranoid and I'm not opposed to
hardening the code as long as we don't cripple functionality. Maybe
Martin had something else in mind, I can't speak on his behalf and he
weren't too specific.

    David