Security/Tizen 2.X Security Model

From Tizen Wiki
Jump to: navigation, search

In this section, we introduce Tizen security model. This will help all the developers understand why and how the Tizen security is implemented, and support them in development of security aware platform.

Trust model

Establishing trust model of a platform is one of the most important task for such platform because this is the anchor of all the security mechanisms and policies. Tizen trust model goes as follows

  • Kernel is trusted. However, secure boot is out of scope since it is manufacturer specific.
    • All information created by kernel is also trusted such as data in /proc, credential for IPC (SO_PEERSEC, SO_PEERCRED), and so on.
    • Kernel access control mechanism is also trusted. This trust implies that we trust file system access control information such as owner and permissions as well as POSIX capabilities. However, guaranteeing file system integrity is out of scope.
    • Trusting file system image is out of scope. This is manufacturer specific.
    • Since we trust kernel, any modification of Linux kernel could introduce system vulnerablility, and manufacturer is responsible for the issue.
  • User is NOT trusted even though user owns the device.
    • Application developer is not trusted either. Therefore SDK developing and debugging interfaces are not trusted.
  • Trust of an application depends on the trust of Certificate Authorities/Providers which signed the application package.

User's Privileges

User acts as a main role of Tizen security life cycle. It is very important to setup privileges of the user. User's privileges of Tizen is different than normal Linux distro's user's privileges because we don't fully trust the user.

  • User has full privileges to graphical user interface (GUI) of the device as well as physical UIs including screen, touch input, keyboard, and hardware buttons.
    • However, some applications can limit GUI components based on their usage scenario.
  • User does not have root privileges and no POSIX capability as well.
    • User can invoke privileged action by legitimate applications. For instance rebooting the device requires privilege, but it is allowed when user presses the power button.
    • User cannot modify or delete system files because most of them requires root privileges. For the same reason user cannot send signals to system services.
    • In some cases, system may allow user to get the privileged access to the system based on the usage scenario. However, this is completely manufacturer specific and not recommended. manufacturer is responsible for possible security breaches caused by such vulnerability.
  • User can install applications which are signed by trusted certificate chain.
    • User can modify application data only by the application itself or package update.

Application's Privileges

Unlike user, application operates directly on the system. It's even more important to carefully establish the security model of the application's privileges.

  • All applications are allowed to use basic graphical user interface (GUI) functionality that allows them to draw windows and get input from user.
    • However, GUI functions can be limited by system based on the usage scenario.
  • Applications do not have root privileges and no POSIX capability as well.
    • There may exist some special usage scenarios which requires privileged access for some applications. This is completely manufacturer specific, but it's not recommended to give root privileges or POSIX capabilities to applications, and manufacturer is responsible for possible security breaches caused by such vulnerability.
  • Applications are only allowed to create and write files in their own data directories. Usually, /opt/apps/[pkgid]/data
    • Applications cannot modify or remove their own files which are delivered by application package and installed by installer.
    • System resources are basically read only, but some of them are protected and require application privileges to access.
  • An application can only acquire privileges declared in its manifest.
    • Privileges are bounded by the certificate that is used for signing.

Application Sandboxing

In Tizen, each application has its own business and security requirements so it is important to provide a secure environment for each application that is protected from other applications.

  • Basically, an application is only allowed to access its own files.
    • All of the application's files except data directories are read-only for the application itself.
    • User's Home directory /opt/home/app is basically allowed to write files, but some of them are read only based on usage scenario.
  • Sharing data between applications is only allowed by methods which are provided by Tizen platform
    • In case of Tizen 2.3, application can use:
      1. messageport,
      2. datacontrol,
      3. and shared directory.
    • Any IPC mechanism between applications such as socket, message queue, shared memory, and signal are not allowed.


Note: Shared directory will be deprecated soon and there will be different file sharing mechanism.

System Resources

Protecting system resource is one of the most important goals of platform security. System resources of Tizen are carefully protected and maintained by following security model.

  • Tizen follows basic principles of Linux system resource protection model.
    • Most of the files are owned by root.
    • File permissions and group ID are used for fine-grained access control.
  • Default policy for system resource is read-only. Most of the system files such as device nodes, shared libraries, system utilities, platform files are readable for all.
    • Some of the system resources can be read-write allowed such as /dev/null, /dev/zero, /dev/random and /tmp.
    • Some of the system resources can be protected from unauthorized reading and only authorized entities can access them.
  • Platform services (daemons) are separated.
    • Each platform service runs in a sandboxed environment and has least privileges.
    • System files that are accessed by a service are also sandboxed and protected.
  • Internet access is also protected and only authorized entities can send and receive data to and from the Internet.

Go back to Overview

Continue to Architecture