Security/Tizen 3.X Overview

From Tizen Wiki
Jump to: navigation, search
Smack Cynara and DAC diagram

Introduction

In this section, overview of Tizen security including security objectives, possible threats and basic security policies is presented. Principles of Tizen 3.X Security are introduced and some differences to the previous version (Tizen 2.X) are discussed.

Tizen 3.X is a multi user operation system based on Linux kernel, which targets a wide range of devices like smartphones, smart TVs, smart watches and other smart devices (such as refrigerators, washing machines), tablets and last but not least IVI (in-vehicle infotainment) devices. The diversity of supported target systems is implemented using dedicated profiles. All of the profiles are supported by Tizen 3.X security framework – which is possible due to its multi-layered composite design. However, one should be aware that on simple platforms running on simple equipment (such as wearable) some Tizen 3.X security features are not present or are realized differently (for instance the SMACK might not be present).

Security Requirements for Tizen 3.X

The primary security requirements for Tizen 3.X platform are:

  • Support for multiple users on a device.
  • Application isolation with controlled inter application resource sharing.
  • Privilege control at the granularity of the application.

Threats

Every Tizen 3.0 device is exposed to different kinds of threats caused by malicious or imprudent users, application developers, external systems (for instance application stores).

Each device might also be a subject to physical security vulnerabilities. However, the physical protection of devices is generally not addressed by Tizen 3.X security framework (there are some exceptions like: secure data storage using Key Manager).

The security framework is supposed to deal with information security threats such as:

  • Creation of malicious application (a virus, worm, Trojan or phishing app) by a developer.
  • Creation unauthorized app stores.
  • Distribution of malicious applications in authorized and unauthorized shops.
  • The violation of digital rights management (DRM) content protection by a device user.
  • Tricking the app user (such as in-application payment).
  • Theft of information belonging to the user.
  • Unauthorized access to system resources or services might be granted to malicious users/applications.

The goals of Tizen 3.X security framework is to prevent the listed above attacks and similar attacks.

Security Objectives

In order to prevent above threats system resources and external tools need to be secured (such as: development environment, system services, shared libraries, system files and databases, kernel and kernel drivers, boot loaders). Tizen 3.X security framework goal is to provide a tool set make it possible.

The security objectives are:

  • Application is installed based on application specific settings and permissions (not user profile or ID).
  • Application privileges are granted based on the application configuration (such as manifest) and the decision of the user.
  • Access to unauthorized privileges is prohibited. Respect to the application manifest is enforced.
  • Breaking the system by an application is avoided.
  • Unauthorized access to data of other users and other applications is avoided.
  • Breaking the system by an application is not possible.
  • Usage of specific privileges based on user ID or user profile is avoided.

Three Pillars of Tizen 3.X Security: DAC, SMACK and Cynara

The security in Tizen 3.x is founded on usage 3 components:

  • Smack
  • DAC
  • Cynara

Two of them (Smack and DAC) were also used in Tizen 2.X, but in different way. Smack is mandatory access control (MAC) system of choice in Tizen. It was present also in series 2.x, but in Tizen 3.0, the rule set and their use is much reduced. Discretionary access control (DAC) is a classic security mechanisms in Unix. It depends on user and group ids and permissions set across of the filesystem. There is also a new security daemon – Cynara. Cynara is a security control point granting applications an access for services and resources. It’s meant to be used by system services to check, if they should grant access to their resources for their clients. Cynara’s database is populated by Security Manager from a number of sources.

Three Domain Policy

Domains: Floor, System and User

In Tizen 2.X, there were many SMACK labels and even more rules which described access rights. It has been simplified in Tizen 3.X.

Three domain policy is a new concept of Smack usage in Tizen 3.X. It implies existence of 3 groups of labels, so called domains: Floor, System and User. Objects inside individual domains have, by default, free access to each other, but cross-domain access is restricted and strictly controlled.

Please notice that there are more SMACK labels than three, each application has has its own SMACK label. However, the number of Smack rules in Tizen 3.X is smaller than in Tizen 2.X (part of rules is stored in Cynara). This smaller number of rules makes the configuration easier to maintain.

More information on Three Domain Policy (including Floor, System, User domains) can be found on the page.

Basic Security Policy

A policy is a set of rules. The rules determine objects’ access rights to resources. The objects recognized by Tizen 3.X security framework are:

  • Objects and resources
    • Applications
      • Web Applications: Despite the name (which suggests that these applications are running in the cloud, the applications just happen to use same technologies like web apps: HTML+CSS+JS), these applications are installed on the platform. They are run by the web runtime component (Crosswalk).
      • Native Applications: These applications are also installed. They are not run by web runtime.
      • Services: Special native applications that are dedicated to providing platform specific access to a resource. For example, connectivity (Wi-Fi, BT, 3G), GPS positioning, and accelerometers are services. SMS/MMS is a service on a phone. Many services are common to all applications or users and must manage either the sharing or the attribution of resources, ensuring that data of one user/application is not visible to others.
    • Utilities: Utilities are programs that are part of Tizen distribution. Most of the standard unix commands like ls are utilities.
    • Files, Directories, device special files, unix sockets. These well known objects are under the control of discretionary and mandatory access rules (DAC and MAC).
  • Privileges Some services are sensitive and should not be available to all applications. For example, reading or sending an SMS on a phone is sensitive, because an incoming SMS might contain secrete (private) information and sending a SMS usually costs money. It means that this functionality shall not be available to all applications, but only to those which were approved by the user (during installation, at runtime, or at purchase - in case of pre-installed apps). Most services expect the calling applications to have access to their sensitive resource, in other words, that the calling applications have the privilege to use it.

Sources of Policies

Policy in Tizen 3.X is determined by file Smack labels (these might be determined by installer or package manager), the default set of smack rules (specified in the file /etc/smack/accesses.d/default-ac-domains) and privilege rules specified by Security Manager and stored by policy manager Cynara. Cynara as a control point of security policies keeps a database of rules. The database is populated by Security Manager from multiple sources, such as applications’ manifests, Privacy Manager, and built-in and administrators’ rules.

Cynara input data

The default (built-in) Smack configuration as of November 2016 contains following rules:

  1. System _ rwx---
  2. System User::App::Shared rwxat-
  3. System User::Home rwxat-
  4. System System::Log rwxa--
  5. System System::Run rwxat-
  6. System System::Shared rwxat-
  7. System System::Privileged rwxat-
  8. System ^ rwxa--
  9. System User rwx---
  10. System User::Shell rwxat-
  11. _ System::Run rwxat-
  12. _ System -wx---
  13. _ System::Privileged -wx---
  14. System::Privileged _ rwx---
  15. System::Privileged User::App::Shared rwxat-
  16. System::Privileged User::Home rwxat-
  17. System::Privileged System::Log rwxa--
  18. System::Privileged System::Run rwxat-
  19. System::Privileged System::Shared rwxat-
  20. System::Privileged System rwxat-
  21. System::Privileged ^ rwxa--
  22. System::Privileged User rwx---
  23. System::Privileged User::Shell rwxat-
  24. ^ System::Log rwxa--
  25. ^ System::Run rwxat-
  26. ^ System::Privileged rwxa--
  27. ^ System rwxa--
  28. User User::App::Shared rwxat-
  29. User User::Home rwxat-
  30. User System::Log rwxa--
  31. User System::Run rwxat-
  32. User System::Shared r-x--l
  33. User System::Privileged -wx---
  34. User System -wx---
  35. User User::Shell rwxat-
  36. User::Shell User::App::Shared rwxat-
  37. User::Shell User::Home r-x--l
  38. User::Shell User -wx---
  39. User::Shell System::Log -w----
  40. User::Shell System::Run r-x--l
  41. User::Shell System::Shared r-x--l
  42. User::Shell System -wx---

Cynara: integration with services

Integration of Cynara with services

In Tizen 3.X, there is a number of services with restricted access (e.g. GPS, address book, etc.). These services need to know, to which client apps the access should be granted.

Instead of maintaining large sets of rules by each service, the services are required to call Cynara (via dedicated API) to check the access rules for triples of user, application and permission, i.e:

“Do app of Maps, ran by user Susan has access to GPS location?”.

Cynara queries its database (which was populated by Security Manager) and yields answer of “yes” or “no”.

Sometimes there may be some extensions (such as popups) involved in process of obtaining answer, but at the end, the original service always gets a binary yes or no reply.

Cynara is optimized in many ways (for instance it caches the answers, whenever possible) so the service performance (the response time) is not affected strongly. The correctness of the answers is dependent on the rules provided by Security Manager.

Security Manager

Security Manager (SM) is a privileged daemon, which glues all 3 pillars of security in Tizen 3.X SM is involved in:

  • Installing apps – populates Cynara database, labels files, creates labels for pkgids
  • Launching apps – applies security context (app label, effective groups) for AMD
  • Managing security policy – editing rules by admin and users (PrivacyManager)
  • Managing users in system

Secure Application Life Cycle

Tizen Secure App Life Cyclel

The secure application life cycle is not operating as of March 2015. As shown in the picture, application life cycle contains the following security measures

  • In SDK
    • Application signing: Application shall be signed by author during application development to authenticate the application's origin.
  • In Store
    • App store signing: App store shall perform validation check, and after success signs with distributor's key to confirm that the application is allowed for distribution.
  • During installation
    • Anti virus check: Device checks the application package with possible anti-virus engine if exist.
    • Signature verification: Distributor signature and author signature are checked along with certificates to verify the application package.
    • Privilege check: Application privileges are verified basing on certificates.
  • During execution
    • Sandboxing: Each application is isolated and access controlled.
    • Access control (not shown in the picture): Important system resources are access controlled using DAC and MAC (Smack) mechanisms. The policies are being stored in DAC access rights and Cynara data base.
Application lifetime table

The table summarizes the cooperation of the three security mechanism (DAC, SMACK and Cynara) during the application lifetime.

  • During installation, newly created files are marked with the correct access rights and SMACK labels (for instance the label of the package). During this phase the Security Manager saves new rules in Cynara database.
  • During launching, the new process (or processes) are being created. Security Manager sets its effective group ids so that the process(es) should have access to the special files and sets its SMACK label
  • During runtime application might request performing action by a service (Runtime(1)) or access to file system (a file or a raw device (Runtime(2)). In the first case application process Smack label is used by Cynara to check whether the access shall be granted. In the second case the filesystem check based on filesystem discretionary access control (user and group id based permissions) and mandatory access control (Smack) is performed.

Application Singing and Certificates

Application signing is the process of digitally signing executables, scripts, and contents of an application to confirm the application author and guarantee that the application has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity. Tizen requires that all application be digitally signed with a proper signing key and certificate before they call be installed.

Goals of application signing

Through the application signing, Tizen achieves the following goals.

  • Ensuring application integrity: Users can download a ‘not tampered’ application after development.
  • Identifying application developer: The applications with a same signing key are regarded as an identical developer developed them. A set of applications with same developer’s signing key can share the secured resource as the developer intended.
  • Proof of store validation: An app store performs some validation checks before distributing application. As the proof of store validation, the app store signs the application.
  • Enforcing proper usage of privileged APIs: An application distributor such as an app store can restrict the API set used by the application by with a signing key with a proper privilege.

Signature type

All Tizen applications must have at least 2 signatures, author signature and distributor signature.

Signature Type

  • Author signature
- Author signature is signed by a developer with his or her own author signing key in SDK.
- Applications with a same author signing key are regarded as developed by an identical developer.
- Application upgrade is allowed only when the author signature of the old version and the new version is signed with a same author signing key.
- A set of applications with a same author’s signing key can share the secured resource as the author (developer) intended.
  • Distributor signature
- Distributor signature is signed by a distributor such as Tizen store as the proof of application validation.
- Distributor signature determines the API set that can be used by an application.

Certificate and API Privileges

Tizen API privileges represent the ability to use a certain set of sensitive APIs and secure system resource. The privileges are categorized into 3 levels according to their security and privacy level.

- Public level: used by any application developers.
- Partner level: used by developers with a business relationship with a device vendor.
- Platform level: exclusively used by a device vendor.

For an application to use a privileged API, the distributor signature must be generated from a certificate (and its signing key) with a proper privilege level. If an application has a distributor signature generated from a partner level certificate (and its signing key), the application can use only public and partner level APIs. The following table shows the relationship between the certificate (and signing key) privilege level and the API privilege level.

Certificate Privilege Level Public level API Partner Level API Platform Level API
Public Level O X X
Partner Level O O X
Platform Level O O O

Signing Flow and Getting certificates

Application Signing Flow

An application developer can sign an application with his or her own author signing key and testing distributor signing key in SDK. And the developer can install and test the application on his or her test device and an emulator. When the application is submitted to a store after development, the store removes the testing distributor signature and adds the store distributor signature for application release. Normal applications are signed with the public level distributor signing key in the store. Some applications granted from a device vendor are allowed to be signed with the partner level distributor signing key. Singing with the platform level distributor key is permitted only for the internal application of a device vendor or Tizen.

The testing distributor certificate and its signing key with the public level are preloaded in SDK and the author certificate and its signing key can also be created in SDK(Certificate Registration ). But a device vendor may disallow unauthorized applications to be installed to its devices to protect its devices from viruses and malwares. Samsung also disallows unauthorized applications to be installed to its Tizen devices. In such case, a developer should get an author certificate and a distributor certificate from the device vendor. To get more detailed information, see Issuing a Tizen Certificate and Running Applications in Commercial Devices at Tip and Tech.

Signature Specification

The application signing scheme of Tizen follows the specification of XML Digital signature for widget specified by W3C(http://www.w3.org/TR/widgets-digsig/). Signature File Structure

System directories and variables

In order to introduce some order in the Tizen system (more specifically to handle variables definition for given profile/platform) a project Tizen configuration is created (its name is 'tizen-platform-config'). The source code of this project is available on tizen gerrit server.. The file with the actual configuration in tizen-platform-config is tizen-platform.meta. It is bash compliant (so easy to read, comments allowed) variables are all named TZ_XXXX_YYYY[_ZZZZ...], with XXXX being the domain (SYS, USER, SDK, ...) and YYYYY being the subject. The versions for single_user, multiple user are kept in one files and are switched between using commenting/uncommenting the lines.

Of course the definitions set in this file might be overriden for a given profile or by an OEM for device customization

Rules for defining variables: syntax is bash compliant (comments, spaces, empty lines ... are accepted) a TZ variable may depend on another previously defined TZ variable a TZ variable may depend on some restricted dynamic variables (expressed in source file but only known at runtime)

Authorized dynamic variables are actually restricted to: HOME: the actual user home dir (read from /etc/passwd) USER: the actual user name (read from /etc/passwd)

The platform variables are defined in a single location and may be used in multiple environments :

  • in source code (using the wrapper library that comes with tizen-platform-config for easier access and runtime resolution)
  • in spec files using macros
  • in spec files (post-install) by sourcing the /etc/tizen-platform.conf file which is bash compatible and using the $TZ_XXX vars
  • in any shell script, at build time or run time

SYSTEM VARIABLES

Base dirs

Variable Name Single User Value Multi User Value Description
TZ_SYS_HOME /home /home Path to a folder containing user home directories.
TZ_SYS_ROOT /opt/home/root /root Path to the root home directory.
TZ_SYS_SHARE /opt/share /usr/share Path to directory, which contains subdirectories with specific application data, that can be shared among applications.
TZ_SYS_ETC /opt/etc /etc Path to directory, which contains configuration files.
TZ_SYS_DATA /opt/data /usr/data Path to directory, which contains subdirectories with specific application data, that are not shared among applications.
TZ_SYS_BIN /usr/bin /usr/bin This is the primary directory for executable programs.
TZ_SYS_SMACK /opt/etc/smack /etc/smack Path to directory, which contains SMACK configuration files.
TZ_SYS_STORAGE /opt/storage /usr/storage Path to directory, which contains subdirectories with specific application data (notshared).
TZ_SYS_USER_GROUP app users Name of system users group.
TZ_SYS_GLOBALAPP_USER tizenglobalapp Name of a user on whose account global applications are installed.
TZ_SYS_ADMIN_GROUP system Name of a group of users who have system administrative privileges.
TZ_SYS_DEFAULT_USER guest mpath which user to use when applications start request are sent by system daemons.

Core & Framework dirs

Variable Name Single User Value Multi User Value Description
TZ_SYS_APP_PREINSTALL /opt/usr/apps/.preinstallWidgets /opt/usr/apps/.preinstallWidgets  ?
TZ_SYS_DB /opt/dbspace /usr/dbspace Path to directory, where application databases are stored
TZ_SYS_CONFIG /opt/var/kdb /usr/kdb
TZ_SYS_DEBUG_PORT 9222
TZ_SYS_RW_APP /opt/apps /usr/apps
TZ_SYS_RO_APP /usr/apps /usr/apps
TZ_SYS_RW_ICONS /opt/share/icons /usr/share/icons
TZ_SYS_RO_ICONS /usr/share/icons /usr/share/icons
TZ_SYS_RW_WIDGET /opt/share/widget /usr/share/widget
TZ_SYS_RO_WIDGET /usr/share/widget /usr/share/widget
TZ_SYS_RW_DESKTOP_APP /opt/share/applications /usr/share/applications
TZ_SYS_RO_DESKTOP_APP /usr/share/applications /usr/share/applications
TZ_SYS_RW_WRT_ENGINE /opt/share/wrt-engine /usr/share/wrt-engine
TZ_SYS_RO_WRT_ENGINE /usr/share/wrt-engine /usr/share/wrt-engine
TZ_SYS_RW_PACKAGES /opt/share/packages /usr/share/packages
TZ_SYS_RO_PACKAGES /usr/share/packages /usr/share/packages
TZ_SYS_WRT_CONF /usr/etc/wrt
TZ_SYS_WRT_PLUGINS_CONF /usr/etc/wrt-plugins /etc/wrt-plugins
TZ_SYS_TIZEN_APIS_CONF /usr/etc/tizen-apis /etc/tizen-apis
TZ_SYS_ACE_CONF /usr/etc/ace /etc/ace
TZ_SYS_RW_UG /opt/ug /usr/ug
TZ_SYS_RO_UG /usr/ug /usr/ug
TZ_SYS_RUN /var/run

SDK

Variable Name Value Description
TZ_SDK_USER_NAME developer
TZ_SDK_HOME /home/developer
TZ_SDK_TOOLS $TZ_SDK_HOME/sdk_tools

USER VARIABLES

Base dirs

Variable Name Single User Value Multi User Value Description
TZ_USER_NAME app $USER
TZ_USER_HOME $TZ_SYS_HOME/app $HOME
TZ_USER_SHARE /opt/usr/share $TZ_USER_HOME/share
TZ_USER_DATA /opt/usr/data $TZ_USER_HOME/data
TZ_USER_ETC /opt/usr/etc $TZ_USER_HOME/etc
TZ_USER_LIVE /opt/usr/live $TZ_USER_HOME/live
TZ_USER_UG /opt/usr/ug $TZ_USER_HOME/ug

Core & Framework dirs

Variable Name Single User Value Multi User Value Description
TZ_USER_APP /opt/usr/apps $TZ_USER_HOME/apps_rw
TZ_USER_APPROOT $TZ_USER_HOME/.applications
TZ_USER_CONFIG /opt/var/kdb $TZ_USER_HOME/kdb
TZ_USER_DB /opt/user/dbspace $TZ_USER_APPROOT/dbspace Path to directory storing global databases
TZ_USER_DESKTOP $TZ_USER_APPROOT/desktop
TZ_USER_PACKAGES $TZ_USER_APPROOT/manifest
TZ_USER_ICONS $TZ_USER_APPROOT/icons

Content dirs

Variable Name Single User Value Multi User Value Description
TZ_USER_CONTENT /opt/usr/media $TZ_USER_HOME/content Path to a folder dedicated to user content storage (in subfolders)
TZ_USER_CAMERA $TZ_USER_CONTENT/Camera $TZ_USER_CONTENT/Camera Path to a folder dedicated to user camera pictures storage
TZ_USER_VIDEOS $TZ_USER_CONTENT/Videos $TZ_USER_CONTENT/Videos Path to a folder dedicated to storage of user videos
TZ_USER_IMAGES $TZ_USER_CONTENT/Images $TZ_USER_CONTENT/Images Path to a folder dedicated to storage of user images
TZ_USER_SOUNDS $TZ_USER_CONTENT/Sounds $TZ_USER_CONTENT/Sounds Path to a folder dedicated to storage of user sound files
TZ_USER_GAMES $TZ_USER_CONTENT/Games $TZ_USER_CONTENT/Games Path to a folder dedicated to storage of content used in games of the user
TZ_USER_DOCUMENTS $TZ_USER_CONTENT/Documents $TZ_USER_CONTENT/Documents Path to a folder dedicated to storage of user documents
TZ_USER_OTHERS $TZ_USER_CONTENT/Others $TZ_USER_CONTENT/Others Path to a folder dedicated to storage of other user content
TZ_USER_DOWNLOADS $TZ_USER_CONTENT/Downloads $TZ_USER_CONTENT/Downloads Path to a folder dedicated to store files downloaded by the user

List of all Tizen 3.X related security pages