Security and authentification with D-Bus

[Yoann Sculo]

Thank you Matthew for your explanation, it helped me in my understanding 
of D-Bus ! This was exactly what I was looking for.

Meanwhile, I've found a small link in the bottom of this page 
http://www.freedesktop.org/wiki/IntroductionToDBus (Future work) which 
leads to security explanations 
http://www.redhat.com/magazine/003jan05/features/dbus/
Furthermore, I've found interesting things in the dbus-daemon manpage. I 
think I begin to understand well dbus security policies.

However, I still have some problems. Then, as you asked, to summarize 
briefly my issue :

I am working in an embedded Linux environment with multiple users. Each 
application has its own user for security manners.
But I don't deal with graphical environment, this is not *real* users.
So, I'd like to get my applications talking each others on D-Bus.
I start my bus session with

dbus-daemon --session --fork --print-address

I set and export the result into DBUS_SESSION_BUS_ADDRESS
If I use only one user, my applications work fine together.
But once I change ownerships (and launch them in separate sessions) I 
get the following error : "Did not receive a reply. Possible causes 
include: the remote application did not send a reply, the message bus 
security policy blocked the reply, the reply timeout expired, or the 
network connection was broken."
I think and suppose these applications have the good D-Bus session 
address, but don't get the right to register on it.
(for the record, DBUS_SESSION_BUS_ADDRESS is well set in each session 
and dbus-monitor doesn't show anything)

On freedesktop wiki, it says "A session bus normally carries traffic 
under only a single user identity, but D-Bus is aware of user identities 
and does support flexible authentication mechanisms and access controls. 
The system bus may see traffic from and to any number of user identities."
For what I understand : Either every application could talk to one 
session or I'm mistaken and it works only for system session and I have 
to create a dbus session for each user. In this case, how could 
applications could find each others registration on the bus ?

Well, I'm wondering if someone could explain to me what did I miss ?
I understand security policies should be written in /etc/dbus-1/system.d 
or /etc/dbus-1/session.d
How could I be able to launch my security rules ? Directories content is 
automatically launched at D-Bus startup ?

I can't easilly find help for my situation. D-Bus (for what I've seen) 
is not ofter used in multi-users environments. And documentations I can 
find for one-user aren't not completely helping in my case.

Sorry for the hudge quantity of text ...

Thank you for your help !

Yoann

Le 26/04/2010 17:59, Matthew Johnson a écrit :
> On Mon Apr 26 16:55, Yoann Sculo wrote:
>    
>> I'm working with D-Bus to let a bunch of application talk together. It
>> works great !
>> However, I'm wondering how D-Bus could provide authentification for my
>> applications. Basically, I'd like to be sure a spy-application isn't
>> usurping another application's identity. This is quite important for me
>> in my context.
>>      
> Can you give us any more details?
>
> The problem you have is how this interacts with the Unix security model. D-Bus
> currently authenticates the _user_ that an application runs as and not the
> application itself. Indeed, you cannot connect to a session bus as any other
> user.
>
> We could do something more specific, but there wouldn't be any point. If you
> are running as the same user as another process, then you can snoop it's memory
> image to determine any key needed to authenticate as that process - or read it
> from disk, or inject code into that process to send messages as that process or
> whatever. Essentially, there is no security gain from that.
>
> D-Bus does have SELinux support, so if you are using that to further control
> access to the system you can use the same security contexts on D-Bus to assure
> it is the correct application. Again though, if the malicious application is
> in the same security context, you have already lost.
>
> Matt
>
>    


-- 
Yoann Sculo | MINDSCAPE
Email : yoann.sculo at mindscape.fr