> -----Original Message----- > From: Karol Lewandowski [mailto:[email protected]] > Sent: Monday, November 04, 2013 6:53 AM > To: Schaufler, Casey > Cc: Jacek Janczyk; Tizen Dev; 'Semun Lee'; Rafał Krypa; 최형준 > Subject: Re: [Dev] [RFC] kdbus transport for DBus > > On 10/31/2013 05:56 PM, Schaufler, Casey wrote: > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Jacek Janczyk > >> Sent: Thursday, October 31, 2013 4:26 AM > >> To: Tizen Dev > >> Cc: 'Semun Lee' > >> Subject: [Dev] [RFC] kdbus transport for DBus > >> > >> Dears, > >> > >> Here, at Samsung, we are experimenting with product specific DBus > >> extension to use kdbus (kernel module) as a transport layer instead > >> of Unix sockets. > >> Currently the scope is limited to enable applications using either > >> libdbus or glib (libgio) to work on top of kdbus bus without noticing any > difference. > >> More one can find in a brief arch description attached to modified > >> dbus sources (see doc-kdbus directory). In the same place there is > >> also a current development status. We will add there also our todo list. > > > > What is your plan regarding supporting Smack? If you do not support Smack > controls in kdbus it can not be used in Tizen. > > > > Really. That's a day one requirement. > > By default kdbus provides us with rather different security model compared to > what we had before (with modified dbus-daemon). Namely, when client app > connects to bus it can request kdbus to attach security context[1][2] of > source > application to each message it delivers[3]. > > This moves the need to check permissions from entity that does the routing > (previously dbus-daemon, now kdbus) to client application itself (effectively > binding libraries).
You can't count on every application that uses (k)dbus to enforce system security policy. That's why we put the controls into dbus. Look at UDS. The kernel enforces LSM policy there. Look at IP, the kernel enforces LSM policy there, too. If kdbus does not enforce policy in the kernel we can't use it in Tizen. And you can't say that enforcement happens in libraries. Libraries are just wads of code that are part of the application. They can be easily circumvented. > Iff this model is acceptable for us then all we have to do is to add policy > checks > to respective binding libs. If not - we would probably need extend kdbus to > support security label-based policing/routing (as HyungJun wrote we've started > looking into it). > > [1] https://github.com/gregkh/kdbus/blob/master/kdbus.h#L235 > [2] https://github.com/gregkh/kdbus/blob/master/connection.c#L850 > [3] https://github.com/gregkh/kdbus/blob/master/message.c#L614 > > Cheers > Karol _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
