我的自定義selinux策略似乎被android系統忽略了

Question

我在基於AOSP的Android 7.1.2（更准確地說是基於sony開放設備樹）上正確運行自定義selinux策略時遇到一些麻煩。

我的問題是審計日志不斷告訴我我實際添加的文件訪問規則丟失。 我還將audit2allow創建的規則復制到我的策略文件中，但即使那些規則也沒有正常工作。

那么，讓我們深入了解細節：

我創建了一個名為vendor_app的自定義域。 此域根據其簽名分配給應用程序。 我在mac_permissions.xml中添加了一個條目來分配seinfo字段供應商 。 在seapp_contexts中，我像這樣分配vendor_app域：

user=_app seinfo=vendor domain=vendor_app type=app_data_file levelFrom=user

我的應用程序在vendor_app上下文中正確啟動：

# ps -Z | grep permissiontest
u:r:vendor_app:s0:c512,c768    u0_a109   4110  508   1620732 79584 SyS_epoll_ 0000000000 S com.vendor.android.permissiontest

所以，現在對於根本不起作用的部分。 在vendor_app上下文中運行的應用程序將獲得/ persist / vendor中文件的讀/寫訪問權限。 為了創建nessesary規則，我將一個名為vendor.te的文件添加到設備目錄中的sepolicy文件夾中，其中包含以下內容：

type vendor_app, domain;
type vendor_file, file_type, data_file_type;
# permissive vendor_app;

app_domain(vendor_app)
net_domain(vendor_app)
bluetooth_domain(vendor_app)

allow vendor_app persist_file:dir r_dir_perms;
allow vendor_app vendor_file:dir create_dir_perms;
allow vendor_app vendor_file:file create_file_perms;

allow vendor_app audioserver_service:service_manager find;
allow vendor_app cameraserver_service:service_manager find;
allow vendor_app drmserver_service:service_manager find;
allow vendor_app mediaserver_service:service_manager find;
allow vendor_app mediaextractor_service:service_manager find;
allow vendor_app mediacodec_service:service_manager find;
allow vendor_app mediadrmserver_service:service_manager find;
allow vendor_app persistent_data_block_service:service_manager find;
allow vendor_app radio_service:service_manager find;
allow vendor_app surfaceflinger_service:service_manager find;
allow vendor_app app_api_service:service_manager find;
allow vendor_app system_api_service:service_manager find;
allow vendor_app vr_manager_service:service_manager find;

我在file_contexts配置中添加了一個條目：

###################################
# persist files
#
/persist(/.*)?                                                      u:object_r:persist_file:s0
/persist/vendor(/.*)?                                               u:object_r:vendor_file:s0

在/ persist分區上，我創建了一些目錄結構，使文件夾具有適當的權限，可以在那里添加一些文件。

# ls -Zal /persist/vendor/                                            
total 56
drwxrwxrwx  5 persist   persist   u:object_r:vendor_file:s0  4096 2017-08-03 22:27 .
drwxrwx--x 16 system    system    u:object_r:persist_file:s0 4096 2017-08-01 16:24 ..
drwxrwxrwx  2 profile   profile   u:object_r:vendor_file:s0  4096 2017-08-04 13:34 profile
drwxrwxrwx  2 provision provision u:object_r:vendor_file:s0  4096 2017-08-04 13:34 provisioning
drwxrwxrwx  2 updater   updater   u:object_r:vendor_file:s0  4096 2017-08-04 13:34 updater

我知道服務的查找規則正在運行，因為我能夠以強制模式啟動我的應用程序並且不會對此有任何抱怨。 我也能夠訪問有關persist_file：dir的規則所允許的{search}的/ persist目錄。

一旦我嘗試將/ persist / vendor / updater / test等新文件寫入/ persist目錄，我就會從auditd收到錯誤消息：

08-04 16:34:29.269  4108  4108 W .permissiontest: type=1400 audit(0.0:27): avc: denied { write } for name="updater" dev="mmcblk0p44" ino=55 scontext=u:r:vendor_app:s0:c512,c768 tcontext=u:object_r:vendor_file:s0 tclass=dir permissive=0

該錯誤當然由audit2allow轉換為以下規則：

#============= vendor_app ==============
allow vendor_app vendor_file:dir write;

由於write是create_dir_perms的成員，它實際上應該在那里。 我也嘗試將audit2allow創建的行添加到我的vendor.te中，但沒有成功。

請注意，寫入更新程序還涉及搜索 persist_file並搜索 vendor_file ，它們似乎都沒有任何問題。

有沒有人有任何建議，如何正確調試，甚至可能解決這個問題？ 我現在已經挖了兩天了，這讓我瘋了。

編輯：

啊。 / persist當然是可寫的：

# mount | grep persist
/dev/block/bootdevice/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nodelalloc,errors=panic,data=ordered)

編輯2：

正如Paul Ratazzi所問，我已經掃描了sepolicy文件以及實際加載到內核中的版本，以了解我的規則。

$ sesearch -A -s vendor_app -t vendor_file policy 
allow vendor_app vendor_file:dir { rename search setattr read lock create reparent getattr write ioctl rmdir remove_name open add_name };
allow vendor_app vendor_file:file { rename setattr read lock create getattr write ioctl unlink open append };

因此它們實際上已正確部署到設備上。

Answer 1

好吧，經過一些挖掘，看起來我終於找到了答案。 為了節省一些遇到同樣問題的人在一些腦力痛苦的日子，這里是解決方案：

除了Android上的MAC（強制訪問控制） SElinux還有MLS（多級安全） 。

雖然在Android SELinux概念中以某種方式描述了MAC，但有關MLS的信息僅在非常簡短和隱含地提到：

在SELinux中，標簽采用以下形式：user：role：type： mls_level ，其中類型是訪問決策的主要組件，可以由構成標簽的其他部分組件修改。

所以，我的Android應用程序運行在MLS級別（由c512，c768表示），可以讀取/ persist上的文件但不寫入它們。 所以需要發生的是我的應用程序獲得MLS級別以正確訪問這些文件。

我（現在）通過將我的自定義標簽更改為存檔來存檔

type vendor_app, domain, mlstrustedsubject;

這讓我的應用程序值得信賴 這解決了問題，但授予了我的應用程序的大量訪問權限。 因此，更好的選擇是將目標的安全級別置於允許對我的應用程序進行讀寫訪問的級別。

所以這基本上是迄今為止這個問題的解決方案（雖然還沒有完成）。