On 2014-12-02 10:25, Patrick Ohly wrote: > On Mon, 2014-12-01 at 19:11 +0100, Karol Lewandowski wrote: >> On 2014-11-26 15:46, José Bollo wrote: >>> Le mercredi 26 novembre 2014 à 14:48 +0100, Jacek Bukarewicz a écrit : >>>> Recent talks on the D-Bus mailing list suggest that in the future all >>>> messages could contain connection credentials [2] which would make >>>> integration process on the service side a bit easier. Such posts suggest >>>> that performing checks on the service side is an approach that is >>>> endorsed by the community. From my understanding it will also be the >>>> suggested way of securing kdbus services. >>> That is very interesting. Thank you for that input, even if it exclude >>> the path taken by tizen. >> >> I would be quite worried if "path taken by Tizen" would be radically >> different from upstream's. > > FWIW, Canonical is also moving ahead with their dbus-daemon patches to > secure D-Bus in combination with AppArmor. So it's not just us still > relying on dbus-daemon. > >> Ignoring community direction might cost us a lot in >> long run >> - and I do not think anyone would be interested in that, >> >> I do believe we are considering this approach because: >> >> (1) there is clear need for fine-grained policy checking >> >> (2) upstream packages we are interested in do not implement it on >> service side >> >> (3) trying to change above does seem too much work compared to gains >> it might bring. >> >> ... and I agree that in above cases implementing dynamic checks in >> dbus-daemon might be great idea. > > Exactly. > >> However, what I would warn (and advise) against is delegating policy >> checks to dbus-daemon where we can implement it directly in given service >> without >> too much trouble (ie. all services we are *the* upstream of). > > I tend to agree. However, I'm not exactly seeing the developers of those > services being particularly eager to do that work either. Has anyone > indicated that they even looked at Cynara and tried to use it in a > service?
I think it would help (me, possibly others) if we could have a clear mapping from abstract privileges to APIs provided by system services. Thanks to Tomasz we do have first part - the Core Privileges list https://wiki.tizen.org/wiki/Security:Tizen_3.0_Core_Privileges I think second part is missing, or at least I am not aware of any source telling me clearly what service, with what API is serving given privilege. I guess we should be starting collecting such information if above statement is not true... Do you think it would be useful? (I could certainly make use of it checking if current design of given service could be served by kdbus LSM hooks...) > I only know of Kevron (Automotive Message Broker) and myself > (and I depend on the D-Bus patches because I need to secure upstream > D-Bus services). > >> While this isn't problem for now I would encourage to really take into >> account >> that in next 1-2 years Linux systems are likely to be running without >> dbus-daemon >> at all. > > It doesn't look like kdbus will be a drop-in replacement for the current > D-Bus, so services and clients will have to be adapted to use it. That > would be our opportunity to get the security checks into upstream. And > yes, that means working with upstream instead of just taking the code > and then trying to run it as-is in Tizen. This looks like win-win situation for me. :) Cheers, -- Karol Lewandowski, Samsung R&D Institute Poland _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
