[Dev] Tizen 3.0 Core privilege list

Patrick Ohly patrick.ohly at intel.com
Thu Oct 30 10:05:15 GMT 2014


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.





More information about the Dev mailing list