Type enforcement (types mandatory access control)

(a), introduction

In SELinux, all visits are explicitly agreed upon. SELinux defaults to no access, regardless of the Linux User ID and group ID. Yes, this means that there is no default Superuser in SELinux, unlike the root user in standard Linux. The way to access is agreed by the type of the principal (that is, the domain) and the type of the object is specified using an Allow rule. An Allow rule has four elements:
1:source type (s), usually the domain of the process you are trying to access
2:target type (s), the kind of object to be accessed by the process
3:object Class (es), the specified object category for the allowed access
4:permission (s), the access mode of the subject Access object category

As an example, the following rules:
Allow user_t bin_t:file {read Execute getattr};

This example shows the basic syntax of the te allow rule. This rule has two type identifiers: the source type (or the subject, or the domain), the user_t, the target type (or object), and the bin_t. The identifier file is the name of an object type that is defined in the policy (in this case, a binary file is represented). The permissions in curly braces is a subset of permission that is valid for a file object category. The translation of this rule is:
A type identifier is a user_t process that can read, execute, or get properties of a file object with a type identifier of bin_t.

As we will discuss below, the permissions in SELinux (permissions) are more granular than standard Linux, with only three permissions in standard Linux, rwx (readable, writable, executable). In this example, read and execute are the same as traditional. GetAttr is not very obvious. In fact, getattr permissions allow callers to see (not change) the properties of a file, such as date, time, and autonomous control access patterns. In a standard Linux system, a caller only needs the permission to search the file directory to view that file's information, even if he does not have permission to read access to the file.

Assuming that user_t is an ordinary, unprivileged user process (such as a login shell process), bin_t is an identifier for an executable program (for example,/bin/bash) that a user must have unique security privileges to run. This rule may allow the user to execute shell programs, such as the bash shell.

Attention:
In the name of the type identifier, _t is of no special significance. This is only a naming habit that is used in most selinux policies, and as long as the syntax of the policy language is met, the policy definition can define any name that conforms to the specification.

Through this chapter, we often use some symbols to describe the permitted access: The circle represents the process, the box represents the object, and the arrow represents the allowed access. For example, the following figure depicts the access allowed by the previous allow rule.

(ii) Examples of type enforcement mechanisms

SELinux allow rules, such as those mentioned above, are used in selinux to consent to access. The problem is that when you decide on thousands of visits, you can only allow the necessary access, but also make the system work properly and make it as secure as possible.

To explore the TE mechanism in more depth, let's cite an example of a password management program (aka passwd). In Linux, read or modify the shadow password file (/etc/shadow) is trustworthy, in the shadow file, the encrypted password is stored inside. The password program implements his own internal security policy, allowing ordinary users to modify only their own passwords, while allowing the superuser to modify any password. In order to accomplish this trustworthy work, the cryptographic program needs to have the ability to move and recreate the shadow file. In Standard Linux, he has this privilege because the password program executable has a setuid bit set, so when he is executed by someone else, it will also run as a superuser (he can access any file).
However, many programs can run as superuser (in fact, all programs may run as Superuser). In other words, any program that runs as Superuser can potentially modify the shadow password file. The TE mechanism lets us make sure that only the password program (or a similar, trusted program) can access the shadow file, regardless of the user who runs the program.

Shows how the password program works in SELinux using the TE mechanism.

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

# ls-z/etc/shadow
-r--Root root system_u:object_r:shadow_t Shadow

Similarly, under this strategy, checking a process running in the password program will display the message:
#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, focusing only on identifiers.

Check the Allow rule in Figure 2-2 of the table, which is intended to give the process identifier (passwd_t) access to the shadow file identifier, which allows the process to move or create a shadow password file. So, take a second look at Figure 2-2, the process of running the password program described by the Cup can successfully manage the shadow password file because he has a valid Superuser user ID (root) (access control in standard Linux), And because TE's allow rule allows him to have sufficient access to the shadow password file identifier (access control in SELinux). These two are necessary, but not sufficient, conditions.

2.2.2 Domain Conversion Issues

If what we need to do is allow a process to access the object, such as a file, then writing a TE strategy will be straightforward. But we need to figure out how to make sure that a proper program runs on a process with the correct domain type. For example, there is a program that runs in a process in some way using the passwd_t domain type, but this program is untrusted and we don't want him to visit our shadow password file. This could be disastrous. This issue will give us the problem of domain type conversion.

For clarity, look at Figure 2-3, in which we have elaborated on examples of previous cryptographic procedures. In this typical system, a user (called Joe) logs into the system via the login process, creating a Shell process Cup (for example, running bash). In standard Linux security, the real-life user IDs (that is, Joe) are the same. In our example SELinux policy, the process type is user_t,user_t, which is the domain type that applies to normal, untrusted user processes. When Joe's shell runs another program, the domain type of the new process that the Joe user is creating will remain user_t unless some other behavior is taken. So, how does Joe change the password?

We don't want Joe's untrusted domain type user_t to have the ability to read directly or to write shadow password files, as this would potentially enable any program (including Joe's Shell program) to view or modify the contents of important files. As discussed earlier, we would like to have only the password program, and this password program only when the domain type passwd_t run only when this access rights. So the question is, how can you provide a safe, secure, and unobtrusive mechanism to transition a shell program of Joe with a domain type of user_t to a process running a password program of domain type passwd_t.

2.2.3 Review the SETUID program in standard Linux security

Before discussing how to deal with domain transformations, let's review how similar problems in standard Linux are handled, that is, how to provide Joe with a way to safely modify his password. The way to deal with this problem in Linux is by setting the user identifier (SETUID) to passwd to the root program. If you are in a typical Linux system, list the password program files, you will see the following form

Note the two things about this list. The first is the owner's permission at x point. This is called the setuid bit, which means that for any process that executes the file, his valid UID (that is, the user ID used to access the control decision) will be changed to the owner of the file. In this example, Root is the owner of the file, so the running password program will always run with a valid root user ID. The diagram below shows the process.

When Joe runs the password program, Joe's shell program uses the fork () system call to create a similar copy of himself. The copy process still maintains the same user ID (Joe) and still runs the shell program. Then, after being created, the new process executes the EXECVE () system call to run the cryptographic program. At the same time, in standard Linux, the process is required to have executable permissions (x) for the program, which is correct in this example because anyone has executable permissions on the password file. There are two key things that can happen after a successful execution of the EXECVE () call. The first is that the shell program in the new process that is running will be replaced by the password program. Second, since Setuid is set as the file owner, the valid user ID is changed from the original ID of the process to the ID of the file owner (root in this case). Because Root has access to any file, the password program now has access to the shadow password file and is able to handle requests from Joe for a change of password.

The use of setuid bits is built on Unix-like operating systems and is a simple and powerful feature. However, he also explains the major flaws in standard Linux security. The password program needs to access the shadow file in the root user's way. Then, when running as the root user, the password program can also access any system resources. This also violates the core principle of safety engineering-least privilege. Therefore, we must trust that the password program does not take other possible actions on the system. For a real security application, a cryptographic program requires a lot of code reviews to make sure he doesn't abuse his privileges. Further, when an unexpected error occurs in a cryptographic program, he may be able to create a security vulnerability that far outweighs the loss caused by accessing the shadow password file. Although the password program is relatively simple and highly reliable, then consider other programs (including the login program) if the root user run, what will happen?

The way we really like it is to make sure that the password program and any other programs that must have permissions have the fewest permissions. Simply put, we want the password program to be able to access only the shadow files and some other password-related files as well as the minimum system resources necessary. At the same time I want to make sure that no other 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 a password program (or a similar program) to manage the user account role without having to consider our own other programs,

Let's talk about the domain conversion of TE security mechanism

2.2.4 Domain Conversion

As just 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 providing secure domain transitions and setuid programs is similar, but is carried out under the TE mechanism. To illustrate, we use the setuid example and add the TE.

Now our example is more complex. Let's take a detailed look at this figure. The first thing to notice is that we've added three types that were shown earlier, that is, Joe's Shell Domain (user_t), the password program's domain identifier (passwd_t), and the shadow password file identifier (shadow_t). In addition to this, we have added a file identifier (passwd_exec_t) for the passwd executable file. For example, the security context of a cryptographic program that is listed on disk will result in the following.

Now, oh, we have enough information to create the TE policy rule to allow the password program to run with passwd_t as the domain identity. Let's look at the rules of Fancy. First rule:

This rule allows Joe's Shell (user_t) to initialize a EXECVE () system call in the passwd executable (passwd_exec_t). The SELinux execute file permissions are essentially the same as the X access rights for standard Linux files. (The shell will count the files before attempting to run, so it also needs GetAttr permissions) to review the description of how the shell program works. First, he first fork a copy of himself, including the exact same security attributes. This copy still retains Joe's Shell's original domain identifier (user_t). Therefore, execute permissions must point to the original domain (that is, the domain identity of the shell). Is that why? user_t is the source identifier for this rule. (Source type)

Let's take a look at the second allow rule:

This rule provides access to the passwd_t domain's entry point (entrypoint). EntryPoint is a fairly valuable privilege in SELinux. What this permission does is define which executable file (and therefore, which program) may enter a domain. For a domain transition, the new or "to-be-entered" (the one that will be entered) (in this case, passwd_t) must have access to the executable entrypoint, which is used to transition to the new domain identity. In this example, assuming that only the passwd executable is flagged as passwd_exec_t, only the entrypoint permission that passwd_t has passwd_exec_t is identified, so that only password programs can run in Passwd_ The T domain ID. This is a very powerful security control.

Warning:
The concept of entrypoint permissions is very important. If you do not fully understand the above example, please read it again before continuing reading.

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

This is the first one we've seen that does not provide an allow rule for file object access. In this instance, the object class is the process, which is the class of objects representing the processes. Recall 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 identity of the security context for this privileged process has changed. The original identity (user_t) must have transition permission to be allowed to be converted to the new identity (passwd_t).

One of these three rules provides the necessary conditions for domain conversions to occur. To make a domain successful, all three of these conditions must be met. Therefore, a domain conversion is allowed when the following three conditions are met.

1: Process new domain identity has entrypoint permissions on the identity of the executable file
2: Process current (or past) domain identity has Execute permission on the entry point file identity
3: Process current domain identity has transition permissions on new domain identity

A domain conversion occurs when all of these three permissions are agreed in the TE policy. Further, for the use of entrypoint permissions in executable files, we have the ability to strictly control which program can run on a given domain identifier. Execvte () is the only way to change the domain identity when the system is called, allowing policy-makers to control access to the personal program, regardless of who is calling the program's user.

The question now is how Joe shows he wants to make a domain transition. The rules above only allow domain conversions, and they will not command him. There are ways in which a program designer or user can explicitly request domain conversions (if allowed). All Joe wanted to do was run the password file, and he wanted the system to make sure he was able to execute it. We need a way to enable the system to initialize a domain transition by default.

2.2.5 Default Domain conversion: type_transition statement

In order to support domain conversion by default (as in our cipher program example), we need to introduce a new rule, type Transtion rule (type_transtion). This regulation provides a way for the SELinux policy to specify a default conversion that should be attempted if an explicit conversion is not required. Let's add the following tyoe transition rule to the Allow rule:

The syntax of this rule is different from the Allow rule. He still has the source and target identifiers (user_t and passed_t), and there are also object classes (process). However, without permission, we have a third-party identity, the default identifier (passwd_t).

The type_transition rule is used for several different targets that are related to the default identity of the table. For now, we are concerned with the type_transitin of the process as his object class. Such a rule results in a default domain conversion to try. Type_transition shows that, by default, in a exece () system call, if the domain of a calling process is identified as user_t, and the identity of an executable file is passwd_exec_t (an example of the figure above), A domain transition to a new domain (passwd_t) will be attempted.

The type_transition rule allows a policy definition to initialize a domain transition by default when there is no explicit user input. This makes the TE mechanism not feel very compelling to the user. In our case, Joe doesn't want to know anything about access control and identity; he wants to change the password. System and policy definitions can use type_transition rules to perform these transformations for the user.

Attention:
Be sure to keep in mind that a type_transition rule will cause a default domain conversion attempt, but he will not allow him. In order to ensure the successful completion of the domain conversion, you still need to provide the three identities required for domain conversion, whether he is initialized by default or as a user-defined requirement.

Type enforcement (types mandatory access control)