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? http://www.redhat.com/magazine/003jan05/features/dbus/ 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 Desktop Group Red Hat, Inc. Blog: http://martianrock.com
