Google致力於提高黑人社區的種族平等。 怎麼看。
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

定制SELinux

在集成了SELinux功能的基本級別並徹底分析了結果之後,您可以添加自己的策略設置以涵蓋對Android操作系統的自定義。這些政策必須仍然符合Android兼容性計劃的要求,並且不得刪除默認的SELinux設置。

製造商不應刪除現有的SELinux策略。否則,他們冒著破壞Android SELinux實現及其管理的應用程序的風險。這包括可能需要進行改進以符合法規要求和可操作的第三方應用程序。應用程序無需進行任何修改即可在啟用SELinux的設備上繼續運行。

開始定制SELinux時,請記住:

  • 為所有新守護程序編寫SELinux策略
  • 適當時使用預定義的域
  • 將域分配給作為init服務生成的任何進程
  • 在編寫策略之前要熟悉宏
  • 將對核心策略的更改提交給AOSP

請記住不要:

  • 創建不兼容的策略
  • 允許最終用戶策略自定義
  • 允許自定義MDM策略
  • 恐嚇違反政策的用戶
  • 添加後門

有關特定要求,請參閱Android兼容性定義文檔的“ 內核安全功能”部分。

SELinux使用白名單方法,這意味著必須在策略中明確允許所有訪問權限才能被授予。由於Android的默認SELinux策略已經支持Android開源項目,因此您無需以任何方式修改SELinux設置。如果您確實自定義SELinux設置,請特別注意不要破壞現有的應用程序。開始:

  1. 使用最新的Android內核
  2. 採用最小特權原則
  3. 僅解決您自己對Android的添加。默認策略會自動與Android Open Source Project代碼庫一起使用。
  4. 將軟件組件分隔為執行單個任務的模塊。
  5. 創建SELinux策略,將那些任務與不相關的功能區分開。
  6. 將這些策略放在/device/ manufacturer / device-name /sepolicy目錄中的*.te文件(SELinux策略源文件的擴展名)中,並使用BOARD_SEPOLICY變量將它們包括在構建中。
  7. 最初允許新的域。這是通過在域的.te文件中使用許可聲明來完成的。
  8. 分析結果並優化您的域定義。
  9. 當userdebug版本中沒有其他拒絕出現時,請刪除允許的聲明。

集成SELinux策略更改後,請在開發工作流程中添加一個步驟,以確保SELinux的兼容性。在理想的軟件開發過程中,SELinux策略僅在軟件模型更改時才更改,而在實際實現時不更改。

在開始自定義SELinux時,首先審核對Android的添加。如果您添加了執行新功能的組件,請在啟用強制模式之前,確保該組件符合Android的安全策略以及OEM制定的任何關聯策略。

為了防止不必要的問題,最好是過於寬泛和過度兼容,而不是過於嚴格和不兼容,這會導致設備功能受損。相反,如果您所做的更改會使其他人受益,則應將這些更改作為補丁提交至默認的SELinux策略。如果將補丁程序應用於默認安全策略,則無需在每個新的Android版本中進行此更改。

政策聲明示例

SELinux基於M4計算機語言,因此支持各種宏以節省時間。

在以下示例中,所有域都被授予對/dev/null進行讀取或寫入以及從/dev/zero進行讀取的訪問權限。

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

可以使用SELinux *_file_perms宏(簡寫形式)編寫相同的語句:

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

政策範例

這是DHCP的完整示例策略,我們在下面進行檢查:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

讓我們剖析示例:

在第一行(類型聲明)中,DHCP守護程序繼承自基本安全策略( domain )。從前面的語句示例中,DHCP可以讀寫/dev/null

在第二行中,DHCP被標識為許可域。

init_daemon_domain(dhcp)行中,策略指出DHCP是從init派生的,並允許與其通信。

net_domain(dhcp)行中,該策略允許DHCP使用來自net域的通用網絡功能,例如讀取和寫入TCP數據包,通過套接字進行通信以及執行DNS請求。

在這一行中allow dhcp proc_net:file write; ,該策略指出DHCP可以寫入/proc特定文件。此行演示了SELinux的細粒度文件標籤。它使用proc_net標籤將寫訪問權限限制為僅對/proc/sys/net下的文件。

該示例的最後一個塊以allow dhcp netd:fd use;描述瞭如何允許應用程序彼此交互。該策略表示DHCP和netd可以通過文件描述符,FIFO文件,數據報套接字和UNIX流套接字相互通信。 DHCP只能讀寫數據報套接字和UNIX流套接字,而不能創建或打開它們。

可用控件

允許
文件
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
目錄
add_name remove_name reparent search rmdir open audit_access execmod
插座
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
文件系統
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
處理
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
安全
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
能力
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

更多

和更多

永遠禁止規則

SELinux neverallow規則禁止不應發生的行為。通過兼容性測試,SELinux neverallow規則現在可以在設備之間執行。

以下準則旨在幫助製造商避免在定製過程中與neverallow規則相關的錯誤。此處使用的規則編號對應於Android 5.1,並且可能會因版本而異。

規則48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
有關ptrace請參見手冊頁。 sys_ptrace功能授予ptrace任何進程的功能,從而可以對其他進程進行大量控制,並且應僅屬於規則中概述的指定係統組件。對該功能的需求通常表明存在某種不存在於不需要的面向用戶的版本或功能的東西。刪除不必要的組件。

規則76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
該規則旨在防止在系統上執行任意代碼。具體來說,它聲稱僅執行/system上的代碼,這歸功於諸如經過驗證的引導之類的機制,因此可以保證安全性。通常,遇到此neverallow規則的問題時,最好的解決方案是將有問題的代碼移動到/system分區。

在Android 8.0+中自定義SEPolicy

本部分為Android 8.0及更高版本中的供應商SELinux策略提供指南,包括有關Android開放源代碼項目(AOSP)SEPolicy和SEPolicy擴展的詳細信息。有關SELinux策略如何在分區和Android版本之間保持兼容的更多信息,請參見Compatibility

政策放置

在Android 7.0和更早版本中,設備製造商可以向BOARD_SEPOLICY_DIRS添加策略,包括旨在在不同設備類型之間擴展AOSP策略的策略。在Android 8.0及更高版本中,將策略添加到BOARD_SEPOLICY_DIRS會將策略僅放置在供應商映像中。

在Android 8.0及更高版本中,策略位於AOSP中的以下位置:

  • 系統/安全政策/公共 。包括導出的策略以供特定於供應商的策略使用。一切都進入了Android 8.0 兼容性基礎架構 。公共策略應在各個發行版中保持不變,因此您可以在自定義策略中包括/public 。因此,可以放在/public的策略類型受到更多限制。考慮一下該平台的導出策略API:處理/system/vendor之間的接口的任何事物都在這裡。
  • 系統/安全/私有 。包括系統映像正常運行所必需的策略,但是其中哪個供應商映像策略應該不了​​解。
  • 系統/安全策略/供應商 。包括用於/vendor但存在於核心平台樹中(而不是特定於設備的目錄)的組件的策略。這是構建系統區分設備和全局組件的一種人工產物。從概念上講,這是下面描述的特定於設備的策略的一部分。
  • 設備/ manufacturer / device-name / sepolicy 。包括特定於設備的策略。還包括針對策略的設備自定義,在Android 8.0及更高版本中,該自定義對應於供應商映像上組件的策略。

支持的策略方案

在使用Android 8.0及更高版本啟動的設備上,供應商映像必須與OEM系統映像以及Google提供的參考AOSP系統映像配合使用(並在此參考映像上傳遞CTS)。這些要求確保了框架與供應商代碼之間的明確區分。此類設備支持以下方案。

僅供應商圖像擴展

示例 :從供應商映像向vndservicemanager添加新服務,以支持供應商映像中的進程。

與使用device/ manufacturer / device-name /sepolicy Android版本啟動的設備一樣,在device/ manufacturer / device-name /sepolicy添加特定於device/ manufacturer / device-name /sepolicy自定義。管理供應商組件如何(僅)與其他供應商組件交互的新策略應涉及僅在device/ manufacturer / device-name /sepolicy 。此處編寫的策略允許供應商上的代碼起作用,不會作為僅框架OTA的一部分進行更新,並且將與參考AOSP系統映像一起出現在設備的組合策略中。

供應商圖像支持與AOSP一起使用

示例 :添加一個新的過程(從供應商映像中向hwservicemanager註冊),以實現AOSP定義的HAL。

與使用device/ manufacturer / device-name /sepolicy Android版本啟動的設備一樣,請在device/ manufacturer / device-name /sepolicy執行特定於device/ manufacturer / device-name /sepolicy自定義。作為system/sepolicy/public/一部分導出的策略可供使用,並作為供應商策略的一部分提供。公共策略的類型和屬性可能會在新規則中使用,該新規則指示與新的特定於供應商的位進行交互,但要遵守所提供的neverallow限制。與僅供應商的情況一樣,此處的新策略將不會作為僅框架OTA的一部分進行更新,而是會在帶有參考AOSP系統映像的設備上的組合策略中出現。

僅系統映像擴展

示例 :添加新服務(在servicemanager中註冊),該服務只能由其他進程從系統映像訪問。

將此策略添加到system/sepolicy/private 。您可以添加額外的流程或對像以在合作夥伴系統映像中啟用功能,前提是這些新位不需要與供應商映像上的新組件進行交互(具體來說,此類流程或對象必須在沒有供應商映像的策略的情況下完全運行) 。 system/sepolicy/public政策system/sepolicy/public導出的策略在此處可用,就像僅用於供應商映像的擴展一樣。此策略是系統映像的一部分,可以在僅框架的OTA中進行更新,但在使用參考AOSP系統映像時將不存在。

供應商映像擴展,用於擴展的AOSP組件

示例:一個新的非AOSP HAL,供AOSP系統映像中也存在的擴展客戶端使用(例如,擴展的system_server)。

系統和供應商之間交互的策略必須包含在供應商分區中隨附的device/ manufacturer / device-name /sepolicy目錄中。這類似於上述添加供應商映像支持以與參考AOSP映像一起使用的方案,不同之處在於,修改後的AOSP組件可能還需要其他策略才能與系統分區的其餘部分一起正常運行(只要它們仍然可用具有公共AOSP類型標籤)。

公共AOSP組件與僅系統映像擴展名交互的策略應該在system/sepolicy/private

僅訪問AOSP接口的系統映像擴展

示例:新的非AOSP系統進程必須訪問AOSP所依賴的HAL。

這類似於僅系統映像的擴展示例 ,不同之處在於新的系統組件可能會跨system/vendor界面進行交互。新系統組件的策略必須放在system/sepolicy/private ,只要通過AOSP在system/sepolicy/public已經建立的接口(即功能所需的類型和屬性在那裡),該策略就可以接受。儘管策略可以包含在特定於設備的策略中,但由於僅框架更新,它將無法使用其他system/sepolicy/private類型或更改(以任何不影響策略的方式)。可以在僅框架的OTA中更改該策略,但是在使用AOSP系統映像(該映像也不包含新的系統組件)時將不存在該策略。

服務於新系統組件的供應商映像擴展

示例:添加一個新的非AOSP HAL,供沒有AOSP類似物的客戶端進程使用(因此需要其自己的域)。

AOSP擴展示例類似,用於系統與供應商之間交互的策略必須位於供應商分區上隨附的device/ manufacturer / device-name /sepolicy目錄中(以確保系統策略不了解供應商特定的詳細信息)。您可以添加新的公共類型來擴展system/sepolicy/public的策略;僅應在現有AOSP策略之外執行此操作,即不要刪除AOSP公共策略。然後,新的公共類型可用於在政策system/sepolicy/privatedevice/ manufacturer / device-name /sepolicy

請記住,對system/sepolicy/public添加都會通過公開必須在映射文件中進行跟踪且受其他限制的新兼容性保證而增加了複雜性。只能在system/sepolicy/public添加新類型和相應的允許規則;屬性和其他策略聲明不受支持。此外,新的公共類型不能用於直接標記/vendor策略中的對象。

不支持的策略方案

使用Android 8.0及更高版本啟動的設備不支持以下策略方案和示例。

僅框架OTA之後需要新的供應商映像組件權限的系統映像的其他擴展

示例:在下一個Android版本中添加了一個新的非AOSP系統進程,該進程需要自己的域,並且需要訪問新的非AOSP HAL。

新的(非AOSP)系統和供應商組件交互類似,不同之處在於,新的系統類型是在僅框架的OTA中引入的。儘管可以在system/sepolicy/public中將新類型添加到策略中,但是現有的供應商策略不了解新類型,因為它僅跟踪Android 8.0系統公共策略。 AOSP通過通過屬性(例如hal_foo屬性)公開供應商提供的資源來解決此問題,但是由於system/sepolicy/public不支持屬性合作夥伴擴展,因此該方法不適用於供應商策略。訪問必須由以前存在的公共類型提供。

示例:對系統進程(AOSP或非AOSP)的更改必須更改其與新的非AOSP供應商組件交互的方式。

必須在不了解特定供應商自定義的情況下編寫系統映像上的策略。因此,有關AOSP中特定接口的策略是通過系統/安全策略/公共屬性來公開的,以便供應商策略可以選擇加入使用這些屬性的未來系統策略。但是, 不支持system/sepolicy/public中的屬性擴展 ,因此所有指示系統組件如何與新的供應商組件進行交互的策略(並且AOSP system/sepolicy/public已經不存在的屬性處理的所有策略)必須位於device/ manufacturer / device-name /sepolicy 。這意味著,作為純框架OTA的一部分,系統類型無法更改對供應商類型的允許訪問。