Shulou(Shulou.com)06/02 Report--

Foreword:

SELinux is a very esoteric thing. I have asked many operation and maintenance technicians around me whether the SElinux of their company's servers is open or closed in the production environment, and get a unified answer-directly shut down, without exception.

There is also a saying on the Internet-a senior operation and maintenance engineer, the SELinux of his system must be turned off.

So, if you want to know about SELinux, you can learn about it, in case your company requires you to open SELinux in the future, but you don't understand it, then it's embarrassing, and it doesn't matter if you don't know it, because it's not so easy to meet a company that forces you to open SELinux.

With all that said above, what is SELinux? This article will talk about some concepts and setup methods of SELinux.

Text:

SELinux is the meaning of security enhanced linux. We all know that in Linux, whether a file can be read by the current user is determined by the user's permissions on the file. The well-known general permissions are read, write and execute, and some special permissions have the special rights seen by lsattr commands, or SUID, SGID, SBIT and other special rights. These permissions are basically controlled for users. SELinux is similar to these permissions, but it is not the same as these permissions. The permissions mentioned above are controlled by the user, while SELinux is controlled by a certain process, so how does the system execute when the user reads a file? Here is a picture of Brother Bird's private dishes. Let's take a look at it.

The focus of the above figure is how the program gets access to the target's resources! As can be seen from the above figure, if a program wants to read a file, it must first pass the rules in the SELinux policy, and then compare the security text. If the comparison fails, it will not be able to carry out further verification (verifying the permissions set for the user). The policy and security text here are all provided by SELinux. To sum up, if the user wants to read a file, the reading process must be detected by SELinux (of course). SELinux must be on) before it is qualified to verify permissions for users. If SELinux is off, there is no doubt that directly verifying the permissions of users can determine whether the file can be read.

Conclusion: when a user reads a file, the process must be verified by SELinux before verifying the user's permissions.

With regard to the policy and security text mentioned above, I don't quite understand it, which is too esoteric (this is what a friend of mine who works abroad told me. I admire a person who graduated for two years with an annual salary of 30W.

We don't do something so esoteric (mainly because I don't understand it either), let's do something simple.

1. How to check the permission control of a file by SELinux? [root@node1 ~] # ls-Z # this is the option to view SELinux-related permissions-rw-. The last column of root root 'system_u':'object_r':'admin_home_t':s0 anaconda-ks.cfg# is the file name-rw-r--r-- root root? Cpu.cfs_quota_us~-rw-r--r--. Root root system_u:object_r:admin_home_t:s0 initial-setup-ks.cfg# has some special font colors on it, which is the special permission of SELinux.

When I first saw these things, I thought to myself, "Oh, my God, what the hell is this?" Ha ha!

Don't panic, it's not a big problem. The purpose of my article is to simplify complex problems. What you need to know is the meaning of the three fields of "'system_u':'object_r':'admin_home_t'" in each file, but you don't need to know all of them. You just need to know the meaning of "_ u, _ r" at the end of each paragraph and what the main paragraph "_ t" is. The first two paragraphs "_ u, _ r" can be ignored selectively.

The relevant explanations are as follows:

_ u (user): equivalent to account identification!

_ r (role): through the role field, we can know whether this data belongs to a process, a file resource, or represents a user. General roles are: object_r: represents file resources such as files or directories, which should be the most common; system_r: represents the process! However, the average user will also be designated as system_r.

_ t (type): this is the most important, the first two "user" and "role" are basically not important, the important thing is this type (type) field! Basically, whether a subject process can read this file resource or not is related to this field.

The above is the file permission control of SELinux, and SELinux is also aimed at the process for permission control, so how to check the corresponding SELinux permissions of the process? Please look at the following:

[root@localhost ~] # ps-eZ # execute the command View the SELinux permissions corresponding to the process LABEL PID TTY TIME CMDsystem_u:system_r:init_t:s0 1? 00:00:01 systemdsystem_u:system_r:kernel_t:s0 2? 00:00:00 kthreaddsystem_u:system_r:kernel_t:s0 3? 00:00:00 ksoftirqd/0system_u : system_r:kernel_t:s0 4? 00:00:00 kworker/0:0system_u:system_r:kernel_t:s0 5? 00:00:00 kworker/0:0Hsystem_u:system_r:kernel_t:s0 6? 00:00:00 kworker/u256:0system_u:system_r:kernel_t:s0 7? 00:00:00 migration/0 . # omit part of the content # of course SELinux must be on before you can view this information. If SELinux is turned off, it cannot be found.

I've been talking about turning SELinux on and off, so how to do it? Please keep watching.

The relevant commands are as follows:

[root@localhost ~] # getenforce # View current SELinux status Enforcing [root@localhost ~] # setenforce 0 # set the status to tolerance mode [root@localhost ~] # getenforce # and then continue to see if you have successfully changed Permissive [root@localhost ~] # setenforce 1 # to mandatory status [root@localhost ~] # getenforce # View Enforcing again

There are three modes of SELinux: Enforcing, Permissive, and disabled. The explanations for these three models are as follows:

Enforcing: mandatory mode, the SELinux in this state mode is normal, can play a good role in controlling the reading of the program; Permissive: tolerant mode, the SELinux in this state is also running, but there is no restriction on the reading of the program, just record logs and other related information. Disabled: if you want to change this mode, you need to modify the configuration file and restart the server.

If you use the command, you can only temporarily change the SELinux to mandatory mode or tolerant mode, not to disable mode, and it is an one-time modification. If you restart, it will read the mode in the configuration file and continue to run.

The configuration file for SELinux is described as follows:

[root@node1 ~] # vim / etc/selinux/config # This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# the following are three working modes of SELinux: enforcing, permissive, Disabled# enforcing-SELinux security policy is enforced.# permissive-SELinux prints warnings instead of enforcing.# disabled-No SELinux policy is loaded.SELINUX=enforcing # here is to modify the operation mode of SELinux # SELINUXTYPE= can take one of three two values:# the following are three policies of SELinux Targeted, minimum, mls# targeted-Targeted processes are protected,# minimum-Modification of targeted policy. Only selected processes are protected. # mls-Multi Level Security protection.SELINUXTYPE=targeted # here are three policies for modifying SELinux # generally, you can modify the working mode of SELinux, not to mention its three policies.

The above is the default policy and startup mode! You should note that if the policy is changed, it needs to be restarted; if enforcing or permissive is changed to disabled, or disabled to the other two, it must also be restarted. This is because SELinux is integrated into the core, you can only switch to enforcing or permissive mode under SELinux operation, and you can't turn off SELinux directly! If you just found disabled in getenforce, please go to the above file and change it to enforcing and restart it. The restart process will be slow, and it is very likely that the restart will not start. I did not find a solution that cannot be restarted. I will solve it myself.

Let's do two little experiments.

Server node1 and client, node1 has web service and FTP service on it. Then the client accesses (note that SELinux is on at this time):

[root@node1 ~] # yum-y install httpd # install web service [root@node1 ~] # yum-y install vsftpd* # install FTP service [root@node1 ~] # systemctl start httpd # start web service [root@node1 ~] # systemctl start vsftpd # start FTP service [root@node1 ~] # echo "test web `date +% F`" > / var/www/html/test.html # do a test Try the web page [root@node1 ~] # ll-Z / var/www/html/test.html # to view the type-rw-r--r--. of this page Root root unconfined_u:object_r:'httpd_sys_content_t':s0 / var/www/html/test.html# can see that it belongs to the httpd process [root@node1 ~] # echo-e "ftptest\ n`date +% F`" > / var/ftp/pub/test.txt # make a file and put it in the ftp directory [root@node1 ~] # ll-R-Z / var/ftp/ # View the files in the FTP root directory Type type / var/ftp/:drwxr-xr-x. Root root system_u:object_r:public_content_t:s0 pub/var/ftp/pub:-rw-r--r--. Root root unconfined_u:object_r:public_content_t:s0 test.txt [root@node1 ~] # getenforce # confirm that the current SELinux status is on Enforcing# to avoid interference from the firewall, turn off the firewalld firewall here (firewall is not what this blog is about)

The client accesses node1's web service and FTP service:

Access node1's web service:

Access node1's FTP service:

1. Test the web web page

Now change the web file of the web service to see if client can still access:

[root@node1 ~] # chcon-t admin_home_t / var/www/html/test.html # change type to "admin_home_t" [root@node1 ~] # ll-Z / var/www/html/test.html # check whether the change is successful-rw-r--r--. Root root unconfined_u:object_r:admin_home_t:s0 / var/www/html/test.html#OK, no problem, the type field has been changed successfully

Client accesses the test again:

Then there are two ways to change the type back. One is to use the command chcon to manually modify it again. How to change it just now, and how to change it back now. The command is as follows:

[root@node1 ~] # chcon-t httpd_sys_content_t / var/www/html/test.html # change the type so that users can access it normally.

The above chcon command can be changed back, but it is troublesome and is not recommended. Let's talk about the restorecon command here.

The restorecon command restores the file to the correct SELinux type (restore the default type).

[root@node1] # ll-Z / var/www/html/test.html # confirm that the type is still the one you randomly changed-rw-r--r--. Root root unconfined_u:object_r:admin_home_t:s0 / var/www/html/test.html [root@node1 ~] # restorecon-R / var/www/html/ # uses this command, and the web page file is not specified here # because I want to say "- R" this option, which means recursive modification means [root@node1] # ll-Z / var/www/html/test.html # check whether it is successful or not-rw-r--r--. Root root unconfined_u:object_r:httpd_sys_content_t:s0 / var/www/html/test.html#OK, no problem, became its original type field.

Client should be able to access it again, right? Let's take a look:

OK, no problem. This is the end of the testing of web web page files!

2. Test the FTP service

1. Modify the root directory of the FTP service

[root@node1 ~] # mkdir / test # create a test directory [root@node1 ~] # usermod-d / test ftp # modify the / test directory to the default root directory of the FTP service # because the default root directory is its host directory, change its host directory directly, in the production environment It is also recommended to change the configuration file of the FTP service [root@node1 ~] # echo-e "Are you ok?\ n `date +% F`" > / test/aaa.txt # to write a test file [root@node1 ~] # ll-Z / test/aaa.txt # to view the default type of the file-rw-r--r--. Root root unconfined_u:object_r:default_t:s0 / test/aaa.txt# since this file has nothing to do with the FTP service process, its type is the same as the type of / var/ftp/pub/test.txt when it was first installed [root@node1 ~] # systemctl restart vsftpd # restart the FTP service for the changes to take effect

2. Client access test:

Of course, at this point, you can also use the chcon command to manually change the type of the file to the same type as / var/ftp/pub/test.txt, but you cannot use the restorecon command, because the restorecon command usually restores the file to its original type, and the file's current type is the initial type! Therefore, we need to think of other ways.

Method 1: use the setsebool command to modify its Boolean value:

[root@node1 ~] # getsebool-a | grep ftpd # View ftp-related process control ftpd_anon_write-- > off # off means to disable ftpd_connect_all_unreserved-- > offftpd_connect_db-- > offftpd_full_access-- > offftpd_use_cifs-- > offftpd_use_fusefs-- > offftpd_use_nfs-- > offftpd_use_passive_mode-- > off [root@node1 ~] # setsebool-P ftpd_full_ Access 1 # uses the setsebool command to modify its access to related Boolean values 1 means on (on) and 0 means off (off). [root@node1 ~] # getsebool-a | grep ftpd # check ftpd_anon_write again-- > offftpd_connect_all_unreserved-- > offftpd_connect_db-- > offftpd_full_access-- > on # just opened this access-related process to ftpd_use_cifs-- > offftpd_use_fusefs-- > offftpd_use_nfs-- > offftpd_use_passive_mode-- > off [root@node1] # Getenforce # confirm that SELinux is now on Enforcing

Client visits again:

OK, no problem. Got access.

Method 2: use the setroubleshoot tool

Redhat has released a very good tool for SELinux-setroubleshoot (can write the error message of SELinux to / var/log/messages and give a solution)

(1) confirm that the setroubleshoot tool is installed

[root@node1 ~] # rpm-qa | grep setroubleshoot # query whether the command is installed [root@node1 ~] # yum-y install setroubleshoot # if not installed, use this command to install [root@node1 ~] # tailf / var/log/messages # dynamic refresh to view log messages

Client access:

(2) when client access fails, the log message monitored by the server will display the following prompt:

(3) Let's run the command it prompts:

[root@node1] # sealert-l 1e24155c-7602-4c51-8eb6-93ec8f77600f # the message under SELinux is preventing vsftpd from read access on the directory test.# (57.6 confidence) in the execution log means what is the probability of the information provided in this paragraph to solve the problem? generally, the higher the probability, the higher the probability. So generally look at the first on the line * Plugin catchall_boolean (57.6 confidence) suggests * If to allow ftpd to full accessThen must be enabled 'ftpd_full_access' Boolean value to inform SELinux of this situation. You can read the 'None' manual page for more details. Do # Do says to run the following command to solve the problem setsebool-P ftpd_full_access 1 # that's the command, I'll go. As if it were the same as our first method. * Plugin catchall_labels (36.2 confidence) suggests * # this paragraph indicates that there is only a 36.2% chance of solving the problem. The lower the rate, the smaller the If you want to allow vsftpd to have read access on the test directoryThen must change the tag Do# semanage fcontext-a-t FILE_TYPE 'test' in test, where FILE_TYPE is one of the following: admin_home_t, bin_t, boot_t, cache_home_t, cert_t, config_home_t, data_home_t, dbusd_etc_t, device_t, devpts_t, etc_runtime_t, etc_t, faillog_t, file_context_t Fonts_cache_t, fonts_t, ftpd_tmp_t, ftpd_tmpfs_t, ftpd_var_run_t, gconf_home_t, gnome_home_t, httpd_user_content_t, httpd_user_script_exec_t, krb5_conf_t, krb5_host_rcache_t, lib_t, locale_t, man_cache_t, man_t, mozilla_plugin_rw_t, net_conf_t, nscd_var_run_t, proc_t, public_content_rw_t, public_content_t Root_t, samba_etc_t, security_t, shell_exec_t, slapd_cert_t, src_t, sssd_public_t, sysfs_t, system_conf_t, system_db_t, systemd_logind_sessions_t, telepathy_cache_home_t, telepathy_data_home_t, textrel_shlib_t, tmp_t, tmpfs_t, udev_var_run_t, user_fonts_t, user_home_dir_t, user_home_t, user_tmp_t, usr_t Var_auth_t, var_lib_t, var_lock_t, var_log_t, var_run_t, virt_home_t, xferlog_t . Then execute: restorecon-v 'test' # this probability is only 36.2% of the prompt, let's run this command # and you know why the probability is so small? Because this command is to let us restore test to the default type, it will certainly not succeed, its default type has not been changed #. Omit part of the content # in fact, these prompts are recorded in the / var/log/messages log, but this display looks intuitive to a lot of [root@node1 ~] # setsebool-P ftpd_full_access 1 # so execute the following command with a 57.6% chance

There is no doubt that its ftp service can be accessed normally:

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.