Security/TizenSecurityReference

From Tizen Wiki
Jump to: navigation, search


Contents

Tizen Security

Replace this with your email address if you plan to work on this section.

Versions

This document describes Tizen 3. There are significant differences between the behavior of Tizen 2 and Tizen 3.

Replace this with your email address if you plan to work on this section.

Tizen 2

Replace this with your email address if you plan to work on this section.

Tizen 3

Replace this with your email address if you plan to work on this section.

Future Directions

Replace this with your email address if you plan to work on this section.

Security Namespaces

Assigned to: Tomasz Swierczek <t.swierczek@samsung.com>

KDBUS

Replace this with your email address if you plan to work on this section.

User Security

Tizen supports the notion of multiple users for a device. A user can generally be thought of as a person. From the software perspective a user is an account, with a user name and a user identification (UID) number. It is possible for a person to have more than one account on a device, or for more than one person to share an account. The software doesn't care who (or what) presses the buttons. All the activity associated with a particular UID is associated with that user.

User Accounts

Replace this with your email address if you plan to work on this section.

The User’s Home Directory

Replace this with your email address if you plan to work on this section.

Sharing Data

Replace this with your email address if you plan to work on this section.

Single Sign-on

Replace this with your email address if you plan to work on this section.

Application Security

Replace this with your email address if you plan to work on this section.

Resources

Resources are the things that applications work with. Resources are defined in terms of their purpose, not their implementation. The granularity of resources is arbitrary and varies from a single file to an entire subsystem. There are also cases where one resource is contained within another.

Application Privileges

Applications may request access to protected resources. The right to access a protected resource is called a privilege. Application privileges are identified by a text string. W3C uses strings like http://tizen.org/privilege/fullscreen. As their name indicates, application privileges are granted to applications and are enforced by system services. For list of Tizen core privileges, please visit the Tizen 3.0 Core Privileges page.

Policy

The application security policy reflects the requirements of W3C. Protected resources are made available only to applications that are granted the required privileges. Tizen policy is the responsibility of the service providing the resource. The application is never trusted behave properly.

Enforcement

Services that provide access to protected resources perform access control checks to ensure they only do so in accordance with the current set of privileges granted to the application. Applications cannot be trusted to control their own access, so no checks are done within the APIs used by the applications. Services use the facilities of Cynara to make decisions based on the attributes of the application process.

Attributes

Applications privileges are enforced based on two process attributes. The user identifier (UID) identifies the user account the application is running under. The Smack label is used as an application identifier and identifies the application.

Cynara

Services that provide access to protected resources use Cynara to determine if access is appropriate. Cynara compares the attributes of the requesting process (the UID and Smack label) with the active set of application permissions and passes judgement. The result is returned to the service, which uses this information to decide how to respond to the application.

Files

Access to files and other file system objects are not controlled by application privileges. However, the same attributes (UIDs and Smack labels) that are used to identify applications are used in access control decisions on system objects like files.

Application Services

Replace this with your email address if you plan to work on this section.

DBUS

Replace this with your email address if you plan to work on this section.

Automotive Message Broker

Replace this with your email address if you plan to work on this section.

Murphy

Replace this with your email address if you plan to work on this section.

Display Services

The displays on a Tizen device are managed by a display service. The display service is profile dependent. The display service directly supports user interactions, and is run as part if the User Smack domain. Display services do not enforce system security policy.

Weston

Weston is a display manager based on the Wayland system. Weston is the only display manager used in the IVI profile and is one of the options in the Common profile.

X11

The X11 window system is a mature network based display manager. The X11 window system is the only display manager used in the Mobile profile and is one of the options in the Common profile.

Web Applications

Replace this with your email address if you plan to work on this section.

Crosswalk

Assigned to: Terri Oda <terri.oda@intel.com>

Render Process

Assigned to: Terri Oda <terri.oda@intel.com>

Extension Process

Assigned to: Terri Oda <terri.oda@intel.com>

Browser Process

Assigned to: Terri Oda <terri.oda@intel.com>

Application Manifest

Assigned to: Terri Oda <terri.oda@intel.com>

Web Application Installation

Replace this with your email address if you plan to work on this section.

Launching Web Applications

Replace this with your email address if you plan to work on this section.

Native Applications

Replace this with your email address if you plan to work on this section.

Core Applications

Replace this with your email address if you plan to work on this section.

OSP Applications

OSP is not supported in Tizen 3.

Installing Native Applications

Replace this with your email address if you plan to work on this section.

Launching Native Applications

Replace this with your email address if you plan to work on this section.

Platform Security

Replace this with your email address if you plan to work on this section.

Access Control

The Tizen platform supports the classic Linux subject/object based model for access control. In the Linux model processes are the subjects. Subjects are the active part of the policy. Anything that processes act on outside of the process itself is an object. Objects include files, directories, shared memory segments and, in special cases, other processes.

Discretionary Access Control

The traditional access controls used on a Linux system are discretionary, meaning that they are based on the user who owns the process and that the user who owns an object may change who has access to the object. Some objects have slightly different restrictions on what operations are permitted. A process can send a signal (a write operation) to another process only if the owning user of the two processes is the same. A process can send a network packet (also a write operation) to any other process. In neither case can the user change these exceptional rules.

Attributes

Every process runs with a user identifier (UID) and a set of group identifiers (GID). Every object has an owning UID and an owning GID.

Mandatory Access Control

Mandatory access controls (MAC) are not traditionally included in the Linux security model. Tizen uses the optional Smack security module to implement MAC. Mandatory controls are not based on UIDs. Instead, a label is assigned to each subject and each object and these labels are used to make access control decisions. The owner of an object does not have control over these labels.

Attributes

The labels used by Smack are uninterpreted text strings. Smack labels are attached to all objects. Additionally, Smack labels are attached to network IP packets, allowing MAC control over IP communications.

Containers

Replace this with your email address if you plan to work on this section.

Process Privileges

There are operations that are restricted to specific users. These include operations on objects owned by the user and system configuration operations. In order to violate these rules a process is required to have privilege.

The Super User

The Super User has the UID zero. A Super User process can violate any policy.

POSIX Capabilities

The Super User mechanism is easy to exploit because it provides privilege that is usually beyond what is required for a specific task. The capabilities mechanism allows specification of finer grained privilege.

System Objects

The Linux kernel provides security for the lowest level system objects. The kernel provides discretionary and mandatory access controls on these objects. Discretionary controls can be modified by the owner of the object. Mandatory controls are managed by the system, and cannot be modified by unprivileged users.

Files

Files are storage containers for arbitrary data. They may contain programs. The access modes supported on files are read, write, execute, append and lock. The lock mode is only relevant to mandatory access control, and indicates that read lock can be set on a file for which write access is unavailable.

Directories

Directories are storage containers for path name components. The access modes supported on directories are read, write, execute and transmute. The transmute mode is only relevant to mandatory access control, and influences the Smack label given files created in the directory.

Symbolic Links

Symbolic Links are storage containers for path components. The access modes supported on Symbolic Links are read and write. The read and write modes are only relevant to mandatory access control. Only the owner of a Symbolic Link can change its contents.

FIFOs

FIFOs provide named pipes between processes. The access modes supported on FIFOs are read and write.

UNIX Domain Socket Rendezvous

A UNIX Domain Socket (UDS) Rendezvous provides a name for an underlying UDS. The access modes supported on a UDS Rendezvous are read and write.

Block Devices

Block device files are generally inaccessible to unprivileged processes.

Character Devices

Character Device files support read and write access. The security attributes for character devices are managed by udev.

Shared Memory Segments

Shared memory segments support read and write access.

Semaphore Sets

Semaphore sets support read and write access.

Message Queues

Message queues support read and write access.

Keys

Replace this with your email address if you plan to work on this section.

Inter Process Communications

Replace this with your email address if you plan to work on this section.

Signals

Replace this with your email address if you plan to work on this section.

UNIX Domain Sockets

Replace this with your email address if you plan to work on this section.

Internet Domain Sockets

Replace this with your email address if you plan to work on this section.

Networking

Replace this with your email address if you plan to work on this section.

IPTables

Replace this with your email address if you plan to work on this section.

Firewall

Replace this with your email address if you plan to work on this section.

CIPSO

Replace this with your email address if you plan to work on this section.

Filesystem Hierarchy

Replace this with your email address if you plan to work on this section.

/dev

Replace this with your email address if you plan to work on this section.

/etc

Replace this with your email address if you plan to work on this section.

/home

Replace this with your email address if you plan to work on this section.

/opt

Replace this with your email address if you plan to work on this section.

/proc

Replace this with your email address if you plan to work on this section.

/run

Replace this with your email address if you plan to work on this section.

/sys

Replace this with your email address if you plan to work on this section.

/tmp

Replace this with your email address if you plan to work on this section.

/usr

Replace this with your email address if you plan to work on this section.

/usr/bin

Replace this with your email address if you plan to work on this section.

/usr/lib

Replace this with your email address if you plan to work on this section.

/var

Replace this with your email address if you plan to work on this section.

System Start Up

Replace this with your email address if you plan to work on this section.

CSF/CSR - McAfee

Replace this with your email address if you plan to work on this section.

Authentication

Replace this with your email address if you plan to work on this section.

Pluggable Authentication Modules

Replace this with your email address if you plan to work on this section.

Developing For Tizen Security

Replace this with your email address if you plan to work on this section.

Web Applications

The requirements for developing web applications are described in the Tizen Web Application Programming guide.

Native Applications

The basic requirements for developing native applications are described in the Tizen Web Application Programming guide. Native application developers are encouraged to use the higher level APIs described there.

Unlike Web applications, native applications may use the Linux system call interfaces directly. Linux system calls are constrained by the native discretionary and mandatory access control policies. While these policies are used in way that is complimentary to the application privilege policy they are not identical. Use of the higher level APIs will help ensure that the application conforms with all of the policies.

Native applications run with the user identifier (UID) assigned to the user. Two instances of the same application used by different users will not have the same access rights. Native applications run with the Smack label assigned to the application. Applications must store their data in the designated locations in the $HOME directory.

Application Services

Platform programs that provide services to applications are required to enforce access control to protected resources based on the application privilege policy. This can be accomplished in a number of ways.

  • dbus - Services that provide dbus interfaces can usually make use of the dbus configuration. The version of dbus in Tizen will soon support application privilege controls.
  • Cynara - Services that provide socket based interfaces can use Cynara APIs to determine is access to protected resources should be allowed. Because Cynara is (currently) unique to Tizen, this will require Tizen specific changes to the service.
  • Smack Peer Domain - In cases where a service is isolated from other services and is reasonably self contained it is possible to run the service in its own Smack peer domain. This is recommended only for those services with extremely limited interaction with other system resources as interactions between domains quickly increases the complexity of the system security policy.
  • Access Control Intermediary - In extreme cases it may make the most sense to create an intermediary process to handle the access controls for a particular resource. This introduces additional system overhead and may introduce API incompatibility. Some legacy services may be best address in this way simply because they have many interactions with other services and active upstream development that makes a Tizen specific version impractical.

System Configuration

Replace this with your email address if you plan to work on this section.

Systemd

Replace this with your email address if you plan to work on this section.

DBus

Replace this with your email address if you plan to work on this section.

Smack

Replace this with your email address if you plan to work on this section.

The Ambient Label

Replace this with your email address if you plan to work on this section.

Per Host Labeling

Replace this with your email address if you plan to work on this section.

CIPSO Configuration

Replace this with your email address if you plan to work on this section.

Developer Access

Replace this with your email address if you plan to work on this section.

System Console

Replace this with your email address if you plan to work on this section.

Network Login

Replace this with your email address if you plan to work on this section.

Terminal Emulators

Replace this with your email address if you plan to work on this section.

Wayland Terminal

Replace this with your email address if you plan to work on this section.

Xterm

Replace this with your email address if you plan to work on this section.

Profiles

Assigned to: John L. Whiteman <john.l.whiteman@intel.com>

Common

Assigned to: John L. Whiteman <john.l.whiteman@intel.com>

Mobile

Assigned to: John L. Whiteman <john.l.whiteman@intel.com>

In Vehicle Infotainment

Assigned to: John L. Whiteman <john.l.whiteman@intel.com>

Television

Assigned to: John L. Whiteman <john.l.whiteman@intel.com>

Glossary

API Application Programming Interface. Traditionally a document detailing how to use one piece of software from another. Now used to describe any set of software that can be invoked by another, regardless of method. APIs are not elements of the Tizen security model.
Application Any program that is not part of the system services.
Application Privilege A privilege that can be granted to a specific application allowing it access to a controlled resource.
Cynara A component of the application security enforcement mechanism. Cynara maintains the relationships between applications and application privileges.
Developer Any source of applications or platform components. Typically a person, but these days, you can't be sure.
Device A computer running Tizen. A hardware component of the computer accessible from the platform software.
Directory A container of information about file system objects.
File A container for data.
Folder A directory. Disparaged terminology from another operating system.
IVI In Vehicle Infotainment. Presentation of information and entertainment in a closed environment.
Linux A publicly accessible implementation of the UNIX kernel API. Any of a number of operating systems using the Linux kernel. The operating system kernel used in Tizen.
Native Application Any user installed program allowed access to APIs that are not provided by the Wed runtime environment, especially the Linux kernel APIs.
Object Anything accessible by name.
Privilege The right to perform an action. Used especially where the right to perform an action is exceptional.
Process An executing instance of a program.
Program An executable unit of code. An application is a program or a set of programs.
Resource Anything that can be used or manipulated by an application. A resource may include a collection of objects and services.
Service A process that provides access to a resource to another process.
Smack The Simplified Mandatory Access Control Kernel. Smack is a component of the Linux kernel that provides strong access controls on platform objects.
User A user is any person who interacts with a device. Anything that interacts with the device in the way a person would is considered a user as well.
Web Application An application that runs under the web runtime environment.