Security:SmackThreeDomainModel

From Tizen Wiki
Jump to: navigation, search

Why Three Domains

Tizen uses Smack to control how the various processes share information. Understanding how the information is used and why it needs to be shared ensures that information is shared appropriately. Without a clear understanding of the relationships between processes it is difficult to determine what information should or should not be shared.

There are two fundamental kinds of data on a Tizen system:

  • User data is owned and controlled by the end user.
  • System data is not changed by the end user.

The simplest possible security model provides two domains: one for system processes and data and the other for user processes and data. Creating all new user software is ideal, but preexisting behavior makes it impractical. For example, user processes need to get information from system processes and to request the system to take actions on the user's behalf.

Smack enforces access controls at a coarse granularity. The granularity is roughly the same as traditional Linux access controls. The simplest way to look at accesses between domains is to determine if one domain needs to read from the other, or if the two domains need to send messages back and forth. Ideally, a pair of domains should do one or the other but not both.

User processes need to look at some system data and communicate with some system processes. It is practical to split the system data into the part that everyone needs to read and the part that communicates with user processes. This results in three domains:

  1. "User" : User domain for user processes and data
  2. "System" : System domain for system processes and their private data
  3. "_": Floor domain for static public data.

Domains, User IDs and Privilege

Tizen uses Smack along with traditional Linux security mechanisms. User IDs identify different people who may use a device. The system user root owns most of the system controlled files. Users are given their own user IDs, allowing them to share or protect information. Until the multiple user support is available there is a single non-system user.

Tizen uses the traditional Linux superuser privilege model with some restrictions based on the Linux POSIX capabilities model. Tizen may move to a pure POSIX capability model in the future. A process that runs with the user ID or root or with any set of POSIX capabilities is considered privileged. A process that is privileged with regard to Smack will run as root or have one of CAP_MAC_ADMIN or CAP_MAC_OVERRIDE .

Within a Smack domain user IDs and privilege will be the same, with a few exceptions. The System domain is composed primarily of privileged processes, running with the root user ID. Where practical, System domain processes will change user ID and drop privilege. The User domain is composed primarily of unprivileged processes, running with a person's user ID. On occasion there will be components of the User domain that requires privilege and will run as root.

Differences Between Tizen 2 and Tizen 3

In Tizen 2, security domains are assigned based on installation packages. All files and directories created by the package are put into a domain specified in the package manifest file. All programs in the package are installed to execute in that domain using the SMACK64EXEC file attribute.

In Tizen 3, security domains are explicitly defined in advance by a team of security experts. Domains are defined in terms of the function they perform. Rather than assuming a package defines a domain, specific domains are initiated by systemd as it launches services. The role of packaging is significantly reduced. System files are stored where they can be used by any domain and only domain specific data needs to be identified.

Motivation

Smack Three Domains Model was designed to meet following goals:

  • making Smack rules clearer and easier to manage - simple separation of domains and clear rules between them makes rules maintenance easier and less error prone;
  • decreasing number of Smack rules - makes loading rules at boot-time and processing in run-time faster;

Possibility of using Tizen 3 platform for setting multi-user environment excludes usage of Smack as the only privilege access control mechanism. That is why strict cooperation with Cynara is needed.

These two mechanisms pay major role in Tizen 3 security (Security Overview). Smack Three Domains Model defines system access relations while Cynara takes care about controlling privilege access.

Running in The Right Domain with systemd

In Tizen 3, services are started by the system service manager systemd. Services are launched in the System domain unless specified otherwise. A service can be launched in the User domain by adding SmackExecLabel=User to the configuration file for the service in /usr/lib/systemd/system.

Peer Domains

There are cases where it makes sense to subdivide a Smack domain. The three domain model remains intact, with the floor, System and User domains defining the basic division. Within the System and User domains it is possible to create peer domains.

Within a set of peer domains any set of access rules may be permitted. This allows the processes to be allowed to communicate or be blocked from communication as needed. A peer domain of the User domain has the same access permissions to the floor or System domain as the User domain. A peer domain of the System domain has the same access permissions to the floor or User domain as the System domain.

Creating New Peer Domains

Resist the temptation to create a new domain if it is at all possible. Fine grained security can be a maintenance nightmare that causes more problems than it solves. In almost all cases programs and applications will be invoked by processes that are already running in the correct domain.

When To Create A Peer Domain

A new peer domain should be created to protect a set of resources from the domain it would run in otherwise. The new peer domain will not have more access than the domain it would naturally run in.

The Default Floor Domain Manifest File

Each Tizen package needs a manifest file. Usually, it will contain:

<manifest>
  <request>
    <domain name="_"/>
  </request>
</manifest>

Label Name Conventions

Smack labels are uninterpreted text strings. There is no implicit relationship between Smack labels with similar appearances. Tizen has adopted the convention that a domain will use a Smack label reflecting the name of the domain. Data that a domain provides for other domains to read should be labeled using a label domain::Shared. Data that a domain provides for other domains to share fully is discouraged, and should be labeled using a label domain::purpose, where purpose explicitly identifies how the data should be used.

The Floor Domain

The floor domain provides the foundation for the system. The content of the floor domain does not change while the system is running, with occasional and explicit exceptions. Only updates to the system itself will affect the floor domain. The exception is system logs, which are protected with the same vigor as other system components.

Labels

  • _ The floor label.

Only kernel helper processes run with this label. This label is readable by processes in all domains.

  • ^ The hat label.

Processes with this label have read access to all domains. The systemd-journal process runs (or will soon) with this label.

  • * The star label.

No processes run with this label. A file with this label is generally accessible. This label should only be given to specific device files.

Processes

Only kernel helper processes run in the floor domain.

Files

All system data that is not expected to change should be in the floor domain. The program files, libraries and static data associated with the system are given the _ (floor) label. System directories generally have the floor label. The special shared directories /tmp and /usr/tmp are granted the star label. They are available for any process to use. Note: the files created in these directories will be visible to all processes, but they are still protected by the Smack label on the file, which will match the label of the process that created them.

The System Domain

The System domain is comprised of the basic system services and the data they maintain.

Labels

  • System

The name for this domain, capitalized as is conventional for personal names.

  • System::Privileged

A label that is in the smackfs/onlycap. Processes running with it are allowed to configure Smack (CAP_MAC_ADMIN and CAP_MAC_OVERRIDE).

  • System::Run

No processes run with this label. The label for the /run hierarchy. The System domain has complete, transmuting access to this label. The User domain has complete, transmuting access to this label.

  • System::Shared

No processes run with this label. The System domain has complete, transmuting access to this label. The User domain has read, execute and lock access to this label.

  • System::Log

No processes run with this label. The System domain has complete access to this label. The User domain has complete access to this label.

Processes

Processes started by systemd (and systemd itself) run with the System label. Programs marked with Smack execute (SMACK64EXEC) attributes run with the specified label and may run in a different domain. Administrative processes (e.g. admin's shell) run with the System::Privileged label.

Files

The directory hierarchy rooted at /run is a transmuting hierarchy labeled System::Run. This hierarchy is part of the mechanism that systemd uses to communicate with its children. The /run hierarchy should not be used as a general repository. It is explicitly for sharing system information between system processes. The /run/memory hierarchy contains vconf databases.

The directory hierarchy rooted at /var/log is labeled System::Log. The root of the directory is transmuting, however none of the rules granting access to it are. The directory hierarchy rooted at /opt/share/crash is labeled System::Log.

The directory hierarchy rooted at /var/lib/bluetooth is labeled System. /var/lib/bluetooth will be moving to the User domain.

The directory hierarchy rooted at /etc is labeled System::Shared. The root of the directory is transmuting. Most of the files contained in /etc will be in the floor domain and labeled _, however some are updated by processes in the System domain, hence the explicit sharing.

The User Domain

The User domain includes the services that interact directly with the person using the Tizen system and the data those services maintain.

Labels

  • User

The name for this domain, capitalized as is conventional for personal names. Assigned to user processes and services, except for installable applications. Installable applications can access this label for write and execute. Files labeled with that label cannot be opened by installable applications (due to lack of read permission).

  • User::Pkg::$pkg_id

Distinct label for packages and applications in non-hybrid packages. $pkg_id will be substituted by package identifier.
User label has complete access to this label.

  • User::Pkg::$pkg_id::App::$app_id

Distinct label for applications in hybrid packages, where every application has a different label. $pkg_id will be substituted by package identifier and $app_id will be substituted by application identifier.
User label has complete access to this label.

  • User::Pkg::$pkg_id::RO

No processes run with this label. Label used for files that are read-only to the application. $pkg_id will be substituted by package identifier.
User label has complete access to this label.

  • User::Pkg::$pkg_id::SharedRO

No processes run with this label. Label used for compatibility with Tizen 2.x applications. It is used to share files in a read-only mode between such applications. $pkg_id will be substituted by package identifier.
User label has complete access to this label.

  • User::Home

No processes run with this label. User label has complete, transmuting access to this label. Installable applications can access this label for read, execute and lock.

  • User::App::Shared

No processes run with this label. User label has complete, transmuting access to this label. Installable applications have complete, transmuting access to this label.

  • User::Shell

Label used by the user's (non-root) shell. Similarly to System::Privileged it is added to the smackfs/onlycap.

Processes

  • weston-launch

This program provides the user experience.

  • launchpad-preloading-preinitializing-daemon

(Don't blame me, I didn't come up with the name!) The ultra-high speed application launcher.

  • pulseaudio

Provides the audio service component of the user experience.

Files

  • /opt/home/app

The hierarchy for the user apps home directory.

  • /opt/usr/media

The hierarchy for user media storage.

  • /home/app

The other hierarchy for the user apps home directory. A symbolic link to /opt/home/app.

The AMB Domain

The Automotive Message Broker (AMB) domain provides a set of services for the In-Vehicle Infotainment (IVI) profile. The AMB domain is a peer domain of the System domain.

Labels

  • AMB

The Name of this domain, in capital letters as is appropriate for an acronym.

  • AMB::readall

Data that is maintained by the domain and generally readable.

  • AMB AMB::writeall

Data shared by this domain and other domains.

  • AMB::machinegun

An example of a protected API.

Processes

  • ambd

The Automotive Message Broker Daemon.

Files

  • /etc/AMB

Private data used by the Automotive Message Broker.

  • /usr/bin/ambd

The Automotive Message Broker Daemon binary.

  • /usr/lib/libamb.so.0.10.900
  • /usr/lib/libamb.so

The Automotive Message Broker library.

  • /usr/lib/systemd/system/network.target.wants
  • /usr/lib/systemd/system/network.target.wants/ambd.service
  • /usr/lib/systemd/system/multi-user.target.wants/ambd.service
  • /usr/lib/systemd/system/ambd.service

The systemd interfaces that invoke the AMB domain.