Hi, Let me add some information in DBus: the DBus patches that utilized Smack-based checks were/are used in Tizen 2.X. These patches created a connection between a method/interface name and Smack label - and only those clients were allowed to call method/interface, that had explicit Smack rule from their process Smack label to the label "virtually" assigned to the interface/method. The Smack rule check was indeed made with lookup in kernel list of Smack rules, but the check was done during DBus daemon startup and policy decision was remembered in DBus internal cache - this is the state that I recall and I'm almost sure its still valid for Tizen 2.X.
For Tizen 3.X however - there is no association of methods/interfaces to Smack labels. Instead, there are patches prepared & merged that allow to associate them with privileges, that are in turn, checked by Cynara, and from what I know, this policy check is done - in contrary to the above - at runtime, during actual method call (see https://review.tizen.org/gerrit/#/c/31022/ and subsequent patches in DBus, also this wiki page: https://wiki.tizen.org/wiki/Security:Cynara:DBus_integration ). As for general rule, processes running with application labels should not register any interface in DBus nor should they talk with each other. The only allowed methods of IPC between applications should be the officially available "message port" and/or "data control" APIs (or any other possibly added in the future - but not native DBus/Socket/etc.). I hope I helped. Best Regards, Tomasz Świerczek Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 95 59 Cell +48 503 135 021 [email protected] -----Original Message----- From: José Bollo [mailto:[email protected]] Sent: Monday, September 28, 2015 2:33 PM To: Patrick Ohly Cc: Tomasz Swierczek; [email protected] Subject: Re: [Dev] Our lessons learnt about tizen's security Le lundi 28 septembre 2015 à 12:02 +0200, Patrick Ohly a écrit : > On Mon, 2015-09-28 at 11:18 +0200, José Bollo wrote: > > Thank you Tomasz for your kind and quick answer. > > > > I'll introduce your remarks in a later version of the document. > > I'd like to add that the D-Bus patches are also needed to separate > applications from each other. Even if all system D-Bus services were > patched to handle messages from arbitrary, untrusted peers, expecting > the same from app developers probably wouldn't be wise. > > But you are right in the document, it is a tradeoff. > Hello Patrick, I think that I understood what you wrote: native applications using D-Bus shouldn't be able to exchange messages by default. Am I right? So I think that in these case, D-Bus applies the policy based only on Smack labels and rules. Security rules based on Smack exist in smack compliant dbus implementation. Is it there the D-Bus patches you wrote about? But IIRC, this check is based only on D-Bus config files, not on smack's kernel database. If I'm not wrong, it is a big missing point in the document and have absolutely to be treated. Because in that case, what should be the correct lesson? Might I write that a such feature was only needed for Tizen 2 and that currently the kernel rules should apply in all cases? Because I am not sure to fully master the problem, I really wish some feedback and advise. Best regards José Bollo _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
