What is SELinux?

In the new Rhel -based generally comes with SELinux, in most cases we disable selinux, in fact, since RHEL to integrate it, there must be his strengths and strengths, we use the following to understand SELinux, Maybe you'd like to use it.

Original English from www.RedHat.com
by Russell Coker
Translation: Hu Zhijiang
Main content
Introduced:
SELinux Overview:
SELinux in-depth research:
Implementation of policies in Fedora:
Default SELinux policy for Fedora:
For more information about SELinux:
About the author and translator:

Introduced:
In today's world, ubiquitous high-speed Internet connections, cafes with wireless access points and various hacking tools spread all over the web make it a cliché to consider computer security. To address security concerns, the NSA has developed an access control system with the help of the Linux community, where the process can access only those files that are needed in his tasks, under the constraints of the access control system. This system is called security-enhanced Linux or simplified to SELinux.

SELinux Overview:

SELinux is an enforced access control (MAC) security system based on the domain-type model (DOMAIN-TYPE), which is written by the NSA and designed into kernel modules that are included in the kernel, and some of the corresponding security-related applications have been hit by the SELinux patch, Finally, there is a corresponding security policy.

As we all know, the standard UNIX security model is an "arbitrary access control" DAC. This means that any program has full control over its resources. If a program intends to keep a file containing potentially important information in the/tmp directory, no one can stop him in the case of a DAC!

The security policy in the case of Mac completely controls access to all resources. This is the difference between Mac and DAC nature.

The Mac that is implemented in SELinux allows the program to create files in the/tmp directory, and it allows the file to be read worldwide as required by the UNIX permission Word, but when the UNIX license checks the application, the SELinux license check further determines whether access to the resource is permitted.
In other words, although the permissions of some UNIX files are set to 0777, you may still be prevented from reading, writing, and executing the UNIX file. In the case of a DAC only, the user can view or change any file that belongs to him. SELinux can limit the access to various resources for each process and the right level of access. This means that when a program uses sensitive data, the data is blocked from being written to files that are readable by low-weight processes.

SELinux provides better access control than traditional UNIX permissions.

For example, an administrator can allow only one application to add records to a log file but not allow it to overwrite or delete the contents of the log file. Although the ext2 and ext3 file systems have a append-only tag (using the Chattr setting), this property does not differentiate between a process (which is not allowed to be a single access append-only while allowing another process to have a fully writable right); An application can be allowed to create and write data to a folder, but cannot delete files: This feature is not available to the normal Linux kernel without selinux. Also, a network application can bind to the port it needs (such as the 53 port of BIND), but it cannot bind to other ports.

The domain-type model means that each process running in the security domain and each resource (generic, directory, socket, and so on) has a "type" associated with it.

On top of that, a series of rules are set up that lists all the actions that a domain can perform on each type. One advantage of the domain-type model is that we can analyze the strategy to determine what information is likely to spill over. In a standard UNIX environment, users can generally use the PS command to view each other's list of processes, but this also provides valuable information to the attacker. Even if the user is completely prevented from using the PS command, the information will be accidental or intentional disclosure, in fact, in a given UNIX environment, what information will leak is impossible to judge.

In the case of SELinux, we have many tools to analyze the SELinux strategy and determine what information leaks are possible. For example, if there are two applications that are allowed to add data to a log file, and they cannot communicate with each other directly. Then if one of the processes gets read access to the log, then a single-sided communication can be formed.

Access restrictions for accessing/etc/shadow files are a good example, and we can see the benefits of strategy analysis with this example.
If you install Fedora Core 3 and you select a strict selinux policy configuration, 17 domains will be allowed access to shadow_t (type/etc/shadow), with 9 domains with write rights. 2 of these 17 domains can be accessed from the user domain, which is/usr/bin/passwd and/sbin/unix_chkpwd, a helper program that provides password checking for unprivileged applications, such as the need to use the UNIX_ to lock screen programs CHKPWD). Some of these 17 domains are prepared for some uncommon applications (such as the radius_t domain is prepared for the RADIUS server), so that is, even if you remove this infrequently used domain, there are 16 accessible domains in the general system that can access/etc/shadow!

It is noteworthy that the SELinux version of the Fedora policy has become increasingly flexible, and future versions of the policy may make it possible to access more than 17 domains of/etc/shadow, depending on the actual configuration of the adjustable options. Also note that the 17 figure is based on strict policy settings, in fact, a default installation will be greater than this number.

On a machine without SE, any process running as root can access the/etc/shadow file. This means that any security issues that are generated by "SETUID root" binary code or a network service daemon running as root will be catastrophic.

SELinux allows us to restrict these daemons from accessing only what they need:
Bind can serve only on port 53, DHCP servers can use RAW sockets (raw network access), DHCP clients can use raw sockets and can change network interfaces, but none of them want to access/etc/shadow,/home,/ Root and so on these important resources.
So, in the case of SELinux, if bind is compromised, it is at best sending some bogus messages. If DHCPD is compromised, the worst possibility is that your IP address assignment is messed up. This is much better than the remote abuse of root power!

It is clear to all that a process can invoke another process.

In this case, take dhcpd as an example, dhcpd may try to invoke/sbin/unix_chkpwd to brute force attacks on the password. (But even this potential vulnerability is closed): SELinux can provide "transition" rules that can be used to determine whether transitions between domains are legitimate. With the "transition" rule, a screen saver executed by a user can smoothly transition to a privileged domain such as/sbin/unix_chkpwd, but DHCPD is not.

These limitations allow you to know the state of your system at your fingertips. If you find a bug in your DHCP server, simply upgrade the DHCP server to the new version and make sure that every client can get the IP address properly. But if you don't have SE, you have to consider whether your new server has been hacked and erased.

SElinux has strict isolation of the different domains. I used to run a Debian system for two years, during which time I opened his root password. I've been doing the same thing on a fedora system for the last two months. However, the two systems have resisted multiple root attacks (see httphttp://www.coker.com.au/selinux/play.html). (Translator Note: There are some authors who have ignored the introduction of their playmachine)

In order to do code testing for RHEL4, Fedora Core 2 has tried to integrate SELinux, but it is turned off by default. And there will be very big differences between rhel and Fedora Core SE in the future. We plan to set the SELinux policy to be stricter than Fedora core in Rhel, and we believe this is also in line with the user's requirements. The SELinux strategy for future versions of Fedora will be more stringent, but no more stringent than Rhel.

SELinux in-depth research:

The SELinux policy database controls all aspects of SELinux. It can determine which domain a program might run in, and also describe which resources a domain can access. Such rules are called rules, and a typical strategy often has 100,000 rules. Don't be frightened by this number, we don't have to care about it, because when we write a strategy, we can use advanced macros, and one line of these high-level macros can generate 10,000 rules. In addition to macros, there are tools that you can use to analyze whether these generated rules will meet your security requirements. In fact, and set the UNIX permission bit for each file, these 100,000 rules are quite a small amount of work.

The goal of Fedora Core 2 security policy is to meet the requirements of most users to work without changes, but there are some common simple options to adjust the policy, usually a simple one-line option. For example, whether the user is allowed to read the kernel log through DMESG, whether the administrator (Sysadm_r) is allowed to log in or log in directly via SSH, and whether the user is allowed to bind TCP sockets.
The 100,000 or so rules are stored in a file about 2.6MB, which is loaded with the kernel and consumes the same size (about 2.6MB) of kernel space when the system starts up. The default strict policy for Fedora Core 3 has 290,000 additional rules that take up 7MB of kernel space. The default target policy for Fedora Core 3 has about 5,000 rules, which takes up 150K of kernel space.

Currently, SELinux is not optimized for memory usage, but now there are plans and some ways to reduce memory usage for these optimizations. If you are not going to use some daemons, you can simply delete their corresponding policy files to get a less space-consuming strategy. In 2003, at a Linux symposium hosted by Ottawa, I submitted an article on my work on migrating selinux to the HP IPAQ PDA (HTTP//archive.linuxsymposium.org/ Ols2003/proceedings/can be obtained).

proves that I can make selinux (and choose the strict strategy) work well on a small platform with only a few MBS of RAM and a storage space of up to MBS, and I believe I can also make it run on smaller platforms. For the Fedora Core2 system, we only look at the most common hardware platforms available today, resulting in a default policy configuration. But users who use older machines may want to configure minimal policies to reduce memory usage and improve performance.

In a system that uses selinux, the context of each process contains three components: an ID, a role, and a domain

The ID refers to the owner of the process, which is the UNIX account, provided that the account must be pre-compiled into the SELinux policy to make SELinux aware of the account, otherwise SELinux will default to the unknown system process ID as System_u. The unknown user process ID is recorded as User_u, and the role is used to determine which domains an ID in this role can enter and also to prevent an ID that is in this role from entering another domain that should not be entered. For example, the User_r role is not allowed to enter sysadm_t (an important system admin domain).

In other words, a process that has only User_u ID can only play the role of User_r, and user_r this role can never be allowed to enter the sysadm_t domain. Thus, those who only user_u this ID do not want to enter the sysadm_t domain. These features are not fully used in the default Fedora Core2 strategy, and we are only spending our efforts on the development of the daemon, with little policy restrictions on the user domain (the targeted policy does not impose any restrictions on user login).

A security context can be succinctly expressed in such a way as a Identity:role:domain descriptor.

For example, a typical system management context can be represented as root:sysadm_r:sysadm_t. Any object that can be accessed can be represented in this way. It is important to note that "domain" is actually a "type" corresponding to a process. So when checking whether a process is authorized to send a signal to another process (for example, to review the/proc file system for a PS command), the "domain" of the process that receives the signal serves as the "type" role in the domain-type model, completing the rule check for domain-type. This completes the check of inter-process communication permissions. Because the file has not yet used the role of the mechanism, so currently each file is defined as the Object_r role (this role is only a position, the policy has no impact).

The ID of the file is the ID of the creator of the file. This method is used in the constraints policy source file to determine whether an access is authorized to change the context descriptor of a file. Unless the ID field in the descriptor of the file being accessed is the same as the Owner ID field of the process accessing the file, the process does not have permission to change the context descriptor of a file, either before or after the change.

For example, a process that has a rjc:user_r:user_t descriptor can change the descriptor of a file that has a rjc:object_r:user_games_rw_t descriptor to rjc:object_r:user_games_ro_t, However, it does not have permission to change any of the properties of a file that has a john:object_r:user_games_rw_t descriptor.

To view the context descriptor of the currently running process, you can use the PS command and add the "-z" option, such as example: "PS ax-z Output":
PID CONTEXT COMMAND
1634 Root:user_r:user_t-bash
1662 root:user_r:user_t PS ax-z

Example 1. Example Output of PS ax-z

To view the context descriptor of a file under a directory, you can use the LS command and add the "-z" option, such as example: "Ls-z output":
Drwxr-xr-x root root system_u:object_r:bin_t bin
Drwxr-xr-x root root system_u:object_r:boot_t boot
Drwxr-xr-x root root system_u:object_r:device_t dev
Drwxr-xr-x root root system_u:object_r:etc_t etc
Drwxr-xr-x Root root system_u:object_r:home_root_t Home
Drwxr-xr-x root root system_u:object_r:root_t initrd
Drwxr-xr-x Root root system_u:object_r:lib_t lib
drwx------root root system_u:object_r:lost_found_t lost+found
Drwxr-xr-x root root system_u:object_r:default_t Misc
Drwxr-xr-x root root system_u:object_r:mnt_t mnt
Drwxr-xr-x root root system_u:object_r:usr_t opt
?---------  ?                                         ? Oracle
Dr-xr-xr-x root root proc
Drwxr-x---root root system_u:object_r:user_home_dir_t root
Drwxr-xr-x root root system_u:object_r:sbin_t sbin
Drwxr-xr-x root root SELinux
Drwxr-xr-x root root system_u:object_r:default_t srv
Drwxr-xr-x root root sys
DRWXRWXRWT root root system_u:object_r:tmp_t tmp
Drwxr-xr-x root root system_u:object_r:usr_t usr
Drwxr-xr-x root root system_u:object_r:var_t var

Example 2. Example Output of Ls-z

It is important to note that the LS command does not display its context for files that do not have the specified contexts (typically those file systems that do not support rwx tags, such as/sys,/proc,/selinux). For those file systems that cannot view the current state with the stat command. The LS command returns "?---------", and its owner and all groups are also marked as "? "And, likewise, his context will not show.
As shown in example three, the ID command returns the context of the current shell
Uid=0 (Root) gid=0 (root) groups=0 (root), 1 (BIN), 2 (daemon), 3 (SYS), 4 (ADM), 6 (disk), ten (wheel) context=root:user_r:user_ T
Example 3. Example Output of the ID Command

If your SELinux system uses the strict strategy, you will find that it is very easy for the application to do something that is not normal. You will often find bugs in some programs that make the program do other things that your selinux policy does not allow.
SELinux requires that the context of the process be changed only at the "moment" of execution. The domain and role information for the new process can be obtained automatically from the context and file type of the EXEC system function. The process can also be specified in context before exec executes. These processes are naturally controlled by SELinux policies because the IDs, roles, and domains are controlled by SELinux policies.

Implementation of policies in Fedora:

Starting with Fedora Core 3, selinux policy data is stored in the/etc/security/selinux/x/src/policy/directory (X refers to the strategy you choose, either "strict" or "targeted"). In this directory, you can use "make load" to compile and install the policy. That is, using that command to compile the policy into binary format and install it into the kernel and take effect immediately. In addition to being installed as a kernel, the command also stores the binary format of the policy to/etc/selinux/x/policy/policy. YY file, here X refers to your choice of strategy, can be "strict" or "targeted", YY is the version number of the policy (Fedora Core 3 Support the latest version is 18). This is to allow Init to quickly load the policy to the kernel at the first time the system is powered on. /etc/selinux/config This configuration file is used to tell Init that those policies need to be loaded.

When you start a selinux, the first thing that Init does is mount the/proc file system and determine if SELinux is activated. Init uses the Selinuxfs file system type to determine if there is selinux in the kernel, and if the kernel does not have selinux or selinux=0 in the kernel parameters, then the system will continue booting with a state called Non-se. If SELinux is found, then the/selinux virtual file system is created, and init checks the SELinux version supported by the kernel through/selinux/policyvers. Finally, the corresponding policy data is/etc/selinux/x/policy/policy. YY will be loaded into the kernel.

When the policy is loaded, all running processes (that is, all the threads of Init and the kernel) will be specified system_u:system_r:kernel_t such a context (the kernel thread is actually created at any time and its context is System_u: system_r:kernel_t). When Init finishes loading the policy, it also needs to re-execute itself. There is a rule in the strategy called Domain_auto_trans (kernel_t, init_exec_t, init_t). What he means is that when the kernel_t domain executes an executable file of the init_exec_t type (such as/sbin/init), the domain of the process that the executable file corresponds to automatically transitions to the init_t domain (this is the correct domain for/sbin/init). When this is done, Init continues to perform the usual tasks to complete the machine's startup. Kernel threads run from kernel_t to the beginning of the same type.

The context of the file and directory is stored in the extended attribute (xattrs). For more information on Xattrs, please refer to the manpage of attr (5), getfattr (1) and setfattr (1).

Simply put, a xattr is the ownership of a file on a hard disk, and it consists of the file name and some other information. For each persistent file system, the SELinux context of each of its files or directories is stored in the Security.selinux attribute. Although the/proc file system is not a persistent file system, SELinux still makes contextual markup for its files and directories behind the scenes, but cannot be obtained with getxattr. In contrast, the context of each file (each pseudo-terminal) in the Devpts file system (applied to the/dev/pts Unix98 pseudo terminal) is available through getxattr and can be obtained by setxattr To change the context of each device (so that similar programs like sshd can change the context of a TTY device). For those file systems with fixed storage (ext2, ext3, Reiserfs, XFS, VFAT, etc.) there are two options for setting the file context:
The first is that the type of file system specifies the context in which each file within it is unified;
The second type: Use Xattrs to mark a different context for each file. For example, the context of each file in the iso9660 (CD-ROM) file system is system_u:object_r:iso9660_t, which is called Genfs tag.

Ext2, ext3 and XFS support Xattrs and the Fedora system also supports the secure tag namespace, so Fedora uses Xattrs to mark the context of the file by default, but this is also one of the options. Because Hans Reiser did not have much interest in supporting Xattr until Reiser4 was released, the ReiserFS file system in Fedora does not support selinux tag operations well. In other words, it is impossible to use the ReiserFS file system as the SELinux root filesystem.

XFS has an important problem related to Xattrs: If Xattrs cannot be loaded into the Super Block (inode), then they will be loaded into the data block, each super block will use a block of data to install the SELinux xattr. When creating XFS, Mkfs.xfs creates a block size of 4096 by default, with a super block size of 256 (approximately 30 bytes if used to install SELinux xattr). This means that the default XFS file system, each super block to occupy 4096 bytes to load the SELinux xattr, which is a serious waste of disk space! When you create an XFS file system using the "-I size=512" option, the Super block size becomes 512 bytes, which allows the SELinux xattr to be loaded into the Super block, which saves space and improves performance. A 512-byte super block can also benefit other operations. So, if you use XFS and plan to use SELinux in the future, it's a good idea to set the size of the Super block to 512 bytes.

If you are using a newer kernel (such as the latest Fedora kernel or the standard 2.6.8.1 kernel) and use the latest Mount tool, there is an option to specify context tags for the entire file system when you mount a file system. For example, the file system you want to mount is a mail pool (mail spool), and you can use the "-O context=system_u:object_r:mail_spool_t" option to mount him, which marks the context of all the files inside it as System_u : object_r:mail_spool_t. If you have a large email pool and an XFS file system, this approach avoids the problem of the inode size discussed in the previous paragraph. Even for xattrs-less overhead file systems such as EXT3, mounting the file system with the context= option can further reduce overhead, and avoid re-setting the SELinux context for the established file system (if the file system has more files will be wasted for a long time).

Default SELinux policy for Fedora:

In the Fedora Core 3 system, the default policy is the "targeted" policy. The problem with this choice of people is that we want to make as many people as possible use SELinux. People would turn it off if they thought it was too scary and hindered people from doing what they wanted to do. So at this point we would rather provide a moderate amount of protection for most people, and will not provide a strict protection strategy for a few people. The default Fedora Core 3 installation activates SELinux and uses the "targeted" policy, and you can also change the policy to a more restrictive "strict" policy by running the System-config-securitylevel program.

If you install the source package of the policy, then the source file of the policy is in the/etc/selinux/x/src/policy/directory (X refers to the strategy you choose, can be "strict" or "targeted") in this directory there is a called domains/ program/subdirectory, which corresponds to a. te file for each daemon. You can delete the. te files that correspond to daemons that you do not use and do not intend to use, thereby reducing the use of kernel memory space and improving performance. For example, if your system does not have a bind service, you can delete the Named.te file completely. Then, if you reload the policy to the kernel using the make load command, the kernel will use less memory. Be careful, however, that if you delete other files by mistake, your system will not boot into enforcing mode properly. So at the moment, this adjustment is best done by an expert.

When you start contacting SELinux, be aware of a kernel parameter that is used to determine whether your system's kernel is running in force (enforcing) or free (permissive) mode, which is the "enforcing" parameter. In free mode, SELinux just records what he should do, and in fact doesn't do any action. In mandatory mode, SELinux will come to the bottom. If your policy has errors, the system may prevent you from logging in force mode! So normally you should transfer enforcing=1 to the kernel at startup, and when you have problems with your selinux policy, you can temporarily pass enforcing=0 to the kernel to check for errors. In/etc/selinux/config This init configuration file has an option, by setting it, you can also put the system into free mode.

If you plan to discontinue using SELinux, you can use the selinux=0 kernel parameter. This turns off the full functionality of SELinux, as if your kernel did not compile the selinux mechanism. So when the system is out of the question, like the system crashes, some people use this method to restore the directors, but I don't agree with this approach. When you use Selinux=0 to enter the system temporarily, any files you create will not have the SELinux context tag. This means that if you replace important files such as/etc/passwd or/etc/shadow, the next time you enter SELinux, the system will not work properly. This is not a serious problem, and the same problem occurs when you boot from a CD, when you do a system restore, or when you use a recovery system that does not support xattrs backup software. Although this problem can be resolved by re-labeling the affected file system, is it better to use enforcing=0 instead of selinux=0?
You can edit/etc/selinux/config to temporarily close SELinux.

The release of Fedora Core 2 is an important development for SELinux. He was the first major Linux distribution to provide full support for SELinux. Fedora Core 3 is also an important milestone because he is the first Linux distribution to use SELinux as the default installation option.
Red Hat Enterprise Linux 4 will follow the pace of Fedora Core development, and its support for SELinux will be further developed. When RHEL 4 is released, she will benefit greatly from the Fedora Core system and the users learning SELinux on fedora.

You can find support for SELinux on the #fedora-selinux channel on the irc.freenode.net IRC server. There are also Fedora SELinux mailing list http://www.redhat.com/mailman/listinfo/fedora-selinux-list. I often hang on top of #fedora-selinux and subscribe to the mailing list, and I look forward to answering any questions you may have.

For more information about SELinux:

NSA site for security-enhanced Linux:http://www.nsa.gov/selinux/
Fedora Core SELinux FAQ:http://people.redhat.com/kwade/fedora-docs/selinux-faq/
IRC channel for SELinux in Fedora Core:irc.freenode.net, #fedora-selinux
Mailing list for SELinux in Fedora Core:http://www.redhat.com/mailman/listinfo/fedora-selinux-list
SELinux Play machine:http://www.coker.com.au/selinux/play.html

About the author and translator:

Russell Coker has been working on the SELinux project for Redhat since 2003. Prior to that he was an independent consultant and studied SELinux in his spare time. He first learned about SELinux at the 2001 Ottawa Linux Symposium, when the NSA's Pete Loscocco made a speech about SELinux. At OLS 2002 he described how he migrated selinux to Debian Linux. As part of the porting effort, he also wrote strategies to support all of the programs he used, which later became the main source of the SELinux strategy. He also published articles on OLS2003 and Linux Kongress 2002.

Translator: Hu Zhijiang, enrolled in the Department of Communication Engineering, Jiangsu University. The RHCT certification has been adopted since 1999 with the linux,2003 year. are interested in Linux systems and embedded systems. The main purpose of this article is to study SELinux, and then share the results with you. I hope you will criticize and correct the mistakes made by the translation.

Source: http://blog.csdn.net/flaght/article/details/2973910

What is SELinux?