㈠ selinux怎麼開放對samba的限制
方法一：關閉SELinux，並修改配置文件，使系統啟動時不啟動SELinux。（我採用的是這種方法）
Disable selinux
[root@Jie ~]# vi /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
把 SELINUX設定為disable, 下次啟動系統後將會停止SElinux。
Linux核心參數(Kernel Parameter)
或者可以在核心參數後加上： selinux=0 （停止） 或 selinux=1 (開啟）參數
檔案/boot/grub/menu.lst
title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet selinux=0
initrd /initrd-2.6.18-1.2798.fc6.img
檢查SELinux現時況態
要知到你現在是否使用 SELinux:
# getenforce
disabled
方法二：不關閉SELinux配置 samba的方法（未測試）
將smb.conf中如下這兩行啟用（去掉行首的；號就可以了）
setsebool -P samba_domain_controller on setsebool -P samba_enable_home_dirs on這兩行生效後，自己的home目錄就可以正常讀寫了。
如果想將/home/samba/temp目錄設置成完全的共享就應該在字元狀態寫輸入：chcon -t samba_share_t /home/samba/temp 同時不要忘記將/home/samba/temp目錄屬性設置成777 就可以了。其它和以前的FC版本應該沒有什麼區別了。
默認的，SELinux禁止網路上對Samba伺服器上的共享目錄進行寫操作，即使你在smb.conf中允許了這項操作。
假設你已經配置了共享目錄/share並允許用戶進行讀寫，而你又不想關閉SELinux的話，可以試試以下操作：
程序代碼:
#/usr/sbin/setsebool -P allow_smbd_anon_write=1
#chcon -t public_content_rw_t /share
其中第一條語句設置SELinux放行標記了public_content_rw_t的內容，第二條語句把欲共享的/share目錄標記為public_content_rw_t。
附SELinux資料：
selinux簡介
SElinux 在linux內核級別上提供了一個靈活的強制訪問控制系統(MAC)，這個強制訪問控制系統是建立在自由訪問控制系統(DAC)之上的。
DAC是指系統的安全訪問控制都是由系統管理員root自由管理的，不是系統強制行為
MAC運行的時候，比如一個應用程序或者一個線程以某個用戶UID或者SUID運行的時候同樣對一些其他的對象擁有訪問控制限制，比如文件,套接子（sockets）或者其他的線程
通過運行SElinux MAC內核可以保護系統不受到惡意程序的侵犯，或者系統本身的bug不會給系統帶來致命影響（把影響限定在一定范圍內）
SElinux為每一個用戶，程序，進程，還有文件定義了訪問還有傳輸的許可權。然後管理所有這些對象之間的交互關系
對於SELinux設定的對象全限是可以根據需要在安裝時候規定嚴格程度，或者完全禁用
在大多數情況下，SElinux對於用戶來說是完全透明的，普通用戶根本感覺不到 Selinux的存在，只有系統管理員才需要對這些用戶環境，以及策略進行考慮。這些策略可以按照需要寬松的部署或者應用嚴格的限制，Selinux提供 了非常具體的控制策略，范圍覆蓋整個linux系統
比如，當一個對象如應用程序要訪問一個文件對象，內核中的控製程序檢查訪問向量緩存 (AVC),從這里尋找目標和對象的許可權，如果在這里沒有發現許可權定義，則繼續查詢安全定義的上下關聯，以及文件許可權，然後作出准許訪問以及拒絕訪問的決 定。如果在var/log/messages出現avc: denied信息,則表明訪問拒絕。
目標和對象通過安裝的策略來決定自身的安全關聯，同時這些安裝的策略也負責給系統產生安全列表提供信息。
除了運行強制模式以外，SELinux可以運行在許可模式，這時候，檢查AVC之後，拒絕的情況被記錄。Selinux不強制使用這種策略.
以下介紹一下SELinux相關的工具
/usr/bin/setenforce 修改SELinux的實時運行模式
setenforce 1 設置SELinux 成為enforcing模式
setenforce 0 設置SELinux 成為permissive模式
如果要徹底禁用SELinux 需要在/etc/sysconfig/selinux中設置參數selinux=0 ，或者在/etc/grub.conf中添加這個參數
/usr/bin/setstatus -v
㈡ SELinux許可權
在了解SELinux之前，我們先來了解一下Linux的兩種訪問控制策略：DAC和MAC
DAC，自主訪問控制（Discretionary Access control）。系統只提供基本的驗證, 完整的訪問控制由開發者自己控制。
DAC將資源訪問者分成三類：Owner、Group、Other 。
將訪問許可權也分成三類：read、write、execute
資源針對資源訪問者設置不同的訪問許可權。訪問者通常是各個用戶的進程，有自己的uid/gid，通過uid/gid 和文件許可權匹配, 來確定是否可以訪問。DAC機制下，每一個用戶進程默認都擁有該用戶的所有許可權。
DAC 有兩個嚴重問題：
問題一：
因為Root用戶是擁有所有許可權的，所以DAC對Root用戶的限制是無效的。並且在Linux Kernel 2.1以後，Linux將Root許可權根據不同的應用場景劃分成許多的Root Capabilities, 普通用戶也可以被設置某個Root Capability。普通用戶如果被設置了CAP_DAC_OVERRIDE， 也可以繞過 DAC 限制。
問題二：
用戶進程擁有該用戶的所有許可權，可以修改/刪除該用戶的所有文件資源, 難以防止惡意軟體。
可見，DAC 有明顯的缺陷，一旦被入侵，取得Root許可權的用戶進程就可以無法無天，胡作非為，早期android版本就深受其害。
MAC， 強制性訪問控制（Mandatory Access control）。 系統針對每一項訪問都進行嚴格的限制, 具體的限制策略由開發者給出。
Linux MAC 針對DAC 的不足, 要求系統對每一項訪問, 每訪問一個文件資源都需要根據已經定義好了的策略進行針對性的驗證。系統可以針對特定的進程與特定的文件資源來進行許可權的控制。即使是root用戶，它所屬的不同的進程，並不一定能取得root許可權，而得要看事先為該進程定義的訪問限制策略。如果不能通過MAC 驗證，一樣無法執行相關的操作。
與DAC相比，MAC訪問控制的「主體」變成了「進程」而不是用戶。這樣可以限制了Root 許可權的濫用，另外要求對每一項許可權進行了更加完整的細化, 可以限制用戶對資源的訪問行為。
SELinux就是目前最好的MAC機制，也是目前的行業標准。
SELinux，安全增強Linux（Security-Enhanced Linux），是由美國國家安全局(NSA)發起, 多個非營利組織和高校參與開發的強制性安全審查機制（Mandatory Access control，簡稱MAC）。SELinux最早於2000年12月採用GPL許可發布。目前，Linux Kernel 2.6 及以上的版本都已經集成了SELinux。
SELinux 分成三種模式：
Android 5.x及以上強制開啟，因此，disabled(關閉)模式並沒有什麼用了。 通常在調試時，我們會啟用Permissve(寬容模式), 以便盡可能的發現多的問題, 然後一次修正。 在量產時啟用Enfocing mode(強制模式)來保護系統。
查看SELinux模式：adb shell getenforce
設置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing
SELinux 的訪問控制示意圖：
通常我們開發的過程中，就是配置Subject、Object、Security Policy。
SELinux 給Linux 的所有對象都分配一個安全上下文(Security Context)， 描述成一個標準的字元串。
安全上下文的標准格式： user:role:type[:range]
Security Label 用來綁定被訪問資源和安全上下文，描述它們的對應關系。標准格式為：resource security_context。即：res user:role:type[:range]。這里也可以使用通配符，例如 net.就可以綁定所有以net.開頭的屬性，除此之外，還有類似正則表達式的*、？等等通配符。Security Label 都定義在type_contexts當中，例如file的定義在file_contexts中，service定義在service_contexts中，property定義在property_contexts中。
舉例：
file_contexts:
service_contexts:
查看進程安全上下文： ps -AZ 。例如，查看Settings進程的安全上下文，ps -AZ | grep settings：
u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls -Z 。例如，查看文件build.prop的安全上下文：
u:object_r:system_file:s0 build.prop
Type Enforcement (TE) 是根據Security Context中的 type 進行許可權審查, 審查 subject type 對 object type 的某個class 類型中某種permission 是否具有訪問許可權，是目前使用最為廣泛的MAC 審查機制, 簡單易用。
TE控制語句格式 : rule_name source_type target_type : class perm_set
Type Enforcement規則說明：
舉個例子，logd.te、tombstoned.te中定義的TE規則：
allow logd runtime_event_log_tags_file:file rw_file_perms;
dontaudit domain runtime_event_log_tags_file:file { open read };
auditallow tombstoned anr_data_file:file { append write };
neverallow logd { app_data_file system_data_file }:dir_file_class_set write;
SELinux 中每一個進程或者文件都對應一個type, 而每一個type 都對應有一個或幾個attribute。所有常見的attribute定義在以下文件中：
system/sepolicy/public/attributes
system/sepolicy/prebuilts/api/[build version]/public/attributes
system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即為android版本號，例如android O為28.0。常見的attribute定義：
Type對應一個或者幾個attribute，Type的定義格式：
type type_name, attribute1, attribute2；
Type的定義通常分散在各個te文件中。例如，常用普通文件的type定義在file.te中：
SEAndroid對於不同的資源類型，定義了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如針對每個process 參數的process 等定義相關的class。這些class，每一個class 都有相對應的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。這些相關的class, 以及他們具有那些Permissions都定義在以下文件中：
system/sepolicy/private/access_vectors
system/sepolicy/reqd_mask/access_vectors
system/sepolicy/prebuilts/api/版本號/private/access_vectors
例如：
定義完之後，在以下對應的security_classes 文件中聲明定義的classes。
system/sepolicy/private/security_classes
system/sepolicy/reqd_mask/security_classes
system/sepolicy/prebuilts/api/版本號/private/security_classes
例如：
注意，Classes 和Permissions的定義與Kernel 中相關API是強相關的，普通用戶嚴禁修改。
在SELinux 中, 我們通常稱一個進程是一個domain, 一個進程fork 另外一個進程並執行(exec) 一個執行檔時, 我們往往會涉及到domain 的切換. 比如init 進程, SELinux 給予了它很大的許可權, 而它拉起的服務, 我們要限制這個服務的許可權，於是就涉及到從一個domain 切換到另外一個domain, 不然默認就使用init 進程的domain.
在SELinux 裡面有專門的一條語法: type_transition statement.
在准備切換前我們先要確保有相關的許可權操作：
如下面的demo, init 拉起apache 並且切換到 apache 的domain.
(1). 首先，你得讓init_t域中的進程能夠執行type為apache_exec_t的文件
allow init_t apache_exec_t : file {read getattr execute};
(2). 然後，你還得告訴SELinux，允許init_t做DT切換以進入apache_t域
allow init_t apache_t : process transition;
(3). 然後，你還得告訴SELinux，切換入口（對應為entrypoint許可權）為執行apache_exec_t類型 的文件
allow apache_t apache_exec_t : file entrypoint;
(4).最後，Domain Transition
type_transition init_t apache_exec_t : process apache_t;
可以看到，整個domain切換過程寫起來非常麻煩。因此，Google 為了使用方便, 在system/sepolicy/public/te_macros 文件中定義了宏：
我們可以使用這些宏來完成domain切換。
舉例：
kernel啟動init進程切換domain:
domain_auto_trans(kernel, init_exec, init)
init啟動netd、vold、zygote、installd切換domain:
init_daemon_domain(netd)
init_daemon_domain(vold)
init_daemon_domain(zygote)
init_daemon_domain(installd)
一個進程創建在一個目錄下創建文件時, 默認是沿用父目錄的Security Context, 如果要設置成特定的Label, 就必須進行Object Transitions.
同樣是使用：type_transition statement.
對應的必須有兩個前提條件:
下面是一個demo, ext_gateway_t 這個domain 在類型為in_queue_t 的目錄下，創建類型為 in_file_t 的文件.
(1). 首先，你得讓ext_gateway_t 對in_queue_t 目錄具備訪問許可權
allow ext_gateway_t in_queue_t : dir { write search add_name };
(2). 然後，你還得告訴SELinux，允許ext_gateway_t 訪問in_file_t的文件
allow ext_gateway_t in_file_t : file { write create getattr };
(3).最後，Object Transition
type_transition ext_gateway_t in_queue_t : file in_file_t;
同樣的，為了方便使用，Google 也在system/sepolicy/public/te_macros 文件中定義了宏:
使用舉例：
file_type_auto_trans(factory, system_data_file, factory_data_file)
android O 以前sepolicy 集中放在boot image 。前面提到SELinux在Android的主要變更歷史時，有提到android O 開始，Google將system image 和 vendor image 分離。因此，sepolicy 也相應的被分離存放到system image 以及 vendor image。與system 相關的sepolicy 就存放system image, 與SoC vendor 相關的sepolicy 就存放在vendor image。
對於原生AOSP，Google 設定了不同的存放目錄, 以便進行分離, 以Google 默認的sepolicy 為例，sepolicy主目錄為 /system/sepolicy，我們主要關注三個子目錄：
對於不同的平台，不同平台廠商也設定了不同的存放目錄，以MTK平台為例：
首先，根據不同的platform共用sepolicy、platform獨有、project獨有，分為：
對應的，不同版本會導入不同目錄下的sepolicy配置
以mt6763平台為例，導入時：
[common] 路徑為：/device/mediatek/sepolicy
[platfrom] 路徑為：/device/mediatek/mt6763/sepolicy/
具體的定義在BoardConfig.mk文件中:
然後，basic、bsp、full又可以主要細分為：
Google 在system/sepolicy 中定義了相關的neverallow 規則, 對SELinux Policy 的更新進行了限制, 以防止開發者過度開放許可權，從而引發安全問題。並且還會通過CTS測試檢測開發者是否有違法相關的規則。
因此，我們需要注意以下幾點：
出現SELinux Policy Exception時常見的兩種解決方案：
(1). 修改對應節點的SELinux Security Label, 為特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等內置APP開啟許可權, 但嚴禁為untrsted app 開啟許可權。
(2). 通過system server service 或者 init 啟動的service 讀寫操作, 然後app 通過binder/socket 等方式連接訪問. 此類安全可靠, 並且可以在service 中做相關的安全審查, 推薦這種方法.
情景: 定義由 init 進程啟動的service, factory, 其對應的執行檔是 /vendor/bin/factory。
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat 目錄下創建一個factory.te , 然後將te文件加入編譯，如放到這種指定目錄下不需要額外配置，sytem/sepolicy/Android.mk中定義的build_policy函數會遍歷指定目錄導入te文件。
(2). 在factory.te 中定義factory類型，init 啟動service 時類型轉換,
type factory, domain;
type factory_exec, exec_type, file_type, vendor_file_type;
init_daemon_domain(factory)
(3). 在file_contexts中綁定執行檔
/(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0
(4). 根據factory需要訪問的文件以及設備, 定義其它的許可權在factory.te 中.
#Purpose: For key and touch event
allow factory input_device:chr_file r_file_perms;
allow factory input_device:dir rw_dir_perms;
情景: 添加一個自定義的system property： persist.demo，並為platform_app設置讀寫許可權
(1). 在property.te中定義system property類型
type demo_prop, property_type
(2). 在property_contexts中綁定system property的安全上下文。
persist.demo u:object_r:demo_prop:s0
(3). 在platform_app.te 中新增寫許可權，可以使用set_prop宏。
set_prop(platform_app, demo_prop)
(4). 在platform_app.te 中新增讀許可權，可以get_prop 宏。
get_prop(platform_app, demo_prop)
情景: 有一個設備節點/dev/demo，有一個platform_app進程需要讀寫這個設備節點。
(1). 在device.te中定義device 類型
type demo_device dev_type;
(2). 在 file_contexts中綁定demo_device
/dev/demo u:object_r:demo_device:s0
(3). 在platform_app.te中，允許platform_app使用demo device 的許可權
allow platform_app demo_device:chr_file rw_file_perms;
情景: 有一個擴展的系統服務demo_service供APP調用。
(1). 在service.te 中定義service 類型
type demo_service, app_api_service, system_server_service, service_manager_type;
(2). 在service_contexts 中綁定service
demo u:object_r:demo_service:s0
(3). 在frameworks/base/core/java/android/content/Context.java中定義服務常量
public static final String DEMO_SERVICE = "demo";
(4). 在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，參照其它系統服務注冊demo_service
(5). 在frameworks/base/services/java/com/android/server/SystemServer.java中，啟動DemoService，添加到service_manager進行管理。
(6). 最後一步，參考其它系統服務，實現DemoManager、DemoService，並定義如IDemoService等等的AIDL介面。
情景: 一個native service 通過init 創建一個socket 並綁定在 /dev/socket/demo, 並且允許某些process 訪問.
(1). 在file.te中定義socket 的類型
type demo_socket, file_type;
(2). 在file_contexts中綁定socket 的類型
/dev/socket/demo_socket u:object_r:demo_socket:s0
(3). 允許所有的process 訪問，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
unix_socket_connect(appdomain, demo, demo)
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat目錄下創建一個demo.te。
(2). 在demo.te 中定義demo 類型，init 啟動service 時類型轉換。並可以根據demo 需要訪問的文件以及設備, 定義其它的許可權在demo.te 中。
type demo, domain;
type demo_exec, exec_type, file_type;
init_daemon_domain(demo)
(3). 綁定執行檔 file_context 類型
/vendor/bin/demo u:object_r:demo_exec:s0
(4). 創建demo的入口執行檔demo_exec、並配置相應的許可權。
(1). 將SELinux 調整到Permissive 模式復測
使用eng/userdebug 版本，adb shell setenforce 0 將SELinux 模式調整到Permissive 模式，然後復測。如果還能復現問題，則與SELinux 無關； 如果原本很容易復現, 而Permissive mode 不能再復現, 那麼就可能與SELinux相關。
(2). 查看LOG 中是否有標準的SELinux Policy Exception.
在Kernel LOG / Main Log 中查詢關鍵字 "avc: denied" 看看是否有與目標進程相關的SELinux Policy Exception, 並進一步確認這個異常是否與當時的邏輯相關。
一般情況我們在符合Google sepolicy策略及neverallow策略的前提下，根據LOG中的內容，需要什麼許可權就加什麼許可權。例如LOG：
2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
LOG說明如下：
一般我們需要重點關注的是四個：permission、source type、target type、target class
根據這四個就可以配置出的所需要的selinux許可權：
allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied { read } for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0
解決方案：
按正常的套公式，應該是這樣修改platform_app.te，增加：
allow platform_app graphics_debug_prop:file r_file_perms;
這里我們利用system/sepolicy/te_macros中定義的宏get_prop：
更多相關的宏定義請參考：system/sepolicy/public/te_macros。
所以最終簡化後，修改platform_app.te，增加：
get_prop(platform_app, graphics_debug_prop)
例2：
03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
解決方案：
修改platform_app.te增加：
allow platform_app als_ps_device:chr_file r_file_perms;
(1). 不符合neverallow規則或者修改了neverallow規則
編譯報錯：
neverallow check failed at xxx
CTS測試項failed：
android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
這類問題在android O vendor和system分離之後，尤其容易出現。基本上這類問題都是因為修改或者增加的te配置不符合neverallow規則，導致編譯報錯。而為了解決編譯報錯，又修改了neverallow規則，最終在跑CTS時，沒法通過相關的測試項。
解決思路：
(2). init進程fork新進程沒有做domain切換
CTS測試項failed：
android.security.cts.SELinuxDomainTest # testInitDomain
解決思路：
fork進程時，參考3.4節中做domain切換。
本文主要參考了MTK-Online的Quick-start中《SELinux 問題快速分析》的內容，感謝原作者們的辛勤付出。另外，結合源碼和自身開發實踐，增加了一些自身理解和實踐內容。
㈢ 在linux系統安裝tomcat後，bin文件下startup.sh啟動不了，這是什麼原因
Permission denied 許可被拒絕
回答人的補充 2009-08-18 12:51
在linux上安裝有些東西時會出現 Permission denied 的情況：以下就是解決它的辦法之一
編輯/etc/selinux/config，找到這段：
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
把 SELINUX=enforcing 注釋掉：#SELINUX=enforcing ，然後新加一行為：
SELINUX=disabled
保存，關閉。
......
編輯/etc/sysconfig/selinux，找到:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
如果SELINUX已經是 SELINUX=disabled，那麼就不用改了，否則就把SELINUX=enforcing 注釋掉，新加一行：
SELINUX=disabled
保存，退出。
如果你碰到其他類似提示：
cannot restore segment prot after reloc: Permission denied
哪應該是SELinux的問題，可以考慮把它關閉。
-------------------------------------------------------------------------------------
在你保證SElinux 被disable後.還執行下
chcon -t texrel_shlib_t
如: chcon -t texrel_shlib_t /路徑/路徑/名字.so (這個文件視具體執行文件.)
以上兩步.已經解決了很多server的問題了.
這是我以前還有linux的時候網路的方法，你可以試一試，不知道對你管不管用，另外，你有操作許可權嗎？
㈣ Linux的系統的安全如何保障保護Linux系統安全的九個常用方法
在現在這個世道中，保障基於Linux的系統的安全是十分重要的。但是，你得知道怎麼干。一個簡單反惡意程序軟體是遠遠不夠的，你需要採取其它措施來協同工作。那麼Linux的系統的安全如何保障？今天小編就為大家總結九個常用方法來保護Linux系統安全，希望能幫助到大家。
1. 使用SELinux
SELinux是用來對Linux進行安全加固的，有了它，用戶和管理員們就可以對訪問控制進行更多控制。SELinux為訪問控制添加了更細的顆粒度控制。與僅可以指定誰可以讀、寫或執行一個文件的許可權不同的是，SELinux可以讓你指定誰可以刪除鏈接、只能追加、移動一個文件之類的更多控制。(LCTT譯註：雖然NSA也給SELinux貢獻過很多代碼，但是目前尚無證據證明SELinux有潛在後門)
2禁用不用的服務和應用
通常來講，用戶大多數時候都用不到他們系統上的服務和應用的一半。然而，這些服務和應用還是會運行，這會招來攻擊者。因而，最好是把這些不用的服務停掉。(LCTT譯註：或者乾脆不安裝那些用不到的服務，這樣根本就不用關注它們是否有安全漏洞和該升級了。)
3 訂閱漏洞警報服務
安全缺陷不一定是在你的操作系統上。事實上，漏洞多見於安裝的應用程序之中。為了避免這個問題的發生，你必須保持你的應用程序更新到最新版本。此外，訂閱漏洞警報服務，如SecurityFocus。
4 使用Iptables
Iptables是什麼?這是一個應用框架，它允許用戶自己為系統建立一個強大的防火牆。因此，要提升安全防護能力，就要學習怎樣一個好的防火牆以及怎樣使用Iptables框架。
5 檢查系統日誌
你的系統日誌告訴你在系統上發生了什麼活動，包括攻擊者是否成功進入或試著訪問系統。時刻保持警惕，這是你第一條防線，而經常性地監控系統日誌就是為了守好這道防線。
6 考慮使用埠試探
設置埠試探(Port knocking)是建立伺服器安全連接的好方法。一般做法是發生特定的包給伺服器，以觸發伺服器的回應/連接(打開防火牆)。埠敲門對於那些有開放埠的系統是一個很好的防護措施。
7. 默認拒絕所有
防火牆有兩種思路：一個是允許每一點通信，另一個是拒絕所有訪問，提示你是否許可。第二種更好一些。你應該只允許那些重要的通信進入。(LCTT譯註：即默認許可策略和默認禁止策略，前者你需要指定哪些應該禁止，除此之外統統放行;後者你需要指定哪些可以放行，除此之外全部禁止。)
8.使用全盤加密
加密的數據更難竊取，有時候根本不可能被竊取，這就是你應該對整個驅動器加密的原因。採用這種方式後，如果有某個人進入到你的系統，那麼他看到這些加密的數據後，就有得頭痛了。根據一些報告，大多數數據丟失源於機器被盜。
9.使用入侵檢測系統
入侵檢測系統，或者叫IDS，允許你更好地管理系統上的通信和受到的攻擊。Snort是目前公認的Linux上的最好的IDS。
以上就是保護Linux系統安全的九個常用方法，希望能幫助到大家！