Linux系統上的SELinux究竟是個什么？

前言：

SELinux是一個很深奧的東西，我問過身邊好多運維技術人員，他們公司服務器的SElinux在生產環境中是開啟狀態還是關閉狀態，得到一個統一的答案——直接關閉，無一例外。

網上也有一句話——一個資深的運維工程師，他系統的SELinux一定是關閉的。

所以說，想了解SELinux的，可以了解一下，為了以防以后自己所在的公司要求必須開啟SELinux，但自己又不懂，那就尷尬了，不了解也無所謂，因為遇到強制開啟SELinux的公司，也不是那么容易的事情。

上面說了那么一大堆，那么什么是SELinux呢？這篇文章就要聊一聊SELinux的一些概念及設置方法。

正文：

SELinux它是安全強化的linux含義，我們都知道在Linux中，一個文件能不能被當前用戶所讀取到，是由該用戶對這個文件所具有的權限來決定的，熟知的一般權限有讀、寫、執行，特殊的一點的權限又有lsattr命令查看到的特殊權限，又或者是SUID、SGID、SBIT等特殊權限，這些權限基本都是針對用戶來進行控制的，而SELinux類似這些權限，但又不是和這些權限一個種類的，前面說到的權限是針對用戶進行權限控制的，而SELinux是針對某個進程進行控制的，那么，當用戶對一個文件進行讀取操作時，系統是如何執行的呢？下面附上鳥哥的私房菜中的一張圖片一起來看一下：

上圖的重點在于程序如何取得目標的資源訪問權限！由上圖可以看出來，程序想要讀取一個文件，必須要先通過SELinux政策內的規則，然后再進行安全性文本的對比，若對比失敗則無法進行下一步驗證（驗證針對用戶設置的權限），這里的政策、安全性文本都是由SELinux來提供的，總結來說，用戶要讀取一個文件，該讀取進程必須要通過SELinux的檢測（當然，SELinux要在開啟狀態下），然后才有資格針對用戶去進行權限驗證，若SELinux是關閉狀態，毫無疑問咯，直接驗證用戶的權限即可決定是否可以讀取到該文件。

結論：用戶讀取一個文件，必須該進程先通過SELinux驗證，然后才是對用戶的權限進行驗證。

關于上面提到的政策及安全性文本，我也沒搞的太明白，里面的東西過于深奧（這是我一個在國外工作的朋友對我說的，畢業兩年，年薪30W+，我挺佩服的一個人）。

我們不搞那么深奧的東西（主要是我也沒怎么搞懂），我們就來一些簡單的。

1、如何查看SELinux對一個文件的權限控制？

[root@node1 ~]# ls -Z       #這就是查看SELinux相關權限的選項
-rw-------. root root 'system_u':'object_r':'admin_home_t':s0 anaconda-ks.cfg
#最后一列是文件名
-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
#在上面字體顏色有些特殊的便是SELinux的特殊權限

我剛看到這些東西的時候，內心的想法就是：我的天哪，這是什么鬼東西！哈哈！！！

不要慌，問題不大，我這篇文章存在的意義就是將復雜的問題簡單化，你需要了解的是“ 'system_u':'object_r':'admin_home_t'”每個文件的三個字段的意思，但也不需要全部了解，你只需要知道每一段后面“_u、_r”的含義，以及最主要的一段“_t”這段是什么就行了，前面兩段““_u、_r”選擇性忽略就行了。

相關解釋如下：
_u（user）：相當于賬號方面的身份識別！
_r（role）：通過角色字段，我們可以知道這個資料是屬于進程、文件資源還是代表使用者。一般的角色有：object_r：代表的是文件或目錄等文件資源，這應該是最常見的；system_r：代表的就是進程啦！不過，一般使用者也會被指定成為 system_r。
_t（type）：這個最重要，前面兩個“user”和“role”基本不重要，重要的是在于這個類型（type）字段！基本上一個主體進程能不能讀取到這個文件資源，就與這個字段有關。

上述是SELinux對文件的權限控制，SELinux也是針對于進程來進行權限控制的，那么，如何查看進程所對應的SELinux權限呢？請看下面：

[root@localhost ~]# ps -eZ             #執行該命令，查看進程所對應的SELinux權限
LABEL                              PID TTY          TIME CMD
system_u:system_r:init_t:s0          1 ?        00:00:01 systemd
system_u:system_r:kernel_t:s0        2 ?        00:00:00 kthreadd
system_u:system_r:kernel_t:s0        3 ?        00:00:00 ksoftirqd/0
system_u:system_r:kernel_t:s0        4 ?        00:00:00 kworker/0:0
system_u:system_r:kernel_t:s0        5 ?        00:00:00 kworker/0:0H
system_u:system_r:kernel_t:s0        6 ?        00:00:00 kworker/u256:0
system_u:system_r:kernel_t:s0        7 ?        00:00:00 migration/0
                   ...............#省略部分內容
#當然了，SELinux必須是開啟狀態下，才可查看這些信息，如果SELinux關閉，是查不到的。

前面一直在說開啟、關閉SELinux，那么怎么操作呢？請繼續看下去。

相關命令如下：

[root@localhost ~]# getenforce               #查看當前SELinux狀態
Enforcing
[root@localhost ~]# setenforce 0            #將狀態設置為寬容模式
[root@localhost ~]# getenforce                #再繼續查看是否更改成功
Permissive
[root@localhost ~]# setenforce 1              #再次改為強制狀態
[root@localhost ~]# getenforce                 #再次查看
Enforcing

SELinux共有三種模式：Enforcing、Permissive、disabled。關于這三種模式的解釋如下：

• Enforcing：強制模式，處于該狀態模式下的SELinux是正常運行的，可以對程序的讀取起到很好的控制作用；
• Permissive：寬容模式，處于該狀態下的SELinux也是正在運行的，只是對于程序的讀取不進行限制，只是記錄下日志等相關信息。
• disabled：禁用模式，就是直接關閉了，如果想要改為此種模式，需要修改配置文件，并重新啟動服務器。

使用命令的話，只可以將SELinux暫時性的改為強制模式或寬容模式，不能修改為禁用模式，并且是一次性修改的，如果重啟的話，它將會讀取到配置文件中的模式繼續運行。

SELinux的配置文件介紹如下：

[root@node1 ~]# vim /etc/selinux/config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#以下是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                        #這里是修改SELinux的運行模式
# SELINUXTYPE= can take one of three two values:
#以下是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           #這里是修改SELinux的三種政策
#一般是修改SELinux的工作模式即可，這里不談它的三種政策

上面是默認的政策與啟動的模式！你要注意的是，如果改變了政策則需要重新啟動；如果由 enforcing或 permissive 改成 disabled ，或由 disabled 改成其他兩個，那也必須要重新啟動。這是因為 SELinux是整合到核心里面去的， 你只可以在 SELinux 運作下切換成為強制 (enforcing) 或寬容 (permissive)模式，不能夠直接關閉 SELinux 的！ 如果剛剛你發現getenforce 出現 disabled 時，請到上述文件修改成為 enforcing 然后重新啟動吧！（重啟的過程會很慢，并且很有可能重啟不起來，我沒有去找無法重啟的解決辦法，自行解決吧）。

來兩個小小的實驗吧！

服務器node1和客戶端，node1上面有web服務和FTP服務。然后客戶端訪問（ 注意，此時SELinux是開啟狀態）：

[root@node1 ~]# yum -y install httpd           #安裝web服務
[root@node1 ~]# yum -y install vsftpd*        #安裝FTP服務
[root@node1 ~]# systemctl start httpd          #啟動web服務
[root@node1 ~]# systemctl start vsftpd        #啟動FTP服務
[root@node1 ~]# echo "test web `date +%F`" > /var/www/html/test.html   #做一個測試網頁
[root@node1 ~]# ll -Z /var/www/html/test.html    #查看該網頁的type
-rw-r--r--. root root unconfined_u:object_r:'httpd_sys_content_t':s0 /var/www/html/test.html
#可以看到是屬于httpd進程的
[root@node1 ~]# echo -e "ftptest \n`date +%F`" > /var/ftp/pub/test.txt   #做一個文件放到ftp目錄下
[root@node1 ~]# ll -R -Z /var/ftp/               #查看FTP根目錄下文件的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            #確認當前SELinux狀態是開啟狀態
Enforcing
#為了避免防火墻的干擾，這里關閉firewalld防火墻（防火墻不是這個博文要說的）

客戶端訪問node1的web服務和FTP服務：

訪問node1的web服務：

訪問node1的FTP服務：

1、對web網頁進行測試

現在改一下web服務的網頁文件，看看client是否還能訪問的到：

[root@node1 ~]# chcon -t admin_home_t /var/www/html/test.html    #更改類型為“admin_home_t”
[root@node1 ~]# ll -Z /var/www/html/test.html      #查看是否更改成功
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 /var/www/html/test.html
#OK，沒問題，類型字段已經更改成功了

client再次訪問測試：

那么將類型改回來，有兩種方法，一種是使用命令chcon手動再次修改，剛才怎么改的，現在就怎么改回來，命令如下：

[root@node1 ~]# chcon -t httpd_sys_content_t /var/www/html/test.html     #更改類型，使用戶可以正常訪問

上面chcon命令可以改回來，但是比較麻煩，不建議使用，這里說一下restorecon這個命令

restorecon 命令可以讓文件恢復正確的 SELinux type（恢復默認類型）。

[root@node1 ~]# ll -Z /var/www/html/test.html    #確認類型還是自己隨便改的那個
-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/  #使用該命令，這里并沒有指定那個網頁文件
#是因為我想說“-R”這個選項，就是遞歸修改的意思
[root@node1 ~]# ll -Z /var/www/html/test.html     #查看，是否成功
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/test.html
#OK了，沒問題，變成了它最初的類型字段

client端應該又可以訪問了吧？一起瞧瞧：

OK，沒問題了。關于web網頁文件的測試至此結束！！！

2、對FTP服務進行測試

1、修改FTP服務的根目錄

[root@node1 ~]# mkdir /test        #創建一個測試目錄
[root@node1 ~]# usermod -d /test ftp     #將/test目錄修改為FTP服務的默認根目錄
#因為默認根目錄是它的宿主目錄，所以直接改它的宿主目錄，生產環境中，還是建議更改FTP服務的配置文件
[root@node1 ~]# echo -e "Are you ok ? \n `date +%F`" > /test/aaa.txt     #寫入一個測試文件
[root@node1 ~]# ll -Z /test/aaa.txt             #查看該文件的默認類型
-rw-r--r--. root root unconfined_u:object_r:default_t:s0 /test/aaa.txt
#由于這個文件和FTP服務進程沒有關系，所以它的類型和剛安裝時，/var/ftp/pub/test.txt的類型一樣
[root@node1 ~]# systemctl restart vsftpd        #重啟FTP服務，以便更改生效

2、客戶端訪問測試：

當然了，此時，也可以使用chcon命令手動更改該文件的類型，改為和/var/ftp/pub/test.txt一樣的類型，但是不可以使用restorecon命令，因為restorecon命令一般是將文件恢復為它初始的類型，而這個文件現在的類型就是初始類型啊！所以，需要另想其他方法。

方法一：使用setsebool命令修改它的布爾值：

[root@node1 ~]# getsebool -a | grep ftpd         #查看ftp相關的進程控制
ftpd_anon_write --> off     #off表示關閉
ftpd_connect_all_unreserved --> off
ftpd_connect_db --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_fusefs --> off
ftpd_use_nfs --> off
ftpd_use_passive_mode --> off
[root@node1 ~]# setsebool -P ftpd_full_access 1   
#使用setsebool命令修改它訪問相關的布爾值，1表示on（開啟），0表示off（關閉）。
[root@node1 ~]# getsebool -a | grep ftpd         #再次查看
ftpd_anon_write --> off
ftpd_connect_all_unreserved --> off
ftpd_connect_db --> off
ftpd_full_access --> on       #剛才就是將這個訪問相關的進程開啟了
ftpd_use_cifs --> off
ftpd_use_fusefs --> off
ftpd_use_nfs --> off
ftpd_use_passive_mode --> off
[root@node1 ~]# getenforce           #確認SELinux現在是開啟的
Enforcing

client再次訪問：

OK，沒問題，訪問到了

方法2：使用setroubleshoot 工具
Redhat公司針對SELinux發布了一個非常好的工具——setroubleshoot （可以將SELinux的錯誤訊息寫入 /var/log/messages中，并且給出解決方案）
（1）確認setroubleshoot工具已安裝

[root@node1 ~]# rpm -qa | grep setroubleshoot    #查詢該命令是否安裝
[root@node1 ~]# yum -y install setroubleshoot    #沒有安裝的話，使用該命令安裝
[root@node1 ~]# tailf /var/log/messages         #動態刷新查看著日志消息

客戶端訪問：

（2）客戶端訪問失敗的同時，服務器監控的日志消息將會顯示如下提示：

（3）我們運行一下它提示的命令：

[root@node1 ~]# sealert -l 1e24155c-7602-4c51-8eb6-93ec8f77600f     #執行日志中提示的信息
SELinux is preventing vsftpd from read access on the directory test.
#下面的（57.6 confidence）的含義是這一段提供的信息解決這個問題的幾率有多大
#一般幾率越大的越靠前，所以一般看第一個就行
*****  Plugin catchall_boolean (57.6 confidence) suggests   ******************

If 要 allow ftpd to full access
Then 必須啟用 'ftpd_full_access' 布爾值告知 SELinux 此情況。
可以閱讀 'None' 手冊頁面來了解詳情。
Do       #Do表示要運行以下命令來解決問題
setsebool -P ftpd_full_access 1          #就是這條命令咯，我去......好像和我們第一種方法一樣....

*****  Plugin catchall_labels (36.2 confidence) suggests   *******************
#這一段表示解決問題的幾率只有36.2%，越往下幾率越小
If you want to allow vsftpd to have read access on the test directory
Then 必須更改 test 中的標簽
Do
# semanage fcontext -a -t FILE_TYPE 'test'
其中 FILE_TYPE 為以下內容之一：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。
然后執行：
restorecon -v 'test'            #這個幾率只有36.2%的提示信息，讓我們運行這條命令
#那知道為什么幾率這么小么？因為這條命令是讓我們將test恢復默認類型，肯定不會成功呀，它的默認類型就沒有改過

                #.....................省略部分內容
#其實這些提示信息，就是/var/log/messages日志中記錄的，只不過這樣顯示的看起來直觀了很多
[root@node1 ~]# setsebool -P ftpd_full_access 1        #那就執行以下這個57.6%幾率的命令咯

毫無疑問，可以正常訪問到它的ftp服務：

———————— 本文至此結束，感謝閱讀 ————————