linux查看selinux

Ⅰ linux下怎麼查看文件的selinux

首先我們可以用命令來查看selinux的狀態
getenforce
這個命令可以查看到selinux的狀態，當前可以看到是關閉狀態的。
還有一個命令也可以查看出selinux的狀態。
sestatus
-v
還有一個setenforce
命令可以設置selinux的狀態，
具體可以查看
man
8
...

Ⅱ linux如何關閉selinux

首先我們可以用命令來查看selinux的狀態
getenforce 這個命令可以查看到selinux的狀態，當前可以看到是關閉狀態的。
還有一個命令也可以查看出selinux的狀態。
sestatus -v
還有一個setenforce 命令可以設置selinux的狀態，
具體可以查看 man 8 setenforce
假設selinux是正在運行的，我們可以使用setenforce 命令設置臨時關閉，不用重啟生效。
setenforce 0
我們還可以通過編輯文件，然後重啟讓它關閉生效。
vi /etc/sysconfig/selinux
把里邊的一行改為
SELINUX=disabled
setenforce 0 可以臨時關閉，但重啟之後還是會變成原來的狀態。
修改/etc/sysconfig/selinux文件可以永久地禁用它。

Ⅲ 怎麼修改linux 修改selinux狀態

1 永久方法 – 需要重啟伺服器
修改/etc/selinux/config文件中設置SELINUX=disabled ，然後重啟伺服器。
2 臨時方法 – 設置系統參數
使用命令setenforce 0
附：
setenforce 1 設置SELinux 成為enforcing模式
setenforce 0 設置SELinux 成為permissive模式
望採納

Ⅳ 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里邊的selinux

首先我們可以用命令來查看selinux的狀態
getenforce
這個命令可以查看到selinux的狀態，當前可以看到是關閉狀態的。
還有一個命令也可以查看出selinux的狀態。
sestatus
-v
還有一個setenforce
命令可以設置selinux的狀態，
具體可以查看man
8
setenforce
假設selinux是正在運行的，我們可以使用setenforce
命令設置臨時關閉，不用重啟生效。
setenforce
0
還可以通過編輯文件，然後重啟讓它關閉生效。
vi
/etc/sysconfig/selinux
把里邊的一行改為
SELINUX=disabled
改了之後保存，然後重啟就可以了。
改了之後，文件的內容如下圖
setenforce
0可以臨時關閉，但重啟之後還是會變成原來的狀態。
修改/etc/sysconfig/selinux文件可以永久地禁用它。

Ⅵ linux下怎麼查看文件的selinux

首先我們可以用命令來查看selinux的狀態 getenforce 這個命令可以查看到selinux的狀態，當前可以看到是關閉狀態的。 還有一個命令也可以查看出selinux的狀態。 sestatus -v 還有一個setenforce 命令可以設置selinux的狀態， 具體可以查看 man 8 ...

Ⅶ 怎麼查看centos的selinux是否關閉

以下就是關閉SELinux的方法

系統版本：centos 6.5 mini

1、查看selinux狀態
查看selinux的詳細狀態，如果為enable則表示為開啟
# /usr/sbin/sestatus -v

查看selinux的模式
# getenforce

2、關閉selinux
2.1:永久性關閉（這樣需要重啟伺服器後生效）
# sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

2.2:臨時性關閉（立即生效，但是重啟伺服器後失效）
# setenforce 0 #設置selinux為permissive模式（即關閉）
# setenforce 1 #設置selinux為enforcing模式（即開啟）

這樣就關閉SELinux了，當安裝軟體遇到問題時可以考慮關閉SELinux再進行安裝

Ⅷ 如何關閉Linux里邊的selinux

一、查看SELinux狀態命令：1、/usr/sbin/sestatus-v##如果SELinuxstatus參數為enabled即為開啟狀態SELinuxstatus:enabled2、getenforce##也可以用這個命令檢查二、關閉SELinux方法：1、臨時關閉（不用重啟機器）：setenforce0#設置SELinux成為permissive模式#setenforce1設置SELinux成為enforcing模式2、修改配置文件需要重啟機器：修改/etc/selinux/config文件將SELINUX=enforcing改為SELINUX=disabled重啟機器即可

Ⅸ 如何查看，關閉和開啟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 status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Policy version: 18

不重啟關閉selinux的解決辦法:
執行命令：setenforce 0
在新版本中的Red Hat 和 Fedora 上，修改檔案/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