[Dev] Tizen 3.0 Core privilege list

Tomasz Swierczek t.swierczek at samsung.com
Thu Oct 30 11:12:38 GMT 2014

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.


Tomasz Świerczek
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 95 59
Cell +48 503 135 021
t.swierczek at samsung.com

-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly at intel.com] 
Sent: Thursday, October 30, 2014 11:05 AM
To: Tomasz Swierczek
Cc: dev at lists.tizen.org
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

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