From Tizen Wiki
Jump to: navigation, search

Smack introduction & role

smack general

  • Smack?
  • Smack manifest (rpm integration)

3-domain Smack

Smack onlycap feature

Smack labeling


  • Basically, no one should be able to make/modify smack label except for designated processes - systemd and security-manager
  • label of processes
  • kernel thread
  • The default smack label of process is floor(_), so all kernel threads are running with _ label.
  • daemons
  • The smack label of daemons is determined by systemd. In accordance with the 3-domain policy, daemons can have System or System::Privileged or User label.
  • All daemons MUST be launched by systemd, otherwise a daemon will have the label of its parent process, it can cause a problem.
  • The System::Privileged label SHOULD be permitted to the designated system session daemons. A daemon which has this label can have smack related capabilities - CAP_MAC_ADMIN and CAP_MAC_OVERRIDE - in the public Tizen platform. So this daemons can change smack label of files/directories or add/remove smack rules. For more information, please refer to
  • applications
  • All application processes in Tizen are regarded as a process under User domain and have User::Pkg::$pkg_id label. This label is given by security-manager at launch time. Application process' smack label is the basis of application sandboxing, so no one should be able to change it.
  • In case of hybrid package, the label of application process is User::Pkg::$pkg_id::App::$app_id. (since security-manager ver. 1.2.1)
  • A file or directory made by an application process will have the same label of that application process, so smack rules between application processes are not permitted because of sandboxing. It means that the IPC of two application processes is not permitted. (unix domain socket, message queue, shared memory and so on)
  • Some directories of an application process can have different label from application process, it is stated in the below section.
  • To use IPC between application processes, developer should use mechanisms provided by appfw

label of directories

  • the current status
  • The labels of directory are given by 3-domain smack structure.
  • If a daemon wants to share resources with other daemons or applications:
  • all processes can read/write - use User::App::Shared
  • daemons can read/write but applications only can read - use System::Shared, but User label daemons can read only
  • not allow to access of applications - we have no label, use DAC instead
  • how to give a label
  • Use smack manifest / Use command line tool / Use libsmack functions in source code
  • In order to use libsmack functions, the process must have CAP_MAC_ADMIN capability.
  • If the onlycap feature is used, the label of process should be existed in the onlycap list

label of applications

  • application process label
  • In Tizen, all applications in one package are treated as having same security context
  • In case of normal application package, the label is "User::Pkg::$pkg_id"
  • But there is a special package type - 'hybrid' package, which has web app and native app, these applications can have different security policy and they have all permissions each other.
  • In case of hybrid application package, the label is "User::Pkg::$pkg_id::App::$app_id"
  • application directory structure and labels
  • All application processes are sandboxed by smack label, each application process has its own smack label and all application processes cannot access to other application processes' directories.
  • An application process can read/write to
  • data/cache directory - /opt/usr/home/$user_name/apps_rw/$pkg_id/{data|cache}
  • shared directories - /opt/usr/home/$user_name/apps_rw/$pkg_id/shared/{data|trusted}
  • An application process can read from
  • bin/res directory - /usr/apps/$pkg_id/{bin|res}
  • shared resources directory - /usr/apps/$pkg_id/shared/res
  • other application processes' shared/data - /opt/usr/home/$user_name/apps_rw/$pkg_id/shared/data
  • An application process can have its shared/data directory only when its version (api_version or required_version) is under 3.0 or it has appdir.shareddata privilege
  • This is not provided by smack since Tizen 6.0, it provides by mount namespace
  • the label of shared/trusted
  • This directory is used for sharing resources with application processes which have same author information (public key of author certificate)
  • When an application process is installed, the security-manager makes a label - User::Author::# (User::Author::1, User::Author::2, ...)
  • The label is made according to the order of installation
  • Since security-manager 1.6.7, the hash value of author information is used - User::Author::$hash_value_of_author_information
  • Use 16 characters of SHA1 hash value of the author information

other special labels

  • User::Shell
  • This label is given to shell prompt. Tizen's shell prompt is provided by sdbd (sdb daemon)

User User::Shell rwxat
User::Shell System wx
User::Shell System::Shared rxtl
User::Shell System::Run rxl
User::Shell System::Log w
User::Shell User wx
User::Shell User::Home rxl
User::Shell User::App::Shared rwxat
User::Shell System::Tools rx
System::Privileged User::Shell rwxat
System User::Shell rwxat

  • System::Tools
  • This label is given to some command line tools and was made in order not to give access(execute) authority to applications
  • Only daemon processes can have read/execute rules to this label

ways to modify Smack labels for various resources

  • smack manifest
  • smack command line tool
  • libsmack / setxattr function
  • access label : SMACK64, execute label : SMACK64EXEC, socket ip in label : SMACK64IPIN, socket ip out label : SMACK64IPOUT
  • To do these functions, CAP_MAC_ADMIN capability is needed
  • If the onlycap feature is used, the label of process should be existed in the onlycap list
  • udev rules for device nodes
  • The smack is integrated with udev, and a device node is made by udev, smack label of that node can be changed
  • This can be done by udev rule file
  • SECLABEL{smack}="$label"
  • RUN+="/bin/chsmack -a $label /absolute/path/for/resource"
  • Udev rule files are stored in /usr/lib/udev/rules.d/
  • tmpfiles.d for tmpfs
  • Resources in tmpfs such as /var, /run are made when system is booting, so using smack manifest or post section cannot be used
  • Developer can make a shell script for labeling, but it can cause race condition issue
  • In this case, we can use tmpfiles.d feature
  • To give a label, make a conf file and use 't' type (this type is used for extended attribute, and smack labels are stored in extended attribute)
  • e.g.) t /absolute/path/for/resource/in/tmpfs - - - - security.SMACK64="$label"
  • tmpfiles.d conf files are stored in /usr/lib/tmpfiles.d/
  • Systemd configurations
  • Set the label of service (*.service file)
  • Provide an option to set the smack label of service executed by system session systemd
  • SmackProcessLabel=$label
  • Set the label of packet (*.socket file)
  • Provide an option to set the smack label of packet transmitted though a socket
  • SmackLabelIPIn=$label
  • SmackLabelIPOut=$label
  • As the system session systemd daemon sets these labels, it must have the right to change a label of forked process and sockets (CAP_MAC_ADMIN)
  • (NOT recommended) post section of rpm spec file
  • The post section of rpm spec file is executed after installation
  • If package owner wants to change smack label of file or directory, use chsmack command in this section
  • In case that those files or directories are installed by the package, using smack manifest is the correct way to do it

smack rule


rule of daemons / kernel threads

  • default-ac-domains
  • The default-ac-domains package has a smack manifest file to add daemon's rules (default-ac-domains/packaging/default-ac-domains.manifest)
  • This rule file is stored in /etc/smack/accesses.d/ and loaded by systemd at booting time

rule of applications

  • security-manager
  • Applications rules are made from security-manager DB
  • The security-manager-rules-loader makes all installed application's smack rules and loads them
  • This should be executed before the first application is launched
  • There are some options, it can be found by # security-manager-rules-loader --help
  • As this execution loads smack rules, it should be executed with CAP_MAC_ADMIN capability
  • When new application is installed at runtime, the rules of that application are loaded at that time
  • If the smack - privilege mapping feature is used, smack rules can be added / removed at launching time as per the application's privilege
  • (Remark) Before Tizen 5.0, the security-manager makes rule files of application and loads it
  • app/package/author rule templates
  • The security-manager-rules-loader uses some template files for making application smack rules
  • These files are in security-manager/policy/ directory - app-rules-template.smack, pkg-rules-template.smack, author-rules-template.smack
  • app-rules-template.smack : this is used for giving basic smack labels of application, ~PROCESS~ will be replaced with application label
  • pkg-rules-template.smack : this is used for giving smack labels of application package directories to daemons, ~PATH_RO~ is "User::Pkg::$pkg_id::RO", ~PATH_RW~ is "User::Pkg::$pkg_id"
  • author-rules-template.smack : this is used for giving shared/trusted labels of package to daemons, ~PATH_TRUSTED~ is "User::Author::$hash_of_author_info" described in the label of applications
  • If a developer wants to make a new domain and give smack rules for that domain, these template files should be modified
  • Note that, this template files are used when the security-manager is compiled, so template files should be modified before compilation

modify smack rule - FORBIDDEN!!

  • Under security review, smack rule can be added or modified, but public Tizen platform NEVER provide any method to do it and NEVER recommend it

add a new smack domain

make smack manifest

change process label of daemon

  • Use SmackProcessLabel option of systemd service file

(if needed) modify security-manager template

  • give a rule with applications
  • since Tizen 5.0, these templates are used for package build


  • To protect from other daemons and applications
  • Make a new domain and sub-labels (smack manifest)
  • Give a label to resources (smack manifest)
  • Add required smack rules (smack manifest)
  • Change smack label of new daemon (systemd service file)
  • Do not modify security-manager template files because there are no rules with any application

smack library and utilities for user space


useful command line tools

  • chsmack
Usage: chsmack [options]
Smack attributes on files are shown or modified with this command.
To check the attribute, try to use as below.

sh-3.2# chsmack /usr/bin/security-manager
/usr/bin/security-manager access="_"

To change the attribute, refer below options. In most cases, "access" and "exec" options are well used.

-a --access set security.SMACK64
-e --exec set security.SMACK64EXEC
-m --mmap set security.SMACK64MMAP
-t --transmute set security.SMACK64TRANSMUTE
-L --dereference tell to follow the symbolic links
-D --drop remove unset attributes
-A --drop-access remove security.SMACK64
-E --drop-exec remove security.SMACK64EXEC
-M --drop-mmap remove security.SMACK64MMAP
-T --drop-transmute remove security.SMACK64TRANSMUTE
-r --recursive list or modify also files in subdirectories

sh-3.2# chsmack -a "_" -e "System" /opt/testfile (Set access label as "_", execute label as "System")
sh-3.2# chsmack /opt/testfile (Check result)
/opt/testfile access="_" execute="System"

  • smackload
Set or clear SMACK rules. Rules loaded by this are cleared after the rebooting.
echo "[subject] [object] [rule]" | smackload => Set a single SMACK rule
smackload [path] => Load rules wriiten in the specific path
echo"[subject] [object] [rule]" | smackload --clear => Clear a single SMACK rule
smackload -c [path] => Clear rules written in the specific path
sh-3.2# echo "TESTA TESTB rwx" | smackload (Set a single SMACK rule)
sh-3.2# cat /sys/fs/smackfs/load2 | grep TESTA (Check the rule)
sh-3.2# echo "TESTA TESTB rwx" | smackload -c (Clear a single SMACK rule)
sh-3.2# cat /sys/fs/smackfs/load2 | grep TESTA (Check the rule)

  • smackctl
Apply or clear all rules from the kernel.
smackctl apply => Initialze all SMACK rules then load all the rules found in the configuration directory's configuration directory : /etc/smack/accesses.d/ & /etc/smack/accesses2.d/
smackctl clear => Remove all SMACK rules from the kernel.
smackctl status => Show the status of the SMACK system.
sh-3.2# smackctl clear
sh-3.2# wc -l /sys/fs/smackfs/load2
0 /sys/fs/smackfs/load2
sh-3.2# smackctl apply
sh-3.2# wc -l /sys/fs/smackfs/load2
79 /sys/fs/smackfs/load2

  • smackaccess
Check whether a specific rule is existed or not. If exist, return 1, If not, return 0.
smackaccess [subject] [object] [rules]
sh-3.2# cat /sys/fs/smackfs/load2 | grep "System _ rwxa" => Assume that "System _ rwxa" rule is existed.
System _ rwxa
sh-3.2# smackaccess System _ rwxa (rwxa rule is existed. Return 1)
sh-3.2# smackaccess System _ rwxat (t rule is not existed. Return 0)
sh-3.2# smackaccess System _ rw (rw rule is existed. Return 1)