2017-08-04 140 views
4

我有一些麻煩讓自定義的selinux策略在基於AOSP的Android 7.1.2(更確切地說是基於索尼打開設備樹)上正常運行。我的自定義selinux政策似乎被Android系統忽略

我的問題是,審計日誌不斷告訴我有關我實際添加的缺少文件訪問規則。我還將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中文件的讀/寫訪問權限。要創建規則所必要的,我在設備目錄中增加了一個名爲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 

我知道找到 -rules的服務工作,因爲我可以開始我的應用程序在執行模式,並沒有得到有關任何投訴。根據關於persist_file:dir的規則,我也可以訪問{search}的/ 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; 

作爲寫入create_dir的成員_perms,它實際上應該在那裏。我也嘗試將audit2allow創建的行添加到我的vendor.te,但沒有取得任何成功。

請注意,寫入更新還涉及搜索 persist_file搜索 vendor_file這似乎都沒有任何問題的工作。

有沒有人有任何建議,如何正確調試或甚至解決這個問題?我一直在挖掘這兩天現在,這讓我瘋狂。

編輯:

啊。當然一直存在安裝/寫:

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

編輯2:

正如保羅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 }; 

因此,它們事實上部署到設備正確。

+0

如果還沒有,請嘗試從正在運行的設備中拉出'/ sepolicy',將其加載到'apol'中,然後檢查您的所有規則是否已被編譯到策略二進制文件中並按照您的預期顯示。這可能有助於縮小到構建vs.運行時問題。 –

+0

感謝您的暗示。事實上,apol確實(afaik)不適用於android的selinux策略,因爲谷歌正在使用setools不支持的定製版本(v30)策略文件。但他們提供了自己的工具來解析和搜索策略文件。這些工具表明規則存在於設備上。我將編輯帖子並將輸出放在那裏。 – nexus

回答

2

那麼,經過一些挖掘,看起來我終於找到了答案。爲了可能救一個人跑到相同的問題一些傷腦筋的日子,這裏是解決方案:

除了MAC (Mandatory Access Control) SElinux在android上也MLS (Multi-Level Security)

雖然MAC在Android SELinux concepts某種方式所描述的,關於MLS信息僅提及非常簡短和隱式:

在SELinux中,標籤的形式如下:用戶:角色:類型:mls_level,其中類型是訪問決策的主要組成部分,可由組成標籤的其他部分組件修改。

所以,我的Android應用運行在MLS級別(由c512,c768表示)可以讀取/保留但不寫入文件。所以需要發生的是我的應用獲得MLS級別以正確訪問這些文件。

我(現在)這個存檔通過改變我的自定義標籤

type vendor_app, domain, mlstrustedsubject; 

這讓我的應用程序的信任。這解決了這個問題,但授予了我的應用程序的大量訪問權限。因此,更好的選擇是將目標的安全級別降低到授予對我的應用程序的讀寫訪問權限的級別。

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