On Fri, 2014-10-31 at 19:17 +0100, Jacek Bukarewicz wrote: > Hi, > > As you might know there is an idea to integrate Cynara checks into > dbus-daemon. Its implementation has been started by Patrick Ohly. I > continued this task and a version of dbus-daemon with this feature > implemented is available in my dbus sandbox. > git://review.tizen.org/platform/upstream/dbus > (sandbox/jacekbe/cynara-integration branch)
Which version of Cynara does that need? > It would be nice to get feedback from service developers whether you > find it useful and sufficient to secure your services. > Ideally, service developers could try this version of D-Bus and see if > they notice any problems. I'm not sure if other parts of security > infrastructure are ready so such tests can be performed though. It would be good if we could run dbus-monitor and Python scripts as if they were less-privileged apps. Does anyone know how to do that? > Additionally, I'd like to know whether we also need to support such > construct: > <check own="com.example.name" privilege="example.privilege" /> > That is: allow only applications/services having given privilege to > own given name. > It would be if services weren't trusted or applications would like to > request some well known name on the bus. I'm not sure if that's the > case. I think it is needed. Otherwise any app can impersonate anything normally accessible via the user session bus and thus potentially intercept confidential information from other apps. But what privilege is needed to own a name on the session bus? The only thing that I can think of is the http://tizen.org/privilege/user privilege that I proposed in the "Tizen 3.0 Core privilege list" mail thread. > Also, are there resources that need multiple privileges or we can > assume that every resource maps to a single privilege? I think at this point we can limit the checking to a single privilege. If a D-Bus service developer needs to check for multiple privileges, they can still call Cynara directly. If this turns out to be common enough, we can still add it to dbus-daemon by turning the "privilege" parameter into a comma-separated list with the meaning of "need all of these", which will be backwards compatible. Needing one of several alternative privileges is already supported by writing different allow rules, one for each privilege. -- 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
