Security/Tizen 3.0 security porting guide

From Tizen Wiki
Jump to: navigation, search


Linux systems security is based on traditional Unix permissions (DAC) and Mandatory Access Control. Tizen uses these mechanisms and also introduces third one - Cynara - a central security daemon which allows to create and effectively manage complex security rules. In Tizen, all three mechanisms are used to secure services and resources directly accessible.

Securing services

Trusted system services are very prevalent in Tizen. From security point of view they are desirable as they provide fine-grained control over what its client can do. Just like resources, services shouldn't be freely available to anyone - some form of security enforcement is required. What this exactly means might vary depending on type of inter-process communication they use and on who is allowed to access the service:

  • D-Bus services security can be enforced by writing proper configuration file. It is often sufficient as D-Bus policy language is pretty descriptive. You can find more information in the "D-Bus services" section later in this page.
  • Permissions to IPC objects (Unix sockets, message queues and others) can be controlled by DAC and Smack policy
    • For system internal services this is usually sufficient
    • For services available to applications this also might be enough provided that access to given IPC is controlled by a single privilege. In such case approach should be the same as the one described in "Securing access to resources" section
  • For more complicated cases performing explicit Cynara checks in service code might be required

Explicit Cynara checks in services

Services can use Cynara to perform security checks. It's the most flexible and often only viable option. Such checks should be performed on per-request basis as described in the following diagram:


Adding explicit Cynara checks might be required if securing IPC by means of DAC or Smack policy is not enough. For example:

  • some of requested actions require privilege while others do not
  • required privilege might vary between different types of requests
  • service might want to grant access to certain resource only for given session (for example - application lifetime)

In either case service should use one of Cynara client APIs (synchronous or asynchronous) and check if request made by Cynara client is allowed. Cynara synchronous client library allows to perform blocking security checks. Keep in mind that such check might take a long time as it can trigger popup prompting user to decide if certain request is allowed or not. If blocking for a long time is not acceptable asynchronous API is also an option. It is designed for easy integration with service's main loop and to process Cynara requests asynchronously. You can find more information about synchronous and asynchronous API (including examples) in these pages:

In order to make security checks it is required to obtain credentials of client requesting privileged action. In Tizen these are: user id and smack label. Obtaining peer credentials is possible for following IPCs thus making them suitable for performing explicit checks:

  • D-Bus
  • Unix domain sockets
  • kdbus

Cynara provides helper libraries containing functions that facilitate integration:

D-Bus services

In case of D-Bus it's not possible to secure communication by means of setting DAC and Smack permissions as all communication goes through D-Bus daemon which typically is accessible by everyone. However, D-Bus daemon can provide fine-grained control over messages that can be transmitted via its XML policy language [1]. To ease integration with Tizen 3.0 security architecture, D-Bus has been patched so it allows to perform Cynara checks internally. Patched version allows certain messages to be sent to or received by clients having given privilege. You can control what messages can be sent/received depending on message type, interface method/signal name. Such granularity is often enough which means in many cases developer only needs to define service's security policy in the configuration file and service code will not have to be modified.

Explicit Cynara checks in service code might be necessary if:

  • more granular security check rules are required. For instance, different privilege might be needed depending on arguments passed in the method call. Such case cannot be mapped to XML policy language, as highest granularity it can offer if method/signal name
  • concept of session for the service is different than the one assumed by D-Bus daemon, which is based on application's lifetime

You can find more details about integration of Cynara with D-Bus in this wikipage: Cynara D-Bus integration.

Securing access to resources

Every file that contains sensitive data should be protected from unauthorized access. Setting up DAC and Smack might be enough if given resource is going to be used internally by the system. However in some cases applications need to access certain files directly (usually for performance reasons). This is also possible with Tizen 3.0 security architecture. Basically, this mechanism works as follows:

  • Resource is assigned to a supplementary group associated with the privilege
  • Every privilege is associated with a single supplementary group
  • On application start, launcher extends supplementary group list with the ones associated with given application's privileges
  • This means that application's group membership will depend on list of privileges it has. As a result, application will be given direct access to a subset of privileged resources
  • This solution is also compatible with Access Control List which might be required in more complex cases (like giving applications different types of permissions (read, read/write) on a single resource depending on privileges it has)


How to set up resource for direct access

Tracking progress

In this Jira ticket progress of service porting is tracked: Any services that need to be adjusted to Tizen 3.0 security architecture should be reported there. Feel free to report any missing services by creating a new sub-task.