Hi David! David Zeuthen [2006-01-12 10:04 -0500]: > On Thu, 2006-01-12 at 15:25 +0100, Martin Pitt wrote: > > I was rather refering to a proper dbus service like RedHat did in > > Network Manager: the 'dhcdbd' backend is a dbus service which can be > > invoked from the user space. It is completely separate code, only has > > a very narrow interface, and does not require to run hald itself as > > root. On top of that it provides flexibility: you can install or > > remove it independently of hal. This is how it should be: only give > > privileges to parts that actually need it (a golden rule for a secure > > architecture). > > It's also a boatload of work: creating separate projects, tarballs, > version hell, API stability, concurrency issues. Partly true, but the actual code for dealing with particluar hardware (like controlling power management or mounting devices) does not have much in common anyway, and dbus already provides the glue between them. For easy things there is still the possibility of bundling the helpers with hal proper: nothing keeps a callout from being suid root and drop the privs it does not need on its own. This is much easier and more efficient than a proper dbus service. A canditate for this strategy would be label detection for hard disks: it's a tiny piece of code that doesn't really warrant the overhead of a dbus service. OTOH dhcdbd does warrant this overhead since it's an independent project. > More importantly, I'd say, you miss the connection with the hardware, > e.g. the hal device object. Today we have an extremely nice interface by > which you can say "this piece of hardware has this functionality; you > can invoke these methods" and any relatively newcomer can go ahead and > send a patch to the HAL list to do this, see e.g. > > http://bugzilla.gnome.org/show_bug.cgi?id=309067#c3 I see. But this kind of circumventing user privileges (that is traditionally defined in terms of group memberships and such) is exactly the thing that makes an all-powerful hal so dangerous. Changes to hal's architecture should not only be judged after how easy it is to throw new stuff into it. > > AFAICS this mechanism provides everything that is required for proper > > privilege separation, without the need of splitting hald into a root > > and non-root part. David, are there things that would be possible with > > that daemon split, but not with dbus services? Do you still want to > > get that split into hal? > > You know, I don't mind getting the split into HAL if it means that you > guys can start shipping a non-crippled HAL. We ship a non-dangerous hal, not a crippled one. > Btw, I really really wish you guys wouldn't ship a crippled HAL - it's > bad for the community at large and just requires extra work for all > parts including your users. I would be happy to drop all the debian/ubuntu specific parts, but not at the cost of dropping sanity. I rather cripple hal than the trust and security of thousands of Debian and Ubuntu users out there. Also, I never heard any complaints from the Ubuntu community about our default security model. We did similar things to e. g. cups (running it as a normal user), which helped to greatly restrict the impact of the various security bugs that were fixed after releases, and cupsys upstream is not fond of this either. It's not that I couldn't understand you, but we two just have different views of what we expect from software: you as upstream aim for simple and maintainable code without much overhead; I as a distro developer (and security team leader) want a proactively secure system design and loose coupling. I understand that it is sometimes hard to get a consensus between those different goals, but I still believe that a discussion (even if it's as long as this one) might eventually lead to a solution. > As distributors we should be working together on solving the > problems upstream once and for all. I perfectly agree, that's why I'm discussing all this stuff with you instead of just silently leaving it the way it is (which works just fine). Thanks, 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?
Attachment:
signature.asc
Description: Digital signature