【GTS-Fail】GtsSecurityHostTestCases#testNoExemptionsForSocketsBetweenCoreAndVendorBan

【GTS-Fail】GtsSecurityHostTestCases#testNoExemptionsForSocketsBetweenCoreAndVendorBan

【問題描述】

Gts-7.0-r4工具報出失敗項
GtsSecurityHostTestCases
com.google.android.security.gts.SELinuxHostTest#testNoExemptionsForSocketsBetweenCoreAndVendorBan

<Failure message="junit.framework.AssertionFailedError: Policy exempts domains from ban on socket communications between core and vendor: [hal_audio_default]">
    <StackTrace>junit.framework.AssertionFailedError: Policy exempts domains from ban on socket communications between core and vendor: [hal_audio_default]
    at junit.framework.Assert.fail(Assert.java:57)
    at junit.framework.TestCase.fail(TestCase.java:227)
    at com.google.android.security.gts.SELinuxHostTest.testNoExemptionsForSocketsBetweenCoreAndVendorBan(SELinuxHostTest.java:221)

這裏有個坑，報問題的時候說上個版本有，其實最終查證0004版本（2.20前）就有這個失敗項了，當時芯片廠商也告知是waiver項了。。。

【問題結論】

是waiver項
失敗項是由google的auto-patch代碼致使，若是第一次遇到能夠諮詢aml是否waiver。

AuthBlog：秋城https://www.cnblogs.com/houser0323

【分析詳細】

測試邏輯總覽
使用linux可執行程序：sepolicy-analyze，對機頂盒中的/sys/fs/selinux/policy文件進行解析，要求不能有返回值，命令是：
sepolicy-analyze policy attribute socket_between_core_and_vendor_violators
即：不容許有type（類型）與該attribute（屬性）「socket_between_core_and_vendor_violators」有關聯，字面意思：core與vendor的違規socket特權

system/sepolicy/tools/sepolicy-analyze/README

ATTRIBUTE (attribute)
sepolicy-analyze out/target/product/ /root/sepolicy attribute
Displays the types associated with the specified attribute name.

該權限詳細限制在如下代碼中有論述，Android TREBLE架構解耦計劃相關
system/sepolicy/prebuilts/api/26.0/public/domain.te
system/sepolicy/prebuilts/api/27.0/public/domain.te
system/sepolicy/prebuilts/api/28.0/public/domain.te:
system/sepolicy/public/domain.te

# On full TREBLE devices, socket communications between core components and vendor components are
# not permitted.
full_treble_only(`
  # Most general rules first, more specific rules below.

  # Core domains are not permitted to initiate communications to vendor domain sockets.
  # We are not restricting the use of already established sockets because it is fine for a process
  # to obtain an already established socket via some public/official/stable API and then exchange
  # data with its peer over that socket. The wire format in this scenario is dicatated by the API
  # and thus does not break the core-vendor separation.

梳理測試項邏輯
反編譯後定位測試項
./com/google/android/security/gts/SELinuxHostTest.java

public void testNoExemptionsForVendorExecutingCore() throws Exception {
        if (isFullTrebleDevice()) {
            Set<String> types = sepolicyAnalyzeGetTypesAssociatedWithAttribute("vendor_executes_system_violators");//該語句是測試判斷，返回測試結果  
            if (!types.isEmpty()) {
                List<String> sortedTypes = new ArrayList(types);
                Collections.sort(sortedTypes);
                fail("Policy exempts vendor domains from ban on executing files in /system: " + sortedTypes);//此處assert，緣由是容器types有東西，東西就是‘[hal_audio_default]’  
            }
        }
    }

看一下方法的測試邏輯：sepolicyAnalyzeGetTypesAssociatedWithAttribute()
經過ProcessBuilder開啓一個進程，用於執行linux命令：sepolicy-analyze policy attribute socket_between_core_and_vendor_violators
而後獲取這個命令的標準輸出進行結果判斷

private Set<String> sepolicyAnalyzeGetTypesAssociatedWithAttribute(String attribute) throws Exception {
        BufferedReader in;
        Throwable th;
        Throwable th2;
        Set<String> types = new HashSet();
        //經過ProcessBuilder開啓一個進程，用於執行linux命令：sepolicy-analyze policy attribute socket_between_core_and_vendor_violators  
        ProcessBuilder pb = new ProcessBuilder(new String[]{this.mSepolicyAnalyze.getAbsolutePath(), this.mDevicePolicyFile.getAbsolutePath(), "attribute", attribute});
......
            in = new BufferedReader(new InputStreamReader(p.getInputStream()));
            th = null;
            while (true) {
                try {
                    String type = in.readLine();
                    if (type != null) {
                        types.add(type.trim());//獲取有效標準輸出，寫到結果容器中存儲  
                    }}} 
......
        return types;
......
    }

如今基本邏輯就清楚了，只要這個命令執行有結果返回就是不被容許的，如今須要分析這個工具‘sepolicy-analyze’是幹嗎的？
在Android工程源碼中搜索，咱們找到了這個host可執行程序的源碼
system/sepolicy/tools/sepolicy-analyze/
結合網絡資料以及閱讀源碼和README文檔，澄清測試的命令用途：解析policy文件返回與attribute相關聯的type值

system/sepolicy/tools/sepolicy-analyze/README

63 ATTRIBUTE (attribute)
64 sepolicy-analyze out/target/product/ /root/sepolicy attribute
65
66 Displays the types associated with the specified attribute name.

工程中搜索確認
搜過確認一下到底在哪裏使得他們關聯的,定位到一下te文件

./system/sepolicy/vendor/hal_audio_default.te:1
type hal_audio_default, domain, socket_between_core_and_vendor_violators;

查證git log，咱們發現是以下的commit致使的，是google的auto-path

commit 783f5b52195f0168f4c9db29b5a80ac63fb04020
Author: xxxxxx
Date:   Mon Feb 17 11:33:16 2020 +0800

    auto patch added:CecAudio

diff --git a/vendor/hal_audio_default.te b/vendor/hal_audio_default.te
index 0dc2170..9da0f1b 100644
--- a/vendor/hal_audio_default.te
+++ b/vendor/hal_audio_default.te
@@ -1,4 +1,4 @@
-type hal_audio_default, domain;
+type hal_audio_default, domain, socket_between_core_and_vendor_violators; #此處添加的關聯，問題找到了根源  
 hal_server_domain(hal_audio_default, hal_audio)

到此，問題很大機率可確認爲Google-waiver，由於引入問題的代碼是Google的。接下來需向芯片廠商或Google溝通確認

因爲報問題的烏龍，事實是該問題好久以前已澄清過，因此這一通分析並木有什麼卵用。。。。。。