SEAndroid - SELinux for Android [Part One] : Introduction to SELinux

SELinux .

In the fields of physical security and information security, access control (AC) is the selective restriction of access to a place or other resource. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called authorization.

In a multiple user environment, it is important that restrictions are placed in order to ensure that people can only access what they need. In this regard, Mandatory Access Control (MAC) and Discretionary Access Control (DAC) are two of the popular access control models in use.

The main difference between them is in how they provide access to users. 

With MAC, admins creates a set of levels and each user is linked with a specific access level. He can access all the resources that are not greater than his access level. 

In contrast, each resource in DAC has a list of users who can access it. DAC provides access by identity of the user and not by permission level.

SELinux concepts.

 Security Enhanced Linux (SELinux), is a mandatory access control (MAC) system for the Linux operating system. As a MAC system, it differs from Linux’s familiar discretionary access control (DAC) system.

 SELinux is implemented as part of the Linux Security Module (LSM) framework, which recognizes various kernel objects, and sensitive actions performed on them.

At the point at which each of these actions would be performed, an LSM hook function is called to determine whether the action should be allowed based on the information for it stored in an opaque security object.

SELinux provides an implementation for these hooks and management of these security objects, which combine with its own policy, to determine the access decisions.

Security-enhanced Linux (SELinux) began as a set of core components and user tools launched by the NSA (National Security Agency) and added to the Linux system to allow applications to run at their required minimum privileges.

The unmodified Linux system is controlled by autonomous access. Users can request higher privileges themselves, so that malicious software can access almost any file that it wants to access, and if you grant it root privileges, and then it will have nothing to do.

Some rules of this game.

1.     There is no concept of root in SELinux.

2.     The security policy is defined by the administrator. No software can override it.

3.     This means that the damage a potential malware can cause can be kept to a minimum. 

When a subject (eg, an application) tries to access an object (eg, a file), the policy execution server in the Kernel will check the AVC (Access Vector Cache).

In AVC, subject and object permissions are cached. If a decision cannot be made based on the data in the AVC, the security server is requested and the security server finds the security context of "application + file" in a matrix. Then allow or deny access based on the result of the query.

The details of the reject message are located in /var/log/messages.

SELinux pseudo file system [/selinux/]

    The pseudo-file system kernel subsystem usually uses commands similar to the /proc/  file system. 

System administrators and users do not need to operate this section. 

Contents of the /selinux/directory are asfollows:

 Example: cat enforce

   1: enforcing mode 

   0: permissive mode

SELinux configuration file.

 The SELinux configuration or policy file is located in the /etc/ directory.

 /etc/sysconfig/selinux .

We can configure SELinux by editing the configuration file (/etc/sysconfig/selinux) which contains the following configuration options:

  1) Turn SELinux on or off

  2) Set which policy the system executes (policy)

  3) Set how the system executes the policy

Configuration File Options

1.     SELINUX

    SELINUX=enforcing|permissive|disabled—Defines SELinux's advanced status

a.     enforcing — The SELinux security policy is enforced.

b.     permissive — The SELinux system prints warnings but does not enforce policy.

c.     disabled — SELinux is fully disabled. SELinux hooks are disengaged from The kernel and the pseudo-file system is unregistered.

2.     SELINUXTYPE (Security Policy)

     SELINUXTYPE=targeted|strict — Specifies which policy SELinux executes.

a.      targeted — Only target network daemons are protected. Whether each daemon executes a policy can be configured via system-config-selinux. Protect common network services for SELinux defaults.

You can use the following tools to set the boolean value for each.

                i.          getsebool -a: List all boolean SELinux.

              ii.          setsebool: Set SELinux Boolean, such as: setsebool -P dhcpd_disable_trans = 0, -P means that even after using reboot, it is still valid.

b.     strict—Performs full protection of SELinux. A security environment is defined for all subjects and objects, and each Action is processed by the policy execution server. Provides a Role-based-Access Control (RBAC) policy with full protection capabilities to protect network services, general commands and applications.

3.     SETLOCALDEFS

     SETLOCALDEFS=0|1 — Controls how the user definitions and booleans are set.

a.     1: These definitions are controlled by load_policy, which comes from the file /etc/selinux/<policyname>

b.     0: controlled by semanage

4.      /etc/selinux/ Directory

/etc/selinux/ is the directory where all policy files and major configuration files are stored. 

SELinux Tools

1)    /usr/sbin/setenforce — Modify the SELinux operating mode. An example is as follows:

a.     setenforce 1 – SELinux in enforcing mode 

b.     setenforce 0 - SELinux runs in permissive mode

    To shut down SELinux, you can modify the configuration file: /etc/selinux/config.

2)    /usr/sbin/sestatus -v - Displays the detailed status of the system.

3)    /usr/bin/newrole - Run a new shell in a new context or role

4)    /sbin/restorecon - Sets the security environment for one or more files by marking extended attributes for the appropriate file or security environment

5)    /sbin/fixfiles - check or correct the security environment database in the file system

6)    getsebool - getsebool -a: See all Boolean values

7)    setsebool - parameter -P, permanent setting

8)    chcon modifies the security context of files and directories

a.     chcon -u[user]

b.     chcon -r[role]

c.     chcon -t[type]

d.     chcon -R recursion

Type Enforcement Security Context

The security context is a simple, consistent access control attribute.

In SELinux, the type identifier is the main component of the security context. For historical reasons, the type of a process is usually referred to as a domain. The meaning of "domain type" is the same.

Usually, we think that [domain], [domain type], [subject type], and [process type] are all synonymous, that is, Is the " TYPE " in the security context .

SELinux modifies many of the commands in the system by adding a -Z option to display the security context of the object and the principal.

Example:

                I.          ls –z

             II.          ps –z , etc..

Security Context Format

      All operating system access controls are based on certain types of access control attributes of associated objects and principals. 

In SELinux, access control attributes are called security contexts. All objects (files, interprocess communication channels, sockets, web hosts, etc.) and principals (processes) have a security context associated with them.

A security context consists of three parts: user, role, and type identifier. 

The security context is often specified or displayed in the following format:

      USER:ROLE:TYPE[LEVEL[:CATEGORY]]

      The user and role identifiers in the security context have little effect on type-enforced access control policies except that there is a little constraint on enforcement.

For processes, user and role identifiers appear more meaningful because they are used to control the type and user identifiers. This will be associated with the Linux user account; However, for the object, user and role identifiers are rarely used, in order to regulate management, the role of the object is often object_r, the object of the object is often the process of creating the object User identifiers.

The distinction between user IDs in standard Linux security and user identifiers in security contexts, as far as technology is concerned, are orthogonal identifiers used for standard and security-enhanced access control mechanisms, respectively.

USER

1.     user identity: similar to the Linux system UID, providing identification, used to record identities; part of the security context.

2.     Three types of user:

a.     user_u: the default after the normal user logs in to the system

b.     system_u: the default of the system process during the boot process.

c.     root : root default after login;

3.     Users are not very important in the targeted policy; 

4.     In the strict policy,it is important that all pre-defined SELinux Users end with "_u" except root.

ROLE

1.     The role of the file, directory and device: usually object_r; 

2.     The role of the program: usually system_r; 

3.     The user's role: targeted policy system_r; strict policy sysadm_r, staff_r, user_r; user's role, similar to the system In the GID, different roles have different permissions; users can have multiple roles; but only one role can be used at the same time; 

TYPE

1.     type: used to divide the subject and object into different groups, define a type for each subject and the object in the system; provide the lowest authority environment for running the process; 

2.     when a type When associated with a process in progress, its type is also known as the domain; 

3.     type is the most important part of the SElinux security context, the heart of the SELinux Type Enforcement, and the default value ends with _t;

SELinux vs Standard Linux Access Control Attributes.

      In standard Linux, the access control attribute of the principal is the real and effective user and group ID associated with the process through the process structure in the kernel.

These attributes are protected by the kernel using a number of tools, including the login process and the setuid program, for the object ( As for files), the file's inode includes a set of access mode bits, file users, and group IDs. 

Previously access control was based on read/write/execution of these three control bits, one for the owner of the file, one for the owner of the file, and one for each other.

In SELinux, access control attributes are always in the form of a security context trio (user: role: type), and all objects and entities have an associated security context.

In particular, because SELinux's main access control feature is type enforcement , the type identifier in the security context determines the access rights.

Note: SELinux adds Type Enforcement (TE) to standard Linux. This means that both standard Linux and SELinux access control must be able to access an object first.

For example: If we have SELinux on a file Write permission, but we don't have permission for the file, we can't write the file either. 

The following table summarizes the comparison of access control attributes between standard Linux and SELinux: 

In Short.

1.     Each file, directory, network port, etc. in the system is assigned a security context, and policy provides the rules of action between security contexts.

2.     SELinux decides whether the access is executable according to policy and security context rules.

3.     Subject: system process, such as /usr/sbin/httpd.

4.     Object: item accessed, such as File, Directory, IP, Socket, etc.

Type Mandatory (TE) Access Control.

     In SELinux, all access must be explicitly authorized. SELinux does not allow any access by default, regardless of the Linux user/group ID. 

This means that in SELinux, there is no default superuser , unlike root in standard Linux, which grants access permissions by specifying the subject type (ie, domain) and object type using allow rules.

The allow rule consists of four parts:

1.     The source type (Source type(s)) is usually the domain type of the process that is trying to access.

2.     Target type(s) The type of object accessed by the process.

3.     Object class(es) Specifies the allowed access type of object.

4.     Permission(s)

An example of the type of access that symbolizes the target type allows the source type to access the object type is as follows:

 Allow user_t bin_t : file {read execute getattr};  

Explanation:

This example shows the basic syntax of the TE allow rule. This rule contains two type identifiers: source type (or body type or domain) user_t, target type (or object type) bin_t. 

The identifier file is the name of the object class defined in the policy (in this case, an ordinary file), and the permissions included in the braces are a subset of the valid permissions for the file object class.

This rule is explained as follows:

Processes with the domain type user_t can read/execute or retrieve properties of a file object with a type of bin_t.

The SELinux allow rule, as in the previous example, is actually granting access rights in SELinux.

Now, That we have a basic understanding of SELinux. We will learn how this is used and adapted by Android which has several Apps/Services/Executables which are in constant need of resources and the real challenge is how to guarantee tens of thousands of accesses to the correct authorizations, grant only the necessary permissions, and achieve as much security as possible.