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
