Security/Tizen 2.X Architecture

From Tizen Wiki
Jump to: navigation, search

In this section, we describe Tizen security architecture. All mechanisms and modules are developed basing on this architecture and it should interact with other modules in Tizen, this is very important for all developers.

Access Control & Privilege

Tizen access control & privilege architecture

Access control and privilege architecture is shown in the right picture that contains full flow of system access.

  • During application installation
    • Precondition
      • An application contains its manifest file (native: tizen-manifest.xml, web: config.xml) and required privileges are described.
      • Application is signed by author and distributor and contains signature verification certificates which distinguishes application's privilege level.
    • Installer verifies signature and certificates
      • If failed, installation is denied.
      • If succeeded, installer checks any non-allowed privilege is declared corresponding to the signer certificate.
    • Installer sets up corresponding security policies.
      • Installer changes user ID and group ID for the application's data directory and shared directory.
      • Installer changes Smack label of most files to application ID by calling libprivilege-control APIs.
      • Installer adds privileges into privilege database by calling libprivilege-control APIs.
      • Inside of libprivilege-control, it uses a mapping table from privilege to Smack rules provided by smack-privilege-config and add Smack rules into policy database.
  • During launching (not shown in the picture)
    • Launcher (launchpad daemon) forks a child process, and the child process change UID to 5000 with corresponding groups and change the process Smack label by calling libprivilege-control API.
  • During application runtime
    • Each application is sandboxed by Smack
    • When an application calls an API, the API flow goes to framework by IPC or function call, and privilege management is called to check the API call is allowed or not. User-space access control is also used for access check.
    • Frameworks or system services access the final system resources such as file, database, and socket, and Smack checks the framework or service allowed to access. This feature protects from application direct access.

Application Signing & Certificate

  • Purpose of application signing
    • Guarantee the integrity of application
      - User can download ‘not tampered’ application after developer’s submission
    • Identify application developer
      - Same PackageID and same developer’s signing key guarantee the identicalness of applications
      - A set of applications with same developer’s signing key can share the secured resource as the developer intended
    • Proof of store validation
      - App store distributes an application package after success of particular validation processes.
      - Integrity of the application package is as the store intended.
      - Enforcing proper usage of privileged API.


  • Types of signature
    W3c widget signing.png
    • Author signature (Mandatory)
      - Signed by developer in SDK using developer’s own signing key.
      - Represents trusted-relationship between old and new version of application in upgrade process or trusted inter-application-communication among applications in a device if signed by same developer’s signing key.
    • Distributor signature (Mandatory)
      - Signed by authorized app publisher, such as Tizen Store and operators, using distributor's signing key.
      - Determines privilege level that the signed application can use in accordance with type of signing keys.
    • Distributor 2 signature (Optional)
      - Signed by Operator or others.


  • Application signing and its privilege level
    • The privileges represent the ability to use a certain set of sensitive APIs and secure system resource.
      You can see the Privilege Categories
    • In order to use these APIs except non privilege level APIs
      - the privileges for this APIs should be declared in the application manifest/config file.
      - the distributor signature of an application should be signed by properly privileged signing key.
      If an application is signed by a platform level signing key, the application can use APIs of platform privilege, partner privilege, public privilege, and non privilege.
      If an application is signed by a partner level signing key, the application can use APIs of partner privilege, public privilege, and non privilege.
      If an application is signed by a public level signing key, the application can use APIs of public privilege and non privilege.
      - the signature of an application is verified based on trusted root certificates in a device and each root certificate has its own privilege level.
    • storing signing keys
      - Tizen opened the public, partner, and platform level distributor signing keys to the public. Developers can download these keys from the public git or get these keys from Tizen SDK.
      - If a device manufacturer wants only some privileged developers to be able to install privileged applications to its devices
      , do not reuse the opened partner/platform level root certificates and signing keys
      , generate its own root certificates and signing keys with partner or platform privilege
      , and securely store those keys and securely distribute only to the proper entities based on its own policy.



Go back to Security Model

Continue to Enabling Technologies & Policy