Typeenforcement (Type-based Mandatory Access Control)

Typeenforcement (Type-based Mandatory Access Control)

(1) Introduction

In SELinux, all access requests must be explicitly agreed. SELinux has no access by default, regardless of the Linux User ID and group ID. Yes, this means that no default Super User exists in SELinux, unlike the root user in standard Linux. The agreed access method is specified by the subject type (that is, the domain) and object type using an allow rule. An allow rule has four elements:
1: source type (s), usually the domain of the process to be accessed
2: target type (s), the type of the object to be accessed by the Process
3: object class (es), the specified class of objects that can be accessed
4: permission (s): The access method of the subject's access object category

For example, the following rule:
Allow user_t bin_t: file {read execute getattr };

This example shows the basic syntax of the TE allow rule. This rule has two types of identifiers: source type (or subject, or domain), user_t, target type (or object), bin_t. The identifier file is the name of an object type defined in the policy (in this example, it represents a binary file ). Permissions in curly braces is a subset of permission that is valid for a file object category. The translation of this rule is:
A process whose type identifier is user_t can read, execute, or obtain attributes of a file whose type identifier is bin_t.

As we will discuss below, permissions in SELinux is more detailed than standard linux. In standard linux, there are only three permissions, rwx (readable, writable, executable ). In this example, read and execute are the same as traditional ones. Getattr is not very obvious. In fact, the getattr permission allows callers to view (not change) the attributes of a file, such as the date, time, and Access Mode Controlled by themselves. In a standard Linux system, a caller only needs the permission to search the file directory to view the information of the file, even if he does not have the permission to read the file.

Assume that user_t is a common, non-privileged user process (such as a login shell process) domain type, bin_t is the identifier of an executable program (for example,/bin/bash) that must have special security privileges. This rule may allow users to execute shell programs, for example, bash shell.

Note:
In the type identifier name, _ t has no special meaning. This is only a naming convention used in most SELinux policies. Policy definers can define any compliant names as long as they comply with the syntax of the policy language.

Through this chapter, we often use symbols to describe allowed access: circles represent processes, boxes represent objects, and arrows represent allowed access. For example, the following figure shows the access allowed by the previous allow rule.

(2) Examples of type forced Mechanism

The allow rules of SELinux, such as the example mentioned above, are used in SELinux to allow access. The problem is that when tens of thousands of access requests are decided, only necessary access is allowed, and the system can work normally to ensure its security as much as possible. <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Examples/examples + examples/templates/yda00NDOxLz + 09BzZXR1aWTOu7yvus + jrMv50tSjrLWxy/uxu8bky/examples + examples/ keys/keys + keys/Kx8/gy8a1xL/keys + keys/e1xKGjPC9wPgoKPHA + pgltzybzcm9 "http://www.2cto.com/uploadfile/Collfiles/20150426/20150426091202534.png" alt = "here write picture description" title = "\ ">

In this example, we define two types. Passwd_t is a domain type used by the cryptographic program. The shadow_t identifier is the identifier of the shadow password file. If we check a file like this on the disk, we will see the following information:

# Ls-Z/etc/shadow
-R -- root system_u: object_r: shadow_t shadow

Similarly, in this policy, checking a process running in a password program will display the following information:
# Ps-Z
Joe: user_r: passwd_t 16532 pts/0 00:00:00 passwd

For now, you can ignore the user and role elements in the security context and focus only on identifiers.

Check the allow rule in Table figure 2-2. The rule aims to grant the process identifier (passwd_t) The permission to access the shadow file identifier, this permission allows the process to move or create a shadow password file. Therefore, review figure 2-2. The process that runs the password program described in the Cup can successfully manage the shadow password file, because it has a valid root User ID) (Access Control in standard linux), and because TE's allow rules allow him to have sufficient access to the shadow password file identifier (Access Control in SELinux ). Both are necessary, but not sufficient.

2.2.2 domain Conversion Problems

If what we need to do is to allow a process to access objects, such as files, then writing a TE policy will be simple. However, we must understand how to ensure that a proper program runs on a process with a correct domain type. For example, a program runs in a certain way using the passwd_t domain type, but this program is untrusted and we don't want it to access our shadow password file. This may be disastrous. This problem will bring us the problem of domain type conversion.

For clarity, see figure 2-3. In this figure, we have elaborated on the previous example of a password program. In this typical system, a user (called joe) logs on to the system by logging on to the process and creates a shell process cup (such as running bash ). In standard linux security, real and effective user IDS (that is, joe) are the same. In our example, in SELinux policy, the process type is user_t, and user_t is the domain Type Applicable to common and untrusted user processes. When joe's shell runs other programs, the domain type of the new process created by the joe user will remain user_t unless other behaviors are taken. So how does joe change the password?

We do not want joe's untrusted domain type user_t to have the ability to directly read or write shadow password files, because it may make any program (including joe's shell program) allows you to view or modify the content of important files. As discussed earlier, we hope that only the password program will have such access permissions only when it runs in the domain type passwd_t. Then the question arises: how can we provide a set of secure and reliable solutions, in addition, there is no abrupt mechanism to make the shell program of joe whose domain type is user_t transition to the process that runs the password program whose domain type is passwd_t.

2.2.3 review the setUID program in standard Linux security

Before discussing how to handle domain conversion, let's review how similar issues are handled in standard linux, that is, how to provide joe with a safe way to change his password. In Linux, the user ID (setUid) is set for passwd to the root program. If you list the password program files in a typical linux system, you will see the following form

Note two things about this list. The first is the owner permission of s at x. This is the so-called setuid bit, which means that for any process that executes this file, its valid UID (that is, the user ID used for Access Control) will be changed to the file owner. In this example, root is the owner of the file, so the executable password program will always run with a valid root User ID. The following figure shows the process.

When joe runs the password program, joe's shell program will use the fork () system call to create a copy similar to himself. This replica process still maintains the same user ID (joe) and runs shell programs. Then, after being created, the new process will execve the execve () System Call to run the password program. In standard linux, the process is required to have executable permissions on the Program (x). In this example, it is correct because anyone has executable permissions on the password file. After the execve () call is successfully executed, two key tasks occur. The first is that the shell program in the new process will be replaced by the password program. Second, because setuid is set as the file owner, the valid user ID changes from the original ID of the process to the ID of the file owner (in this example, It is root ). Because the root user can access any file, the password program can now access the shadow password file and process requests from joe to change the password.

The use of setuid bits is built in unix-like operating systems and is a simple and powerful feature. However, he also explained major defects in standard linux security. The password program needs to access the shadow file as a root user. Then, when running as a root user, the password program can also access any system resources. This also violates the core principle of Security Engineering-Minimum permissions. Therefore, we must trust that the cryptographic program will not take other possible actions on the system. For real security applications, a cryptographic program requires a lot of code reviews to ensure that it will not abuse his permissions. In addition, when unexpected errors occur in the password program, it may cause a security vulnerability, which far exceeds the loss caused by access to the shadow password file. Although the password program is relatively simple and highly trusted, what if other programs (including logon programs) Run as root users?

What we really like is to ensure that the password program and any other program with the minimum permissions must have. Simply put, we hope that the cryptographic program can only access the shadow file and other password-related files and necessary minimum system resources. At the same time, I want to ensure that no program except the password program can access the shadow password file. In this way, when evaluating security issues for user account management, we only need password programs (or similar programs) the role played in managing user accounts does not have to consider other programs,

The following describes the domain conversion of the TE security mechanism.

2.2.4 domain Conversion

As shown in figure 2-2, the allow rule ensures that the passwd process domain type (passwd_t) can access the shadow password file. However, we still have the domain conversion problem we just described. The concept of secure domain transition is similar to that of the setuid program, but it is implemented under the TE mechanism. To illustrate, we use the setuid example and add the preceding TE.

Now our example is more complex. Let's take a closer look at this figure. First, we have added the three types shown previously, namely, the shell domain (user_t) of joe and the domain ID (passwd_t) of the cryptographic program ), and shadow_t ). In addition, we also added the File Identifier (passwd_exec_t) for the passwd executable file ). For example, the security context of the password program listed on the disk will get the following result.

Now, we have enough information to create TE policy rules to allow the password program to run with passwd_t as the domain ID. Let's take a look at the Rules in. Rule 1:

This rule allows joe's shell (user_t) to initiate an execve () System Call to the passwd executable file (passwd_exec_t. The execute file permissions of SELinux are essentially the same as the x access permissions of standard linux Files. (The shell collects statistics on the file before trying to run it, so the getattr permission is also required.) Review the description about how the shell program works. First, he fork his own copy, including completely identical security attributes. This copy still maintains the original domain ID (user_t) of joe's shell ). Therefore, the execute Permission must point to the original domain (that is, the domain ID of the shell ). This is why user_t is the source ID of this rule. (Source type)

Next let's take a look at the second allow rule:

This rule provides an endpoint for accessing the passwd_t domain ). Entrypoint is a valuable permission in SELinux. This permission defines which executable file (thus, Which program) may enter a domain. For a domain transition, the new or "to-be-entered" (to be entered) domain (in this example, passwd_t) be sure to have an entrypoint to access the executable file for the transition to a new domain ID. In this example, assume that only the passwd executable file is marked as passwd_exec_t, and only the passwd_t has the entrypoint permission of passwd_exec_t, so that only the password program can run in the passwd_t domain identity. This is a very powerful security control.

Warning:
The concept of entrypoint permission is very important. If you cannot fully understand the preceding example, read it again before continuing to read it.

Now let's take a look at the last rule:

This is the first allow rule we have seen that does not provide access to object files. In this instance, the object class is process, that is, the object class representing the process. Review that all system resources are encapsulated in the object class. This concept also applies to processes. In the last rule, the permission is transition access. The identifier of the security context of the permission process is changed. The original identifier (user_t) must have the transition permission to be allowed to be converted to a new identifier (passwd_t ).

These three rules provide the necessary conditions for domain conversion. To successfully convert a domain, all three conditions must be met. Therefore, when all three of the following conditions are met, a domain conversion is allowed.

1: The New Domain ID of the process has the entrypoint permission for the executable file ID.
2: The current (or past) process domain ID has the execute permission on the entry point File ID
3: the current domain ID of the process has the transition permission on the new domain ID

If all the three permissions in the TE policy are agreed, a domain conversion occurs. Further, for the use of the entrypoint permission of the executable file, we have the ability to strictly control which program can run on a given domain ID. Execvte () is used to change the unique method of domain identification during system calls, so that the policy definer can control the access permissions of the personal program, regardless of who calls the program.

Now the question is how joe shows that he wants to perform domain conversion. The above rules only allow domain conversion, and they do not command it. There are some ways for programmers or users to explicitly require domain conversion (if allowed ). What joe wants to do is to run the password file. He wants the system to ensure that the password file can be executed. We need a way to enable the system to initialize a domain conversion by default.

2.2.5 default domain conversion: type_transition statement

To support domain conversion by default (as in the example of a cryptographic Program), we need to introduce a new rule, type transtion rule (type_transtion ). This rule provides a method for SELinux policies. If an obvious conversion is not required, you need to specify a default conversion that should be tried. We will add the following tyoe transition rule for the allow rule:

In a system call, if the domain ID of a called process is user_t and the ID of an executable file is passwd_exec_t (in the figure example above ), A domain to a new domain (passwd_t) will be attempted.

The type_transition rule allows the policy definer to initiate a domain conversion by default when there is no clear user input. This prevents users from being forced by the TE mechanism. In our example, joe doesn't want to know anything about access control and identity; he wants to change the password. The system and policy definer can use type_transition rules to perform these conversions for users.

Note:
Remember that a type_transition rule will lead to a default domain conversion attempt, but it will not allow it. To ensure the successful completion of domain conversion, you still need to provide the three identifiers required for domain conversion, whether it is initialized by default or as a user-defined requirement.