Hi Patrick,
can't we just make proper DBus policy with existing tools so that we have user bus where we have ONLY these services that can be used by applications and system bus where we have things that apps should not call, dedicated for inter-service communication? I think this could be achieved without adding/extending either privilege list or Cynara. Anyway, idea seems worth further discussion. What others think about it? I'd like to add this topic to our next F2F meeting agenda. One reason for this is because I'd like such decision to be fully discussed with everybody on our security teams, and second - the implementation you proposed, with hardcoding parts of policy, is what I'd personally object :-) Cynara already has (not released yet, but in code review) DB integrity mechanisms and will have "emergency mode" so if there is ANY problem with DB, it denies any access. BRs, 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: Patrick Ohly [mailto:[email protected]] Sent: Thursday, October 30, 2014 11:05 AM To: Tomasz Swierczek Cc: [email protected] Subject: Re: [Dev] Tizen 3.0 Core privilege list On Tue, 2014-10-28 at 17:38 +0100, Tomasz Swierczek wrote: > Hi All, > > > > As part of our work on privilege-based access control model with > Cynara in Tizen 3.0, we’ve gathered Tizen 3.0 Core privileges in one > place: https://wiki.tizen.org/wiki/Security:Tizen_3.0_Core_Privileges I think we also need something like http://tizen.org/privilege/system and http://tizen.org/privilege/user as a fallback for operations which don't fall under any of the other defined privileges. Example: system D-Bus service "foo" offers a method "bar()" which is meant to be used only by other system services. Any process can try to call it, so when invoked, the service or dbus-daemon should call Cynara and asks to check whether the caller has the http://tizen.org/privilege/system privilege. Cynara could grant that to all processes running with the "System" label and deny for everyone else, similar to the existing <policy user="root"> or <policy group="plugdev"> entries in /etc/dbus-1/system.d/hal.conf (taking just one example). This is particularly important for a user session D-Bus service, because there we don't have a user or group to check against. A user service should check for http://tizen.org/privilege/user, which then gets granted for processes running as "System" or "User". Without this special privilege, each user service would have to implement the Smack check itself instead of using the unified privilege checking code paths and instance (= Cynara), or we need to revive the non-upstream, and otherwise obsolete Smack label checking and rules in dbus-daemon. Cynara then becomes a very critical system component, even more than before. When it fails, not even user and system services will be able to do privileged operations. To minimize the risk, I would hard-code the rules above in the Cynara daemon instead of depending on a potentially broken rules database. But that's just an idea. -- 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
