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:
- Smack (Simplified Mandatory Access Control Kernel) provides strong isolation of items at the kernel ground
- Cynara (Latin word for artichoke) provides privilege management and check.
Overview of the Tizen 3 security model:
- 1 The objectives of the security
- 2 The basics of Tizen 3 security model
- 3 The details of Tizen 3 security model
- 4 Implementation in Tizen 3.0 2015.Q2
- 5 Links
The objectives of the security
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.
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 identified as important for security are:
- 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.
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 .
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.
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.
- 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.
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.
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 ).
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
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
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
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 $TZ_SYS_STORAGE $TZ_SYS_MEDIA
MODE 700 SMACK User::Home true $TZ_USER_HOME $TZ_USER_APPROOT $TZ_USER_ICONS $TZ_USER_CONTENT
SMACK User::App::Shared true $TZ_USER_CAMERA $TZ_USER_DOCUMENTS $TZ_USER_DOWNLOADS $TZ_USER_GAMES $TZ_USER_IMAGES $TZ_USER_OTHERS $TZ_USER_SOUNDS $TZ_USER_VIDEOS $TZ_USER_SHARE
SMACK User false $TZ_USER_APP $TZ_USER_DB $TZ_USER_DESKTOP $TZ_USER_PACKAGES
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
System User::App::Shared rw-a-- System User::Home rw-a-- User System::Shared r-x--l
- Package and applications