SELinux Policy Management Server - Use Case

Introduction

Administration of SELinux policy is inherently “all or nothing” -- giving a user or application the ability to update any part of the policy allows for unrestricted updates to the entire policy. This makes it difficult to securely delegate policy administration to multiple administrators or to create automated policy management tools. Such unrestricted access can be prevented by the use of the Policy Management Server, which provides the following functionality:

• Encapsulates the SELinux policy to mediate all policy access;
• Enforces fine-grained access control over policy changes;
• Provides enhanced policy management infrastructure.

Example Scenario

The following scenario illustrates the use of the Policy Management Server:

Isolated domains on mobile devices

Because of the distributed nature of mobile devices, security is a great concern. Users of mobile devices often install third party applications from untrusted sources, and security vulnerabilities in these third party applications could compromise the entire system. To mitigate these potential security vulnerabilities, SELinux can isolate these applications into security domains.

In order to allow security domains to be created when new applications are installed, the SELinux policy must be updated. While it would be possible to create new domains with no access control on the policy, there would be no assurance that the new domains would maintain the intent of the security policy, to keep the untrusted applications isolated from the rest of the system.

Using the Policy Management Server, the policy intent can be enforced via the meta-policy. The meta-policy would be architected so that isolated domains are always under the parent type untrusted_app. When a new application is installed, a policy helper would be able to create a new application domain under the untrusted_app parent type but could not exceed the permissions of untrusted_app. This allows the mobile device vendor to define the maximum allowed permissions for third party applications and policies can be created for these applications when they are being installed.

An example policy template for untrusted_app could allow access to standard system resources as required, such as libraries and system configuration files but nothing that could compromise the system. In this example, the templates for the third party applications might look like this:

template(`untrusted_app_template', `

        ########################################
        #
        # Declarations
        #

        application_executable_file($2)

        application_domain($1,$2)

        #
        # Local policy
        #

        #allow this domain to do what it wants with its own files and dirs
        allow $1 self:file manage_file_perms;
        allow $1 self:dir manage_dir_perms;

        unconfined_domtrans_to($1, $2)

        libs_exec_lib_files($1)
        libs_read_lib_files($1)
        libs_search_lib($1)
        libs_use_ld_so($1)
        term_use_all_terms($1)
        miscfiles_read_localization($1)
        domain_use_interactive_fds($1)
        files_read_etc_files($1)
        fs_getattr_all_fs($1)
        fs_search_auto_mountpoints($1)

        #temp hack because refpolicy has a bug
        role unconfined_r types $1;
')

interface(`untrusted_app_network_access',`

# allow our sandboxed apps to access the network
# This is here instead of in the main template so that
# a new sandboxed app can be restricted from network
# access if that is desirable. 
        corenet_all_recvfrom_unlabeled($1)
        corenet_all_recvfrom_netlabel($1)
        corenet_tcp_sendrecv_generic_if($1)
        corenet_udp_sendrecv_generic_if($1)
        corenet_raw_sendrecv_generic_if($1)
        corenet_tcp_sendrecv_all_nodes($1)
        corenet_udp_sendrecv_all_nodes($1)
        corenet_raw_sendrecv_all_nodes($1)
        corenet_tcp_sendrecv_all_ports($1)
        corenet_udp_sendrecv_all_ports($1)
        corenet_raw_bind_all_nodes($1)
        corenet_tcp_bind_all_nodes($1)
        corenet_udp_bind_all_nodes($1)
        corenet_tcp_connect_all_ports($1)
        corenet_sendrecv_all_client_packets($1)
        corenet_sendrecv_all_server_packets($1)
')

With these templates in place one could create an isolation domain that has the standard sandbox permissions with or without network access. More fine-grained file system and network access could also be given. A policy module to create a new sandbox domain with network access would simply look like this:

policy_module(untrusted_app_one,0.0.1)

########################################
#
# Declarations
#

# Types for first sandbox domain
type untrusted_app.one;
type untrusted_app _exec.one;

# Call template for first sandboxed domain
untrusted_app_template(untrusted_app.one, untrusted_app_exec.one)
untrusted_app_network_access(untrusted_app.one)

The meta-policy labeling statements that allow a policy helper tool to create new child domains but not modify the untrusted_app parent domain would look like:

type untrusted_app                       gen_context(system_u:object_r:untrusted_app_type,s0)
type untrusted_app_exec              gen_context(system_u:object_r:untrusted_app_type,s0)

The meta-policy would look like:

allow policy_helper_t untrusted_app_type:policy.type {add remove use };
allow policy_helper_t untrusted_app_type:policy.attribute {add remove add_type }; 
allow policy_helper_t unlabeled_t:policy.class {add remove use add_perm };