Security/Tizen 6.X Internet Access Control

From Tizen Wiki
Jump to: navigation, search

Internet Access Control Mechanisms

On Tizen 6.X there are multiple access control mechanisms, which can be used to control process access to the internet. The main differences are possibility of runtime access changes (allowing/denying access while application is running), support of multiuser, support of IPv6 protocol and requirements for these mechanism to work.

GID based Internet access control

Quick description


This mechanism is based on the process supplementary groups and iptables ability of filtering outbound network traffic based on these groups. Security-manager allows privilege-group mapping, which can be used for GID based Internet access control together with proper iptables setup. The latter one is provided by security-manager-iptables.rules and security-manager-ip6tables.rules files from security-manager-policy-iptables RPM package. Security-manager mapping will assign Internet privilege group (by default its priv_internet) when launching application, if given application is allowed the usage of Internet. This group is directly used by provided iptables rules,

for e.g.:

-A OUTPUT -m owner --gid-owner priv_internet --suppl-groups -j ACCEPT

This mechanism supports multiuser and IPv6 protocol, but allows control only of outbound network traffic.

GID based access control doesn't support runtime access control changes. When application is launched with given groups, they cannot be changed until application is launched again.

Current configuration


While Smack is not a primary network controller in this solution it does play a role. If we look at the main Smack network configuration file for IPV4:


   1: -CIPSO
   2: System

The first line means that for localhost addresses CIPSO and Smack are used. Which basically means that the communication is controlled by labels of processes. If a process's label have a write access to other process's label then it can send it an IP packet. And vice versa.

All other addresses (by that I mean mostly external ones) have label System set explicitly. Label System has write access to all applications and all applications have write access to it by the default rules in default-ac-domains package. That means Smack itself will allow such communication, both incoming and outgoing.

To read more about Smack and CIPSO have a look here.

Privilege group mappings

Currently there are two privileges and 2 corresponding groups:

Privilege Group priv_internet priv_appdebugging

Those privileges only work for user applications. System services always have internet access, they don't need any privileges for that (by iptables rules, see below).

Those privileges control both, the external network and localhost communication. Localhost is additionally controlled by Smack and CIPSO (by Smack netlabel configuration, see above).

The first privilege is intended for a generic internet access. If an app does not have it will not be able to access external IP addresses.

The second one is a special use case where application has an access to a specific set of IP addresses used for application debugging. It does not have general internet access.

Groups for applications according to their privileges are set by security-manager when application launches. This is done according to privileges-groups mappings that are part of security-manager configuration and policy.


     1: priv_camera
     2: priv_recorder
     3: priv_mediastorage
     4: priv_externalstorage
     5: priv_message_read
     6: priv_mapservice
     7: priv_internet
     8: priv_network_get
     9: priv_tethering_admin
    10: priv_email
    11: priv_tee_client
    12: audio
    13: display
    14: video
    15: priv_livecoredump
    16: priv_appdebugging

It can be clearly seen that lines 7 and 16 contain the mappings that are of interest in regards to internet access.


iptables configuration for this solution is kept in security-manager-policy-iptables package. It needs to be installed and nether package cannot be.


    1: *mangle
    8: -A INPUT ! -i lo -j SECMARK --selctx System
   10: -A OUTPUT -p igmp -j ACCEPT
   11: -A CHECK-LOCALHOST -p udp -m udp --dport 53 -j RETURN
   12: -A CHECK-LOCALHOST -p tcp -m tcp --dport 53 -j RETURN
   14: COMMIT
   15: *filter
   19: :REJECT-LOG -
   20: -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
   21: -A OUTPUT -m owner --uid-owner 0-5000 -j ACCEPT
   22: -A OUTPUT -m owner --gid-owner priv_internet --suppl-groups -j ACCEPT
   23: -A OUTPUT -d -m owner --gid-owner priv_appdebugging --suppl-groups -j ACCEPT
   24: -A OUTPUT -d -m owner --gid-owner priv_appdebugging --suppl-groups -j ACCEPT
   25: -A OUTPUT -d -m owner --gid-owner priv_appdebugging --suppl-groups -j ACCEPT
   26: -A OUTPUT -d -m owner --gid-owner priv_appdebugging --suppl-groups -j ACCEPT
   28: -A REJECT-LOG -m limit --limit 1/min -j AUDIT --type reject
   29: -A REJECT-LOG -j REJECT --reject-with icmp-net-prohibited
   31: COMMIT

Line 8 sets System label for all incoming packages from external network interfaces.

Line 20 guarantees that connections that were already allowed (are established or related, including UDP connections) are no longer checked. This is both for optimizations (don't check the outgoing packet for a connection that has been checked before) and for incoming packets that are from the allowed connection so they won't get dropped (if the default INPUT policy were ever set to DROP).

Line 21 guarantees that processes that run with 0-5000 UIDs have internet access without any groups/privileges. This is for system services.

Line 22 allows internet access to all processes that belong to the priv_internet group (either main or supplementary groups).

Lines 23-26 allow access to 4 specific IP address for processes that belong to priv_appdebugging group.

Lines 27-30 cause all other OUTPUT packages to be rejected and logged.

Modifying the configuration

Privilege group mappings

Privileges and their group mappings are kept and are managed in system-manager source package. Its sources are available here.

Policy configuration is kept in various files inside policy directory.

privileges policy/usertype-*.profile
privilege - group mapping policy/privilege-group.list

They are installed in the security-manager-policy sub-package into /usr/share/security-manager/policy directory.

For more information about creating new privileges and their group mappings look here and here.


Iptables configuration is also kept in security-manager source package. The source file for the IPV4 in the repository is: packaging/security-manager-iptables.rules. This file exists in security-manager-policy-iptables subpackage and is installed on the image as: /etc/security-manager-iptables.rules.

After adding new privilege/group/mapping we need to add custom iptables rules for this group. This is done by using owner module of iptables. This is relatively simple module and its usage can easily be seen in the current iptables configuration in lines 22-26 seen above.

Full owner configuration can be found in iptables-extentions(8) manual available online here.


Quick description


Nether is a standalone system service daemon, based on netfliter-queue and cynara and is described on nether page. It filters outbound network traffic based on application Cynara policy (access to internet privilege).

This mechanism doesn't support IPv6 and allows control only of outbound network traffic.

Nether allows runtime access control changes and supports multiuser, because its access control is based on Cynara policy.

Current configuration


Smack plays similar role here as with the GID solution.

The only difference here is that currently Nether does not check localhost packages (per iptables rules, see below). Only Smack is relevant here. While in the GID solution, both, Smack and GID have to allow a packet for it to pass through.

Please refer to the GID/Smack section for more information.

Nether / Cynara

Nether is a user-space agent that tests packets in the netfilter queue that has been sent to it by the iptables configuration (see below). Only the first packet of every new connection is sent so the performance hit is kept small.

Nether by default operates using cynara policy.



It finds the packet author's UID and security context then goes through the configuration file asking Cynara for every privilege found there. For the first positive response from Cynara it marks the packet with an ID in the configuration file (after the "|" sign) and stops. If Cynara denies access for all the privileges Nether marks the packet with the deny mark (0x3 by default, hard-coded in Nether, configurable with cmd-line parameter).

Due to this the order of the mappings is important.

Nether has one more special mark, allowAndLog (0x4 by default, also hard-coded in Nether and configurable with cmd-line parameter).

For more information about Nether look here.


Iptables configuration for nether is kept within the main nether package. security-manager-policy-iptables cannot be installed.


    1: *raw
    6: -A OUTPUT -p udp -j NFQUEUE --queue-num 0 --queue-bypass
    7: -A OUTPUT -p udplite -j NFQUEUE --queue-num 0 --queue-bypass
    8: -A CHECK-LOCALHOST -p udp --dport 53 -j RETURN
   10: COMMIT
   11: *mangle
   18: -A INPUT ! -i lo -j SECMARK --selctx System
   20: -A OUTPUT -p igmp -j ACCEPT
   21: -A OUTPUT -p tcp -m conntrack --ctstate NEW ! --ctstatus CONFIRMED -j NFQUEUE --queue-num 0 --queue-bypass
   22: -A CHECK-LOCALHOST -p tcp --dport 53 -j RETURN
   24: COMMIT
   25: *filter
   30: :NETHER-DENY -
   31: -A OUTPUT -m mark --mark 0x3 -j NETHER-DENY
   32: -A OUTPUT -m mark --mark 0x4 -j NETHER-ALLOWLOG
   33: -A NETHER-ALLOWLOG -j AUDIT --type accept
   35: -A NETHER-DENY -j AUDIT --type reject
   36: -A NETHER-DENY -j REJECT --reject-with icmp-port-unreachable
   38: COMMIT

Line 18 sets label System to all incoming packages.

Lines 6-7 and 20-21 send all outgoing packages to netfilter queue that the Nether reads from.

Lines 5, 8-9, 19 and 22-23 cause almost all localhost outgoing packages to be accepted without Nether. The only exception is port 53, DNS. Those packages are sent to Nether as well.

Lines in filter table (below line 25) are used to handle marked packages from Nether.

Lines 31 and 35-37 handle packets marked with 0x3. They are logged and rejected.

Lines 32 and 33-34 handle packets marked with 0x4. They are logged and accepted.

All other marks pass through the filter table rules and are allowed by default per the default OUTPUT rule (line 28).

Modifying the configuration

Nether / Cynara

Privilege to mark mappings are kept and are managed in nether source package. Its sources are available here.

They are in the conf/cynara.policy file. Format is simple:




iptables rules for Nether are also kept in the nether source package.

The configuration file for IPV4 is conf/nether.rules. To add rules for new marks (e.g. to allow only specific IP) we need to create new rules in the filter table.

Let's say we marked a packet with mark 0xdb as in the example above and we want to allow processes with this privilege access to only one IP, like We'd add new lines to the rules (e.g. in between lines 32 and 33):

   -A OUTPUT -m mark --mark 0xdb -d -j ACCEPT
   -A OUTPUT -m mark --mark 0xdb -j REJECT

Privilege-Smack mapping

Quick description


  • security-manager since 1.6.0 version
  • Tizen running only with single user (no multiuser support)
  • netlabel and ipv6host configuration (see Smack documentation)

Using security-manager privilege-Smack mapping mechanism, Internet access control can be expressed as Smack label identifying Internet connection (this requires proper configuration of Smack netlabel and ipv6host) and a set of Smack template rules (see here for template rules and privilege-Smack mapping explanation) to allow inbound and outbound traffic. These rules will be applied for each launched application granted Internet privilege.

For connection between application and Internet, default 'priv-rules-default-template.smack' Smack rules template can be used (provided by security-manager-policy RPM package since 1.6.0).

Privilege-Smack mapping rules are based on privilege Smack label and application label. Because currently on Tizen application label is based only on application packaged id and application id (there is no information about user context), rules for different users, but same application and privilege, are the same. Thus this mechanism currently cannot support multiuser.

This mechanism supports IPv6 and allows control of both outbound and inbound network traffic.

Privilege-Smack mapping allows runtime access control changes. When application is allowed/denied the privilege, the Smack rules are applied/removed from the system.

Enabling the solution

As it currently stands, the framework for the solution is finished, but the ready to use solution itself is not prepared. There is no "install this package to enable the solution". It has to be done by hand.

To enable it now, at least the following steps have to be made:

1. Make sure that neither nether nor security-manager-policy-iptables is installed on the image.

2. Modify the content of /etc/smack/netlabel.d/netlabel_config to: System::Privilege::Internet

This file belongs to security-config package that is a part of repository by the same name. This way the label for all the packages that are not localhost will be set to System::Privilege::Internet label. This can be seen in /sys/fs/smackfs/netlabel file.

3. Uncomment the internet rule (last line) of the /usr/share/security-manager/policy/privilege-smack.list file that belongs to security-manager-policy package that is a part of security-manager repository. System::Privilege::Internet default

4. The following needs to be added to the default smack rules.

     System System::Privilege::Internet w
     System::Privilege::Internet System w

The file that keeps them is /etc/smack/accesses.d/default-ac-domains that is installed by default-ac-domains package that is a part of a repository by the same name.

This is required for the system services to have internet access. More rules might be required. The outcome can be seen in the /sys/fs/smackfs/load2 file.

Solution description

With the changes described in the previous section made we caused the following:

1. Every host/interface having an IP address different than localhost is labeled System::Privilege::Internet.

2. For a process to be able to send a package to such IP or to receive one from it there needs to be a rule:

     ${PROCESS_LABEL} System::Privilege::Internet w
     System::Privilege::Internet ${PROCESS_LABEL} w

3. For system services this is guaranteed by manually adding the rules to the list of default system rules in default-ac-domains mentioned above.

4. For user applications this will be done in run-time by security-manager. Depending on an application having privilege security-manager will add and/or remove smack rules based on the default template that is in the /usr/share/security-manager/policy/privilege-mapping/priv-rules-default-template.smack file:


~PROCESS~ will be replaced by the application's label. ~PRIVILEGE~ will be replaced by a label that is configured for a specific privilege. This will be System::Privilege::Internet in this case.

Iptables is not used in this solution.

Modifying the configuration

If a new privilege that would govern access to a specific IP is required (like we did for previous solutions) the following needs to be done:

1. New privilege/label mapping needs to be created in /usr/share/security-manager/policy/privilege-smack.list file that belongs to security-manager-policy package that is a part of security-manager repository. E.g.: System::Privilege::Internet default System::Privilege::New_Priv default

2. The new label needs to be applied to the IP address(es) we want. This is done in the /etc/smack/netlabel.d/netlabel_config file that belongs to security-config package that is a part of repository by the same name. The order of lines is important. E.g.: System::Privilege::New_Priv System::Privilege::Internet

And that's it. Unfortunately such a solution has a big drawback. Now every process (either system service or user application) that has access to System::Privilege::Internet label (as was configure previously) now lost access to IP that is now governed solely by System::Privilege::New_Priv label.

So when adding a new rule one needs to make sure that other processes that had internet privilege now also have new_priv privilege if that's what required.


Mechanism Multi-user support IPv6 support Inbound network control Outbound network control
GID Yes Yes No Yes
Nether Yes No No Yes
Smack No Yes Yes Yes