Some privilege reduction patches

[Martin Pitt]

Hi Artem!

David Zeuthen [2006-02-18 18:11 -0500]:
> 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`".

Either that, or changing the properties in a way to mount fixed disks
like the system partition through the mount helper, thus circumventing
the device specific policy.

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

Right. But (1) this is a use case I'm concerned of (thinking about
thin client solutions, kiosk systems, etc), and (2) in the future it
is at least possible that hal and/or dbus are extended to process
messages over a network, too. So I would like to see an established
design that keeps it reasonably secure.

> 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.

Right, sorry for being too brief; you explained it pretty well.

(Also see my other reply, I was more detailled there.)

Martin

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/hal/attachments/20060220/8af5f3f2/attachment-0001.pgp