selinux的實際應用
我見過的幾乎所有教程和大多數係統似乎都禁用了 selinux。現實世界中是否有 selinux 安全性的實際實現？
SELinux 是一種強制訪問控制形式，其中使用一組標籤來控制程序可以做什麼或不可以做什麼。Linux 上涉及
ugo權限的預設訪問控制方法是自行決定的 - 它讓使用者自行決定實際確定哪些權限應該去哪裡。使用 SELinux 的強制訪問控制的一個“問題”是，應用程序有時會拒絕按您希望的方式工作，原因顯然很神秘。我們以
rsyslog守護程序為例。目錄和文件/var/log具有正確的 SELinux 標籤以使用rsyslog. 但是，如果您嘗試在系統的其他位置定義日誌文件，例如/opt，rsyslog將無法寫入該文件，因為該文件上的 SELinux 上下文錯誤。由於訪問控制是強制性的，即使您777在新日誌文件上設置權限，也會發生這種情況。在這種特定情況下，可以使用chcon. 但是等等，這些上下文將在文件系統的下一次重新標記時失去。所以你真正需要的是semanage fcontext.正如我試圖用上面的例子來說明的那樣，SELinux 有很強的學習曲線。即使您了解了其工作原理的基礎知識，您仍然需要使用大量命令（
semanage、sestatus、sealert、chcon、restorecon、audit2allow）來達到預期的結果。即使這樣，文件有時也會讓您對哪裡出錯感到困惑。考慮到實際使用 SELinux 的挑戰，大多數人只是發現禁用它是一個更方便的選擇。事實上，U&L 上 SELinux 標籤下投票率最高的問題是關於禁用 SELinux。
還有一點需要注意的是，與 Red Hat 相關的發行版都啟用了 SELinux（Fedora、RHEL 及其衍生產品）。這些系統附帶的 SELinux 策略已經足夠好，以至於很多人通常不會注意到 SELinux 在他們的系統上執行。