Le lundi 28 septembre 2015 à 15:03 +0200, Tomasz Swierczek a écrit : > 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.
Tomasz, I just rechecked with more success. D-Bus seems to use kernel rules at each connexion. I sew no caching of kernel rules. > 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 knew that (however, I'll check "data control"). What I don't know is how is precisely managed "message port" on the author basis in the current model. > I hope I helped. Yes! Thaks a lot. Regards José > Best Regards, > > > > Tomasz Świerczek > Samsung R&D Institute Poland > Samsung Electronics > Office +48 22 377 95 59 > Cell +48 503 135 021 > t.swierc...@samsung.com > > > -----Original Message----- > From: José Bollo [mailto:jo...@nonadev.net] > Sent: Monday, September 28, 2015 2:33 PM > To: Patrick Ohly > Cc: Tomasz Swierczek; dev@lists.tizen.org > 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 Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
