2733SEPAL：面向SEAndroid策略定制的大规模分析于东松1、 2、杨广良3、孟国柱1、2、龚晓瑞1、2、张秀1、 2、向晓波1、 2、王晓宇1、 2、蒋跃1、2、陈凯1、 2、邹伟1、 2、李文科3、石文昌41中国科学院信息工程研究所2中国科学院大学网络安全学院3美国佐治亚理工学院4中国人民大学{于冬松，孟国柱，龚希瑞，张秀，向晓波，王晓宇，江月，陈凯，邹伟}@iie.ac.cnguangliang.yang11@www.example.com，wenke. gmail.com，wenchang@ruc.edu.cngmail.com摘要如今，SEAndroid已被广泛部署在Android设备中，以执行安全策略并提供灵活的强制访问控制（MAC），以缩小攻击面并限制风险操作。一般来说，原始的SEAndroid安全策略规则是由Android社区精心编写和维护的。然而，在实际应用中，移动终端制造商往往需要自定义这些策略规则，并添加自己的新规则来满足其功能扩展，这破坏了SEAndroid的完整性，并导致严重的安全问题。然而，到目前为止，由于大量且不断增加的策略规则以及策略语义的复杂性，识别这些安全问题仍然是一项具有挑战性的任务为了研究SEAndroid策略定制的现状，提出了一种通用的策略规则自动检索和检查工具SEPAL应用NLP技术，并采用和训练一个广泛的深度模型，以快速准确地预测一个规则是否不受管制。我们的评估表明，SEPAL是有效的，实用的和可扩展的。我们验证了SEPAL优于最先进的方法（即，EASE-Andro I d）平均准确率为15%。在我们的实验中，SEPAL成功地从595,236条自定义规则（从72家制造商的774个Android固件映像中提取）中识别出7,111条不受监管的策略规则，误报率较低。我们进一步发现，策略定制问题在较新的Android版本中变得越来越严重（例如，Android 7约为8%，Android 9接近20%），尽管人们做出了越来越多的努力然后，我们进行了深入的研究，并讨论了为什么引入不受监管的规则，以及它们如何危害用户设备。最后，我们向七家供应商报告了一些不受监管的规则，到目前为止，其中四家证实了我们的发现。ACM参考格式：于冬松1、 2，杨广良3，孟国柱1、2，龚晓瑞1、2，张秀1、 2，向晓波1、 2，王晓宇1、 2，蒋跃1、 2，陈凯1、 2，本文在知识共享署名4.0国际（CC-BY 4.0）许可下发布。作者保留在其个人和公司网站上以适当的署名传播作品的权利WWW©2021 IW 3C 2（国际万维网大会委员会），在知识共享CC-BY 4.0许可下发布。ACM ISBN 978-1-4503-8312-7/21/04。https://doi.org/10.1145/3442381.3450007邹伟1、2、李文科3、石文昌4。2021年SEPAL：走向SEAndroid策略定制的大规模分析. 在网络会议2021（WWW '21）的会议记录，2021年4月19日至23日，斯洛文尼亚卢布尔雅那。 ACM， 纽 约 州 纽 约 市， 美 国 ， 12 页 。https://doi.org/10.1145/3442381.34500071介绍目前，SEAndroid（Security Enhanced Android）已被广泛应用于Android设备中，以缩小攻击面。自Android5以来，它已完全强制执行，截至2020年9月，它现在为超过98%的Android设备提供服务和保护[6]。SEAndroid源自SELinux（Linux内核中的一个有效的安全执行模块）[43]，它为敏感资源和操作提供了强大而灵活的强制访问控制（MAC）。SEAndroid的有效性通常由安全策略的正确性和完整性高度决定，安全策略是一组手动定义的条目，称为规则。通过完善的策略规则，SEAndroid可以轻松方便地限制系统服务，控制敏感数据访问，减少恶意应用的影响，并保护用户免受应用中潜在缺陷的影响。因此，在官方Android源代码中，即Android开源项目（AOSP）是一个坚实的基础政策，经过仔细定义和良好维护。这一基本策略为应用程序和系统服务提供了有效的保护，这在最近的一项研究中得到了反映和验证：Android 8中几乎50%的内核错误可以通过官方策略阻止然而，实际上，野外的Android设备通常由制造商定制。 为了确保自定义功能可以正常工作，他们需要在设备中添加特定于设备的规则。不幸的是，自定义策略可能会破坏SEAndroid提供的原始防御。例如，源策略严格限制了非特权进程对敏感设备节点的访问，因此大多数内核驱动程序漏洞无法被攻击者触发以提升特权。然而，一些设备中的定制规则打破了这一限制。例如，它允许一些不必要的进程访问MediaTek组件的易受攻击的驱动程序（称为CVE-2020-0069）[35]，这可能导致本地权限升级的攻击。为方便起见，本文将具有潜在风险或不必要的规则称之为不规范规则。* 孟国柱和龚晓瑞为通讯作者。2734WWWYu，G.Yang，G.孟，X.龚，X.Zhang，X.Xiang，X.Wang，Y.Jiang，K.陈威邹，W.Lee和W.石为了理解策略定制的现状，我们需要一种通用的方法来识别野生的不受管制的规则然而，这也是一项具有挑战性的任务。首先，Android碎片化问题极大地阻碍了政策分析。策略的表示在不同设备之间可能不同，导致相同语义的规则看起来不同（参见第2.2节）。其次，仅仅基于规则的静态表示很难获得足够的语义来评价目标规则的合理性。第三，没有明确的基础事实来判断一项规则是否是宽容的。决定在很大程度上依赖于专业知识，个案分析有时可能是主观的。即使我们可以编写一个脚本来查询基于先前研究总结的模式的未调节规则[18，36]，它也无法找到以前未知类别的未调节规则事实上，由于该策略已经发生了很大的变化，旧模式几乎不会出现在最新版本的Android中。为了应对这些挑战，本文提出了一种新的不受监管的策略检测解决方案，称为SEAndroid策略分析器（SEPAL），以自动审查大量的自定义规则。本研究的基本原理是通过基于学习的方法，根据AOSP中定义的坚实的政策规则，在不受监管和普通监管之间建立一个明确的边界。我们的目标是从统计学的角度突出数据集中的离群值，然后设法解释为什么它们被归类为不受监管，从而识别以前未知的不受监管规则的模式。特别是，该方案分三个阶段进行首先，给定固件映像，SEPAL检索所有规则，而不管策略格式和版本。为了解决规则的碎片化问题和统一规则的表达，SEPAL将不同表示形式的规则转换为统一的原子规则格式。 为了丰富原子规则中的语义，SEPAL然后生成信息特征来表示来自相应主体的策略属性和用户ID的原子规则。我们进一步设法从官方政策评论中提取一些由自然语言处理（NLP）生成的语义特征，以收集有关相应过程的特定领域知识。此外，我们使用从AOSP中收集的原子规则，通过机器学习来建模SEAndroid中主体和对象之间的复杂关联。 为了实现高准确性，我们丰富了原始的不平衡数据集，并使用一个与线性模型和深度神经网络（DNN）相结合的复合模型来学习官方策略中的特征组合，这是现代推荐系统的启发。它产生了一个分类器，以帮助我们突出大量的定制规则中的不规范规则我们还设计了一个基线算法的基础上，传统的机器学习方法进行比较，这是用于在SEAndroid的前期研究结果表明，SEPAL在我们的任务中表现得更准确。为了评估SEPAL的性能，我们从72家制造商的774个Android图像中收集了595，236条自定义规则。 SEPAL从这些图像中检索了近350万条原子规则。 通过将SEPAL应用于这些规则，我们发现超过12%的定制原子规则是不受管制的，这些规则来自制造商定义的7 ，111 个唯一策略规则。在我们的分析中，我们发现在Android7时代，事情有了很大的改善，因为谷歌付出了他们的努力，分解了一些粗糙的类型，在早期研究中提出的一些易出错属性的使用[18，36]。然而，现在情况似乎越来越糟-Android9中的百分比已经上升到17.76%。我们发现，即使是三星和华为这样的知名制造商也很难跟上官方政策的演变，更不用说其他规模较小的制造商了。基于SEPAL的结果，我们进一步对这些不受监管的规则进行了深入的分析我们总结了四个以前未知的原因，为什么这些规则被引入，如滥用的属性，调试相关的规则，弃用的规则，并授予不受信任的域过多的权限。此外，为了演示规则如何降低官方SEAndroid的防御能力，我们展示了这些不受监管的规则的安全影响，包括暴露系统服务和敏感设备节点，扩展恶意应用程序的功能，并为漏洞利用提供额外的路径。为了说明安全影响，我们还进行了一个案例研究的攻击，其中：1）我们控制设备的屏幕锁定密码，2）与相机通信，而无需许可请求，这是由相应的供应商承认。 我们已经就这些问题联系了七家供应商，其中四家证实了我们的调查结果。 据我们所知，这是第一次对策略定制进行如此大规模的测量。 我们希望我们的研究结果可以帮助制造商改善他们的政策写作。本文的主要贡献如下：新技术。我们提出了一个通用的方法，SEPAL，克服了大规模定制规则的自动分析的挑战。SEPAL以细粒度的格式化并利用NLP技术和深度学习来有效地检测不受监管的规则。它有助于在策略定制中全面、可扩展地发现安全问题新发现。SEPAL从70家制造商收集的350万条原子规则中识别出7，111条独特的不受监管的规则。然后，我们对跨版本和供应商的策略定制进行大规模测量。 我们揭示了一些重要的见解，包括为什么这些规则是不受管制的，以及它们可能造成的安全影响。2背景2.1SEAndroid概述SEAndroid Concepts. 为了通过实施强制访问控制（MAC）来增强安全性，Smalley 等人。为Android 定制的SELinux ，即SEAndroid [43]，由Google在An-droid 4.3中移植，并自Android 5起全面实施。传统的MAC包含多种安全机制：基于角色的访问控制（RBAC）[38]，多级安全（MLS）[30]和类型加密（TE）[17] 。因此，所有受试者（例如，过程）和对象（例如，SEAndroid中涉及的文件、套接字）从这些机制中继承安全标签，格式为“user：role：ty pe：securitylevel“。字段user和role主要用于RBAC，在SEAndroid中很少使用，也没有用于MLS的字段安全级别SEAndroid的访问控制主要是通过TE来实现的，TE使用类型字段通过大量的类型强制规则来限制系统··SEPAL：面向SEAndroid策略定制WWW2735一般来说，类型强制规则（缩写为rule）符合“allowdomaintype：classpermission“，它定义了系统中主体的可允许操作。特别地，域字段指定主题的标签（例如，过程），类型指示对象的标签（例如，文件和套接字），类是对象的类，权限表示对对象执行的特定操作。例如，规则“allow untrusted_app app_data_file：file {open read};”允许标 记 为 “untrusted_app” 的 所 有 进 程 打 开 并 读 取 标 记 为“app_data_file”的普通文件。 所有规则都是由系统开发人员编写的，并保存在源代码树中的 *.te文件中。为了正确有效地编写和管理这些规则，SEAndroid中定义的大多数类型都有几个属性。例如，untrusted_app具有多个属性，包括do- main、appdomain和netdomain，分别指示不可信app是进程、app进程和具有网络访问的进程。由属性定义的规则对于具有该属性的所有主体或对象都有效。策略编写者还可以使用宏来提供可重用的语句片段 例如，rw_file_perms是一个代表权限列 表 的 宏 -getattr open read ioctl lock map append write ，binder_use（domain）可以在目标域的单行中生成与Binder IPC使用相关的所有规则。此外，在SEAndroid的源代码树中有两种类型的命令式规则-允许规则和从不允许规则。 neverallow规则不会被编译到设备中，但当存在违反neverallow条目的允许规则时，它将中断编译。 这些规则主要用于避免引入不规范的规则。这些允许 *.te文件中的规则最终编译成固件映像，并在系统启动时初始化。SEAndroid将拒绝策略中未明确允许的所有访问尝试，即使进程以root身份运行：$iduid=0（root）gid=0（root）groups=. context=u：r：untrusted_app：s0：c512，c768$ls/ls：/：Permission denied$logcat| grep avc11-06 06：41：49.193 2810 2810 W ls：type=1400 audit（0.0：19）：avc：denied{read}for name="/”dev=“sda43”ino=2 scontext=u：r：untrusted_app：s0：c512，c768tcontext=u：object_r：rootfs：s0 tclass=dir permissive=02.2政策多样性从以下角度来看，政策规则可能会有很大版本多样性。 SELinux版本和SEAndroid版本都用于指示策略的状态。从SELinux版本的角度来看，当新的语法特性添加到策略中时，它会发生变化这可能会导致策略语法以及二进制策略中的文件结构发生变化例如，Android 5使用26.0的SELinux版本，而Android 6使用30.0，这导致了一些宏和保留字的变化。从SEAndroid版本的角度来看，它与Android的版本同步它表示随着操作系统的发展策略的变化例如，在27版之前的SEAndroid策略规则中，所有进程都可以通过直接打开字符device：“allow domain ashillary_device ： chr_file rw_file_perms”来 访 问ashillary设备。然而，在Android 9和SEAndroid 28上，进程必须使用本地API来相同目的，并且这样的规则被修改为“允许域ash-缓存_设备：chr_filegetattrreadioctllockappendwrite”。 因此，在Android9中，从普通用户级进程打开/dev中的ashcodedevice将被拒绝。事实上，随着Android版本的发展，官方政策通常会发生很大变化政策形式多样。 不同文件格式的策略在呈现方式上有所不同。以下不同策略文件中的代码片段显示了如何以不同的样式表示一个规则。#TE style：allow{ appdomain -isolated_app } app_data_file：file r_file_perms#CIL style：allowbase_typeattr_97 app_data_file（file（getattr open read ioctl lock map））#Binary style：allowbluetooth app_data_file：file getattr open read ioctl lock map;allowplatform_app app_data_file：getattr open read ioctl lock map;allowuntrusted_app app_data_file：file getattr open read ioctl lock map;.AOSP中的规则保存在按域分类的*.te文件它们大多用宏、属性和逻辑符号（如“*”表示所有，“-”表示异常）编写，而设备中内置的二进制策略可以通过setools[11]解压缩源代码中属性定义的相应规则在setools的解压缩结果中可以表示为多个条目。这意味着二进制策略和源代码策略之间的规则粒度可能不同此外，neverallow规则不会编译到二进制策略中。随着Android8.0中Project Treble [8]的引入，一种名为通用中间语言（CIL）的新策略格式被用作 *.te策略文件和二进制策略文件之间的中间表示-除了编译的二进制策略，设备还包含多个编译的CIL文件。 CIL文件中定义的规则保持源代码（*.te文件）中定义的allow和neverallow规则的顺序和形状。因此，CIL文件包含的信息比使用setools从二进制策略中获得的信息多得多。例如，上面提到的属性base_typeattr_97被分配给除了isolated_app之外的所有应用级别类型，isolated_app保留了否定表达式的形状。政策多义性。由于属性定义的自定义，*.te或二进制策略文件中具有相同语法的规则在不同的设备中可能具有不同的含义。例如，属性hal_audio的定义在Pixel设备和某些第三方设备之间可能不同，导 致 以 下 规 则 可 能 具 有 不 同 的 含 义 ： “allow hal_audioaudio_device：chr_file ioctl“这样的规则在AOSP中是合理的，但在某些第 三方设备中，属性 hal_audio被额外分配 给域hal_ir_default和域hal_irsi_default。这两个域主要分配给与红外相关的服务器进程。它将授予比原始规则更多的权限（如第6.2节所示）。3问题陈述在这一部分中，我们提出了本文要解决的问题策略的定制可能会给SEAndroid设备带来严重的安全风险和破坏性影响。图1显示了一个说明性示例，说明由于对原始策略的不正确添加，可能会利用一个漏洞具体而言，在联发科（MTK）存储的驱动程序中发现了越界访问漏洞（CVE-2015-6637）。驱动程序公开一个设备节点/dev/misc-sd由misc_sd_device标记，并由原始策略控制，其中只有vold域可以访问易受攻击的进程WWWD. Yu，G.Yang，G.孟，X.龚，X.Zhang，X.Xiang，X.Wang，Y.Jiang，K.陈威邹，W.Lee和W.石2736（D、T、C、P）DC（）∈ {}⟨⟩中国（）∈ {}中国（ ）（）∈ ∈D∈ T ∈ C ∈P呼叫用户空间利用射电过程MTK上下文/dev/misc-sd呼叫@EngineerModeServer连接无线电3.允许无线电em_svr {connectto}2.允许em_svr misc_sd_device {ioctl read open}em_svr1. ALLOW vold misc_sd_device {ioctl read open}杂项sd装置沃尔德法voldSELinux上下文图1：定制（第1条）。因此，在强制执行SEAndroid时，非特权进程无法以这种方式利用此漏洞。然而，一些MTK设备编写了两个自定义规则（规则2和规则3），使另一条路径能够到达漏洞点。因此，用户空间攻击可以与进程“radio”交互，连接到em_svr守护程序，随后触发内核中的漏洞。由于兼容性问题和策略验证不足，供应商倾向于编写这些不必要或有风险的规则，这些规则扩大了攻击面，可以被恶意软件进一步利用[31，32]。为了简单而准确地说明这个问题，我们为这些策略规则提供了一个正式的定义，然后讨论违反。定义1（SEAndroid策略规则）Android中的策略规则可以表示为一个六元组（Op，D，T，C，P，Attr），其中Op表示allow或neverallow，D是域的集合，T是组件类型的集合，P表示所有预定义的权限，Attr是域D或类型T的子集。因此，AttrDaught。4方法图2显示了SEPAL的工作流程，我们描述了三个组件，即、原子规则收集、特征提取和基于广度&和深度的分类一起工作，以识别本节中制造商图像中的未规范规则。4.1原子规则集合考虑到策略文件格式和策略粒度的多样性，首先将AOSP和固件映像中不同文件格式的规则表示为原子形式。我们开发了一个通用的解析器来获取元数据，即。从AOSP中的策略文件和固件映像中提取六个元组Op、Attr，然后将元数据转换为原子规则。对于来自不同版本的man-ufacturer映像中的策略规则，我们只需要allow规则。因此，我们可以直接从二进制策略文件或CIL文件中提取原始策略规则现有的工具，如[4，13]，可用于固件提取根据这些图像是如何打包的。Android 8之后的策略规则保存在CIL文件中，并分别位于系统和供应商分区在合并这些CIL文件后，提取元组是很简单的在Android的早期版本中，二进制策略文件被打包在引导映像的解析器使用setools反编译二进制策略，并检索二进制策略中的allow规则和属性我 们还 需 要 AOSP 规 则来 进 行模 型 训练 。 它 额外 要 求neverallow规则作为负数据记录，因此我们不能使用二进制策略，因为neverallow规则永远不会编译成二进制。因此，在AOSP中直接解析*.te文件是很麻烦的，因为它们是用复杂的宏和逻辑符号编写的，并且这些规则的语法也可能随着时间的推移而演变。直观地说，规则可以表示为r = dop，d|属性，t |attr，c，{pi}版本。因此，我们使用CIL文件来构建训练其中OP执行部分d得双曲余切值.，c，pi.此外，attr指的是一组域或类型。虽然attr可以简化策略编写，但由于策略的多样性，它增加了策略验证和分析的难度（第2.2节）。 为此，我们提出了“原子规则”作为新的度量表示策略规则。这里的基本原理是，我们注意到属性的定义可能因设备而异，但指定的类型保持稳定。具体地，原子规则可以定义为：定义2（原子规则）它是策略规则的具体实例，可以表示为ra=d，t，c，p。设是一个权限标识符，其中是allow，never是allow。此规则仅指定某个域对单个目标的一种允许或禁止的行为。所以它是不可约的，也就是说，不能进一步分解成更细粒度的规则。为了识别制造商定制化带来的安全风险并了解它们是如何引入的，我们打算了解AOSP策略中定义的类型的允许和禁止的相关性的边界，并确定定制规则与这些相关性之间的冲突。 正式地说，该研究旨在生成一个输出由原子规则给出的allow或neverallow权限的命令，即允许，永远不允许。因此，一次违反即，不受管制的规则）被发现，如果rara。此外，SEPAL强调的波动不仅可以帮助我们识别以前未知的模式，而且可以更好地理解如何摆脱不受监管的规则的引入数据集。此外，CIL文件几乎保留了*.te中定义的所有语义，因此可以用来丰富我们的初始数据集（见4.3节）。 但CIL文件仅在 Android 8 之 后 可 用 。 对 于 以 前 的版 本 ， 我 们 修 改 了checkpolicy [3]，一个开源的te编译器，以添加兼容性支持，从早期的AOSP源代码编译CIL文件。然后可以很容易地从CIL策略文件中检索在从AOSP和固件映像中获得元组后，我们递归地扩展由这些属性定义的所有主体和对象，直到所有属性在规则中被替换。 然后，我们将权限分开，以获得原子规则。4.2特征提取为了更好地表示原子规则中元素之间的语义，我们从这些规则中提取了三种类型的特征F1原子规则的基本语义。策略中出现的每个主体、对象、类和权限都将在one-hot编码后直接映射到向量空间。此外，一些属性可以直观地表征规则中的类型，但它们在将原始规则分解为原子规则的过程中被忽略。具体来说，以下属性表示为六个布尔特征：domain表示主体是否是进程，MLS表示进程是否可以覆盖多级安全限制，core表示类型是否由平台定义，app表示主体是否是app进程，net表示主体是否可以访问（SEPAL：面向SEAndroid策略定制WWW2737∈∈AOSP政策OEMROMs原子规则1.原子规则收集属性特征提取用户ID特征提取基于NLP的特征提取2. 甘草提取物3. 基于深度的分类图2：SEP AL网络，而untrusted指示不受信任的代码是否可以在进程上下文中执行。NLPWordNet允许F2正在运行的进程的用户ID 用户ID（UID）表示进程的特权级别。 从正在运行的设备获取UID是很简单的。 先前的研究[18]直接使用“adbshellps-Z“通过adb连接从根设备收集此信息，这在大规模分析中是不可行的。为此，我们开发了一种静态方法来关联策略中的用户ID和类型，SELinuxWiki*.te inAOSP名词和动词SELinux语料库依存关系树关键词永不允许运行时环境。应用程序相关主题的UID对于图3：规则注释矢量化的工作流程获取-名为seapp_context的文件指示所有用户帐户这些科目。 对于系统守护进程，推断其UID需要保存在系统中的file_context、init脚本文件 *.rc和策略中的typetransition条目中的相关信息。 以类型mediadrmserver为例。要获取其用户帐户，首先 我 们 查 找 策 略 文 件 并 获 取 条 目 “typetrition initmediadrmserver_exec process mediadrmserver“，该条目显示当执行mediadrmserver_exec 标 记 的 文 件 时 ， init 类 型 将 转 换 为mediadrmserver。然后file_context显示类型mediadrmserver_exec只分配给/system/bin/mediadrmserver。最后，在mediadrmserver.rc中发现了以下条目：服务mediadrm /system/bin/mediadrmserver.用户媒体.它的结论是标记为mediadrmserver的mediadrm作为媒体运行。F3规则注释。 有时，类似的操作可能会用不同的类或权限来表示。以文件hal_wifi.te和app.te中定义的规则为例。算法1：在句子中找到关键字三元组输入：dt：句子的依赖树输出：kt：关键字三元组1v.getV0（dt）;2 对于v动词可以3如果InAcT I onCorPU s（v），则4act<$v;resources<$ getOB js（v）;5forres∈resourcesdo6comp←getComp（res）;tr={act，res，comp};7如果trgkt，则8kt←kt （b）秘书长;9 为obj物体如果InResoU rceCorPU s（obj），则11res←obj;comp← getComp（obj）;12act←getPredI cA te（obj）;tr={act，res，comp};13如果trgkt，则14kt←kt （b）秘书长;15 returnint;从评论来看，应用程序和hal_wifi都可以将转储信息发送到dumpstate，即使它们使用不同的IPC通道。为了表征主题之间的这些潜在相关性，我们需要解析和向量化相应类型的评论文本。然而，注释通常是任意编写的，其中一些注释甚至与规则的语义几乎没有关系，例如bug ID或相应的shell命令。考虑到我们所关注的评论本质上定义了主题的动作及其可以访问的资源，我们设法从评论中提取关于谁做了什么的关键字，并通过NLP技术将它们表示为向量。图3显示了我们如何将主题的评论表示为两个向量（即，allow和neverallow向量）。首先，我们从SELinux Wiki页面收集了一个与策略相关的语料库[10]。 基于SEAndroid使用的对象类和权限的定义，我们提取所有的动词（例如，，开放，阅读）和一般资源（例如，、文件、套接字）与访问事件相关。然后我们使用WordNet [34]来获取这些动词的同义词以丰富语料库。最后，我们获得了515个动词和49个资源，该语料库可以帮助识别与访问事件相关的句子，并过滤评论中的无关词但由于英语的多义性，单纯使用关键词搜索容易产生误报。因此，我们执行依存分析，以获得词然后，我们实现了一个关键字三元组提取器的基础上发现的原则，在自然语言处理，它采取上述依存树作为输入，并提取主谓宾从一个句子。算法1描述了我们如何提取关键字三元组。具体地说，每个句子表示为一个依赖树后，分词和词形化。然后我们检索动词和宾语AOSP部件原子规则向量不受管制的规则OEM部件冗余移除宽深模型基于否定的数据补充看情况解析关键字三元组提取doc2vec........==#允许hal_wifi将转储信息发送到dumpstate：允许hal_wifi dumpstate：fifo_file write;===#允许应用将转储信息发送到dumpstate：允许appdomain dumpstate：fd使用;allowappdomain dumpstate：unix_stream_socket {read write getopt getattr};WWWD. Yu，G.Yang，G.孟，X.龚，X.Zhang，X.Xiang，X.Wang，Y.Jiang，K.陈威邹，W.Lee和W.石2738根据这些词的依存信息和词性标记，在句子中提取SVO，这类似于NLP中获取SVO的过程[5，9 如果这些词在我们的语料库中，我们将把它们以及它们在依存关系树中的补语添加到我们的关键字集中。以前面提到的句子首先，函数getVO从句子的依赖树中提取包 括 “allow apps” 和 “send information” 的 短 语 。 但 是 动 词“allow”和宾语“apps”都不在我们的语料库中，通过第3行的InResourceCorpus函数和第11行的InResourceCorpus函数所以它们将被解析器驳回一方面，动词“send”在我们的语料库中是一个常见的动作，因此我们可以分别通过第4行的getObjs和第6行的getComp函数另一方面，由于“information”在我们的资源语料库中，第11行的函数getComp和第12行的函数请注意，我们不提取一个句子的主语，因为它经常在政策评论中被省略但是，我们可以通过文档文件名确定主题最后，一个*.te文件中的所有注释将由两组关键字三元组表示：一组来自allow规则的注释，另一组来自neverallow规则的注释。 最后，每个关键字三元组都被视为相应“文档”（它所定位的 *.te文件）中的规范化句子。 我们使用doc2vec [33]将这些注释嵌入到两个300维向量中进行模型训练。4.3宽深度分类在本节中，我们将描述如何增强数据以解决数据不平衡问题以及如何训练模型数据扩充。 在从AOSP中获取原子规则后，我们注意到允许规则和从不允许规则的比例非常不平衡，这可能会使模型产生偏差。例如，Android 8中95.4%的原子规则是neverallow。这是因为大多数allow规则指定了细粒度的域，而neveral-low规则通常引用大量的域，因此只有特权域可以访问敏感数据。为了构造具有平衡标签的训练数据集，我们设法提供一些基于CIL文件中的否 定 的 附 加 原 子 规 则 具体来 说 ， CIL 引 入 了一 组 前缀为base_typeattr的属性。这些属性是AOSP中定义的属性的子集例 如 ， base_typeattr_293 通 过 条 目 “typeattributesetbase_typeattr_293 （ and （ appdomain ） not （ shellcon_monitor_app））“分配给除shell和con_monitor_app类型之外的所有具有属性appdomain的类型因此，从base_typeattr定义 的 那 些 neverallow 规 则 中 ， 我 们 可 以 推 断 出 除 了 被base_typeattr排除的主体之外，哪些主体不能执行这种行为。base_typeattr_293不允许访问标记为con_monitor_app的文件，这暗示shell和con_monitor_app都可以访问此类文件。类似地，额外的原子允许规则可以从neverallow规则中的否定语句中推断出来这些从否定中推断出的原子规则可以极大地丰富我们的训练数据集。此外，通过限制“推断”原子规则的数量，我们可以调整训练数据集中标记数据的比例。去除红细胞。只有图像中的自定义规则将被考虑用于进一步分类。因此，我们执行比较以获得定制部件。注意原子规则的表示可以帮助我们精确地找到制造商定义的规则，而不管设备之间的属性的差异。最后，从超过4000万个原子规则中获得由制造商添加的350万个原子规则，总共产生267，162个唯一原子规则。宽深模型。 在获得原子规则后，我们联合训练了一个宽线性模型和一个深度神经网络来分类一个规则是否是不规则的。考虑到Android策略的重大演变，我们为每个Android版本分别训练一个模型从原子规则中的基本语义和用户ID（即，、F1和F2）被编码成独热表示。它们用于训练Logistic Regression（LR）分类器，即模型的“宽”部分。此外，某些功能在组合后可能会更好地工作例如，class字段指示对象的类，它也限制权限字段。 将这些字段交叉在一起使宽模型能够将它们视为合成特征，并学习它们的每个组合的权重。然而，这样的线性模型不够精确，因为这些特征是离散的，并且非常稀疏-在SEAndroid策略中，只有少量的类型是相 关 的 。 大多数 类 型 在策略中既 不 与 allow 关联，也 不 与neverallow关联。这使得传统的机器学习算法在对以前看不见的主体-对象对进行分类时效率低下，因为它们只能记住训练集中出现的特征组合。此外，一些规则可能具有间接连接性，导致我们在特征选择中可能不可避免地错过一些不显眼但信息丰富的特征。为了解决这些问题，我们进一步将特征表示为低维密集嵌入向量，然后使用深度神经网络（DNN）来学习看不见的特征组合之间的关系。 这个想法的灵感来自于现代推荐系统所采用的模型，在该模型中，用户与大多数项目不相关，而只显示他对大型数据集中有限数量项目的偏好或不喜欢。最近的研究[19，22]通过联合使用线性模型（例如，、LR或支持向量机），用于学习训练数据集中特征组合的频繁共现，以及深度模型（例如，DNN），用于基于相关性的传递性来探索新的特征组合这种结构已经证明了它在现实世界的点击率（CTR）预测任务中的有效性，例如在Google Play中为用户推荐应用程序。它根据用户配置文件预测用户的偏好。同样，我们也可以根据物体的特征来预测受试者对物体的“偏好”。DNN分类器通常将数据的嵌入表示作为输入。我们通过嵌入将独热编码特征F1映射到稠密向量空间中，并将它们与策略评论特征（F3）的嵌入表示然后我们使用四个完全连接的层来将这些嵌入作为输入。最后，深度模型与线性模型共享相同的输出单元，从而产生原子规则的最终分类结果分类模型和输入特征的详细信息可在我们的网站上找到[7]。当训练完成时，这些模型将接收向量化的制造商原子规则ra并输出分类结果DC（ra）。如果DC（ra）不包括（ra），则ra将被突出显示为不受管制的ra。SEPAL：面向SEAndroid策略定制WWW2739⟨⟩（）（）（）（）（）（）Android 9百分之二安卓8安卓537%33%Android 7Android 6百分之八百分之二十200150100500表1：SEPAL和EASEAndroid的性能指标Android版本评估数据集SEPAL# 阳性# 负精度精度召回精度精度召回# （of Uncla）ssifieDAndroid 51943873750.9860.9900.9910.8950.9660.893742人（2.77%）Android 6795688930.9900.9690.9730.7900.6330.7471 320人（7.83%）Android 7144382761
我的内容管理
展开
