On Fri, 2014-07-18 at 13:18 +0200, Karol Lewandowski wrote: > On 2014-07-16 13:53, Patrick Ohly wrote: > > On Mon, 2014-07-14 at 13:06 +0200, Tomasz Swierczek wrote: > > As D-Bus and Cynara integration now seems to have more attention in > > Tizen, let me use the opportunity to give a status summary. I started > > investigating what it would take to enhance dbus-daemon after TDC. So > > far, I have only updated the API for obtaining a D-Bus client's Smack > > label: > > > > https://review.tizen.org/git/?p=platform%2Fupstream%2Fdbus.git;a=shortlog;h=refs%2Fheads%2Fsandbox%2Fpohly%2Ftizen > > > > This is necessary because upstream rejected the current Tizen patch > > (https://bugs.freedesktop.org/show_bug.cgi?id=47581). > > > > Further specific work on policy enforcement is blocked by the need to > > clarify goals and various Cynara aspects, in particular the asynchronous > > API (see the separate mails about that on the list). But prototyping without > > Cynara involved is possible (see the last section of this email) and it > > is useful to discuss the concept before investing a lot of work into > > the implementation. > > > > Approaches > > ========== > > > > We have two possible ways of securing D-Bus services: > > 1. A D-Bus service calls Cynara and rejects to do things which are > > not allowed. It can reply with an error or simply ignore > > messages (TBD, see below). > > 2. The dbus-daemon asks Cynara whether a) a client is allowed to > > send a certain message and/or b) whether it is allowed to > > receive one (for signals). > > Third option would be to consider doing such checks transparently in > binding libraries on behalf of given app/service.
I see that more as one way of implementing option 1. It has the same conceptual limitations (not being able to filter recipients of signals). The other is to modify the code called by the binding libraries. > > What I have in mind for option 2 is an extension of the <allow/deny> > > rules with a <check privilege="foobar"> rule. This <check> rule would > > have the same match criteria as the <allow/deny> rules. If it matches, a > > call to cynara with > > * client = Smack label of D-Bus client > > * user = UID of the client process > > * session_id = unique connection name (1) > > * privilege = "foobar" > > determines whether the rule grants access. > > > Note that in this model, > > Cynara would never be used to take away access already granted before by > > some other rule. > > > > This means that if the current state is "allowed" when > > evaluating a check rule, it gets skipped, because a "DENIED" would be > > ignored and an "OKAY" wouldn't change the state. > > Please correct me if I'm wrong but this looks like same model of > operation as used by current SMACK patches. This model, I believe, > was critiqued openly by at least Tomasz and Rafał for exactly that > reason. Tomasz has just told me that neither Casey nor Auke were > that keen on this approach so I doubt if such model shall be used > together with Cynara. No, the current Smack policy patches were different. The Smack label and corresponding Smack rules were used to determine whether D-Bus rules were to be applied. There were multiple indirections involved. As Jose pointed out in his analysis [1], this leads to the unexpected (not a good thing in security!) situation where a <deny> rule does not get applied because a process does not have a certain access right according to Smack. Perhaps this was just a bad way of writing rules using the feature; not sure. [1] https://wiki.tizen.org/wiki/Security/Smack_setting_of_DBUS > IOW, I think it would be great if you could post this proposal to dbus > mailing list rather sooner than later. I suspect that upstream will prefer to see what kind of impact this proposal will have on the dbus-daemon source code. In other words, I think we should have at least a tentative set of patches. By then we'll also know whether we overlooked any major roadblock that might make implementing this proposal impossible. I don't think there is one, but I don't want to waste upstream's time if there is. With that in mind, can we get back to the discussion of the asynchronous cynara client API? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
