Security/Tizen 2.X Smack
The general introduction to Smack in Tizen might be found in the article Security/Tizen_Smack.
Smack Policy in Tizen 2.X
In Tizen 2.X, we utilize Smack as a mechaism for user privilege, application privilege, system resource protection and application sandboxing.
Tizen uses rpm as a package manager for platform modules. Basic policy for the package is that all files in a single package should be labeled with a single label. But some of the files in a package would be labeled different from others to provide finer grained protection or access support.
Manifest file is the primary language of labeling and rule definition for rpm packages which means developers can assign labels and rules by themselves although some of the modules using direct rule file or using command line tools to assign them. However, we recommend to use Smack manifest.
Below statements are basic policy of system resources.
Most of system files would be labeled as "_", since they are read-only. (e.g. /lib, /bin, /usr/lib, /etc, /dev)
Some system files which should be written by every process, are labeld as "*" (e.g. /dev/null, /dev/zero)
If an executable file should be executed by specific processes, then label should be domain of package and the calling processes should have a X rule. Otherwise, the label could be floor, "_" without execute label assigned.
Naming of a label is important for readability. In case of system service daemon, the label should explicitly recognizable. (e.g. contacts-service, telephony_frwk, deviced)
Name of a system resource should be labeled based on system service daemon with double colon. (e.g. contacts-service::db, telephony_frwk::sim, device::audio)
Label of a device file is defined by udev module.
Following statements are requirements of application sandboxing.
- Application cannot access resources of other applications.
- Application cannot access running status of other applications(Cannot access /proc/[PID_of_application] except self).
- Application cannot read and write data of other applications.
- Application cannot send IPC and signal to other applications.
One of the important characteristic of Smack is that accessing from a subject to an object with same label is always allowed without any Smack rule. We utilize this feature to provide sandboxing that files and the application process in an application are labeled same, which is application identifier of the application.
Smack labeling of an application is done by installer which calls libprivilege-control APIs.
Following table shows each sub-directory except shared directory. /opt/usr/apps/[APPLICATION_ID] is standard location of downloadable applications.
Executable files of a native application is installed in /opt/usr/apps/[APPLICATION_ID]/bin.
Same as native application, but executable files of web application is link of web run time executable.
Shared directory is a special exception for the application sandboxing. Labels of shared directories are described below.
|/opt/usr/apps/[APPLICATION_ID]/shared/data||directory||Hash value of application ID||Enable|
|/opt/usr/apps/[APPLICATION_ID]/shared/trusted||directory||Hash value of certificate||Enable|
shared/cache, and shared/res directories are labeled as floor which means any process can read the data inside including the owner application itself. This is the location for data to allow everybody to read.
shared/data is labeled as hash of the application identifier to guarantee uniqueness of the Smack label. Installer gives rwxatl rule for the owner application to read, write, and create files inside the directory. Since the directory is transmutable, all the files inside will inherit Smack label from the directory. In addition, all other applications have rxl Smack rules to the shared/data directory, therefore every other applications can access the directory to read files inside.
|Note: Every application installation occurs adding 2n Smack rules because of this shared/data directory which resulting n^2 Smack rule required.|
shared/trusted is used for sharing data between application from a single developer. The label of the directory is a hash value of author certificate, so any application signed by the same author will have directory with same label. The application process acquires rwxatl rule.
In case of network resources, we use Netlabel.
Tizen 2.X maps IP addresses into specific Smack labels to provide find grand access control in /sys/fs/smackfs/netlabel which is described below. The label is applied in top to down order.
10.0.2.2/32 system::debugging_network 10.0.2.16/32 system::debugging_network 127.0.0.1/32 -CIPSO 192.168.129.1/32 @ (Deprecated) 192.168.129.3/32 @ (Deprecated) 0.0.0.0/1 system::use_internet 22.214.171.124/1 system::use_internet
- system::debugging_network : Refer to debugging environment, this label denotes IP addresses of connection for debugging host and sdbd.
- CIPSO : In case of packets in loop back device, CIPSO denotes Smack label of the packets will follow the the Smack label of the sender process.
- @ : Label stands for Web, IP address of 192.168.129.1 and 192.168.129.3 was used for ssh communication between host PC and the device before sdbd is introduced. This is historical label that is no longer used.
- system::use_internet : Packets from/to outside. All packets from/to outside are masked to 0.0.0.0 or 126.96.36.199 If IP address is not mapped with label like above, then it is regarded as IP address from outside and labeled as system::use_internet. This means that any application which requires to send IP packets to the network, it requires Smack rules regarding system::use_internet.