Dbus and security - a few questions
John (J5) Palmieri
johnp at redhat.com
Fri Mar 4 20:17:44 UTC 2005
On Fri, 2005-03-04 at 20:36 +0100, Kyrre Ness Sjobak wrote:
> As a desktop/server Linux user (and spare time developer which really
> needs a good GTK/C book in order to be able to contribute more back to
> the comunity), i am thrilled to see the new posibilities dbus opens for
> user-friendly interaction. But a bit concerned as well (probably because
> i don't know much about dbus) over security issues.
> As far as i understand, dbus is a framework for aplications running on
> the same computer to comunicate. Great. It is often used to connect
> backend (often running as root, doing stuff with system configuration),
> and frontend (often running as any user which happens to have user
> access to the system). One example is NetworkManager - which is great
> for primarily single user laptops.
> But as this system grows, and more and more apps hook up - what are the
> exploitation risks? Could one f.ex. buffer overflow a privilegued app
> trough the dbus "network"? Which/what kind of services will be turned on
> by default in future fedora installations? Ofcource, having
> NetworkManager running on a shell server would be a problem so
> NetworkManager would probably never be turned on by default, but where
> are the border cases?
> Such things.
> Kyrre Ness Sjøbæk
Have you read my article?
It specifically deals with d-bus security. D-Bus is a trusted component
of the system so yes, if there is a vulnerability in d-bus or one of the
apps running over d-bus it could be used as an exploit. However d-bus is
built with security in mind and whenever we allow an application to
export normally restricted functionality we do so very carefully using
d-bus's security mechanism to make sure only users who should get that
functionality are able to use it. It is similar to the risks of setuid
binaries. Of course d-bus also has the ability to enhance security in
many ways outlined by the article. BTW the idea is for NetworkManager
to one day be the only way to configure networking. Of course it has a
long way to go before it can become the default.
John (J5) Palmieri
Associate Software Engineer
Red Hat, Inc.
More information about the devel