From Tizen Wiki
Jump to: navigation, search

One of the major goals of Tizen is to provide secure devices.

In addition to the traditional UNIX discretionary access control, the security model of Tizen 3 is built over the two specific components Smack and Cynara:

Overview of the Tizen 3 security model:

The objectives of the security

The context

Tizen 3 is intended to run on many embedded platforms, from simple to complex. The most complex platform is probably IVI (In-Vehicle Infotainment), targeting multiple users at the same time with active Wi-Fi and/or BlueTooth and/or 3G connections.

The problem is not the security of the car because the core vehicle system that can be hacked ([1] [2] ) is poorly linked to the infotainment system.

The objectives

There are three primary security requirements that can't be ignored:

  • Application isolation with controlled sharing;
  • Control over privileged resources at the granularity of the application;
  • Multiple users on a device.

The main objectives for ensuring security are:

  • avoiding installations of applications based on user profile or ID;
  • avoiding installations of applications that need specific privileges based on user profile or ID;
  • avoiding uses of specific privileges based on user profile or ID;
  • avoiding applications using unauthorized privileges based on user ID and application manifest (enforce respect of the application manifest);
  • avoiding applications accessing unauthorized data (data of other users, data of other applications, unshared data) based on user ID and application manifest;
  • avoiding applications that break the system.

The basics of Tizen 3 security model

The objects

The objects identified as important for security are:

  • Applications
    • Web Applications: Despite the name (which suggests that these applications are built using Web technologies 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 webruntime.
  • Services: Special 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: These well known objects are under the control of discretionary and mandatory access rules (DAC and MAC). Unix sockets and other sockets should also be mentioned here.

The privileges

Some services are sensitive. For example, reading or sending an SMS on a phone is sensitive. Would you accept any application to send SMS? No.

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.

Tizen 3 defines several privileges [3].

The creators of applications must specify needed privileges (what services their application will need). This is done in the manifest [4] [5] of the application.

Note: The Tizen 3 model can't check statically if a developer is lying on the requested privilege of the application (i.e. if the application is using undeclared privilege). This check is dynamic.

Installing applications

Applications can be downloaded and installed after being packaged. The packaging process embeds expected privileges (and other security concerns as origin, signature, integrity, ...) in the package.

Note: package refers to the combination of the application, its manifest and its data. Application refers to only the application.

The packaged application is installed by the Tizen 3 installer.

The installer:

  • confirms the current user has the right to install packages;
  • checks the integrity of the package;
  • reads the requested privileges and, if needed, asks the user for validation;
  • installs the package in the system (if the installation is allowed):
    • computes its security items using its ID and its privileges;
    • unpacks it to the local storage;
    • records it to the db of installed applications;
    • updates the system to accept the new package.

Running applications

The applications can be run once installed.

The Tizen 3 model doesn't enforce application isolation using containerization; isolation is ensured using Smack and DAC.

Because privileges are managed (see the following) the enforcement of the respect of the privilege is made by the services using Cynara.

Managing privileges

Privileges are granted to applications following several modes:

Blanket Prompt
User is prompted for confirmation the first time the API function is called by the widget, but once confirmed, prompting is never again required.
Session Prompt
User is prompted once per session.
One-Shot Prompt
User is prompted each time the restricted API is invoked.
Use of the device capability is always permitted, without asking the user.
Use of the device capability is always denied.

The privilege manager can be used at any time to change granted permissions.

The means of Tizen 3 security

To achieve the security model, Tizen 3 uses:

  • Discretionary Access Control (DAC): File System permissions and Access control list (ACL);
  • Mandatory Access Control (MAC) with the kernel LSM Smack;
  • Cynara permission management and check service.

The details of Tizen 3 security model

Every application has its own Smack label and run it

At installation, each application receive a Smack label in a one-to-one relation with its ID. For example, the application of ID A7z8ert9y receives the Smack label User::App::A7z8ert9y.

By principle, the application is running with its Smack label as Smack context.

This is necessary to achieve application isolation: any object kernel accesses are checked using Smack rules with the Smack context as subject AND any created object kernel (files or directory) by default receives the object Smack label of the context. The objects of the application are tagged as such.

This is true for both web and native applications. The Smack label, being unique to the application, is used to identify the application (by Cynara for example) as well as to provide access controls (by Smack . By default applications can't access the objects of the other applications).

Note: system utilities like the command ls(1) and the services are not applications, so their Smack labels follow other rules.

Linux kernel objects are controlled using DAC and MAC

Linux kernel objects accesses are controlled using UIDs, GIDs and Smack labels.

The application installers can be taught association between application privileges and the security attributes on specific objects.

If an application is granted a privilege it is also possible to set the Smack policy to allow direct access to one or more of these well-known objects.

At this level operates the separation between users using DAC restrictions.

Every application is checked for its privileges using Cynara

An application may be assigned a set of application privileges. This association is initially made by the application installer and may change over time.

This is true for both web and native applications.

When running, the accesses of the application to the privileged services are dynamically checked against the current authorizations and policy of the database mainly on the base of the application id and user but also using a session id (see [6]).

This is the role of Cynara to check the privileges.

How is Cynara invoked?

The API used by programs (specifically the Core API) are modified to have a user part and a system part communicating through a Unix Domain Socket or DBUS.

     PROGRAM           .     SERVICE
+------------------+   .    +--------+
| PROG ---- LIB ---+---.----+- CORE  |
+------------------+   .    +--------+
    user domain        .   system domain


The use of services is subject to privilege in the Tizen model.

Service developers, please check the page on analysing security privileges of tizen services.

Implementation in Tizen 3.0 2015.Q2

The security model is described in at least 3 major places:

  • the default setting (project platform/core/security/default-ac-domains)
  • the setting for applications (project platform/core/security/security-manager)
  • the skeleton of users (project platform/core/appfw/tizen-platform-config)

The default setting

PROJECT: platform/core/security/default-ac-domains

This is set using the file packaging/default-ac-domains.manifest that through the MSM plugin of rpm produces the file /etc/smack/accesses.d/default-ac-domains.

# cat /etc/smack/accesses.d/default-ac-domains
System _ -----l
System System::Log rwxa--
System System::Run rwxat-
System System::Shared rwxat-
System ^ rwxa--
System User rwx---
_ System::Run rwxat-
_ System -wx---
^ System::Log rwxa--
^ System::Run rwxat-
^ System rwxa--
User _ -----l
User User::App::Shared rwxat-
User User::Home rwxat-
User System::Log rwxa--
User System::Run rwxat-
User System::Shared r-x---
User System -wx---

the setting for applications

PROJECT: platform/core/security/security-manager

The security-manager creates the rules for each installed application using the files of the sub-directory policy installed in the directory /usr/share/security-manager/policy/.

In particular, the file app-rules-template.smack is:

# cat /usr/share/security-manager/policy/app-rules-template.smack
System ~APP~ rwx
~APP~ System wx
~APP~ System::Shared rx
~APP~ System::Run rwxat
~APP~ System::Log rwxa
~APP~ _ l
User ~APP~ rwxa
User ~PKG~ rwxat
~APP~ User wx
~APP~ User::Home rxl
~APP~ User::App::Shared rwxat
~APP~ ~PKG~ rwxat

The security manager replaces ~APP~ and ~PKG~ by the installed values and places it in the directory /etc/smack/accesses.d/. Example for the "toy" application Mancala:

# cat /etc/smack/accesses.d/app_yKrWwxz1KX.mancala
System User::App::yKrWwxz1KX.mancala rwx---
User::App::yKrWwxz1KX.mancala System -wx---
User::App::yKrWwxz1KX.mancala System::Shared r-x---
User::App::yKrWwxz1KX.mancala System::Run rwxat-
User::App::yKrWwxz1KX.mancala System::Log rwxa--
User::App::yKrWwxz1KX.mancala _ -----l
User::App::yKrWwxz1KX.mancala User -wx---
User::App::yKrWwxz1KX.mancala User::Home r-x--l
User::App::yKrWwxz1KX.mancala User::App::Shared rwxat-
User::App::yKrWwxz1KX.mancala User::Pkg::yKrWwxz1KX rwxat-
User User::App::yKrWwxz1KX.mancala rwxa--
User User::Pkg::yKrWwxz1KX rwxat-

the skeleton of users

PROJECT: platform/core/appfw/tizen-platform-config

The skeleton files are created in the packaging using the following definitions that set mode, access label and transmutation:

MODE 777
SMACK System::Shared true
MODE 700
SMACK User::Home true
SMACK User::App::Shared true
SMACK User false

For example on a target:

# ls -lZd $(find /etc/skel/)
drwx------.  6 root root User::Home        4096 juin   7 04:34 /etc/skel/
drwxr-xr-x.  6 root root User::Home        4096 juin   7 04:34 /etc/skel/.applications
drwxr-xr-x.  2 root root User              4096 juin   7 04:34 /etc/skel/.applications/dbspace
drwxr-xr-x.  2 root root User              4096 juin   7 04:34 /etc/skel/.applications/desktop
drwxr-xr-x.  2 root root User::Home        4096 juin   7 04:34 /etc/skel/.applications/icons
drwxr-xr-x.  2 root root User              4096 juin   7 04:34 /etc/skel/.applications/manifest
drwxr-xr-x.  2 root root User              4096 juin   7 04:34 /etc/skel/apps_rw
drwxr-xr-x. 10 root root User::Home        4096 juin   7 04:34 /etc/skel/content
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Camera
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Documents
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Downloads
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Games
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Images
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Others
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Sounds
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/content/Videos
drwxr-xr-x.  2 root root User::App::Shared 4096 juin   7 04:34 /etc/skel/share

Currently studied evolution

In /etc/smack/accesses.d/default-ac-domains:

System User::App::Shared rw-a--
System User::Home rw-a--
User System::Shared r-x--l


The old presentation of Onur Accicmez and Andrew Blaich.