第26章：Android虚拟化技术

Android虚拟化技术是系统安全和功能隔离的基石。从早期简单的UID隔离到现代复杂的容器化架构，Android在虚拟化道路上不断演进。本章将深入剖析Android虚拟化技术栈，包括容器化应用、多用户系统、工作资料机制以及相关的安全增强措施。通过与iOS等系统的对比，我们将全面理解Android虚拟化的设计理念和实现细节。

26.1 容器化技术应用

26.1.1 Android容器化基础架构

Android的容器化技术建立在Linux内核的Namespace和Cgroup机制之上，但针对移动场景做了大量优化和定制。与传统服务器容器化不同，Android需要在有限的硬件资源下实现高效的应用隔离，同时保持良好的用户体验。

Namespace隔离层次：

• PID Namespace：每个应用拥有独立的进程空间，pid 1在应用内部视角是其主进程
• Mount Namespace：隔离文件系统视图，实现私有存储和动态权限
• Network Namespace：网络栈隔离，主要用于VPN和网络调试场景
• User Namespace：UID/GID映射（Android 10+），增强权限隔离
• UTS Namespace：主机名隔离，较少使用但提供完整性
• IPC Namespace：SystemV IPC隔离，防止共享内存滥用

Android通过clone()系统调用的CLONE_NEW*标志创建新的namespace，具体实现在frameworks/base/core/jni/com_android_internal_os_Zygote.cpp：

• Zygote fork时设置CLONE_NEWNS实现挂载隔离
• VPN应用通过CLONE_NEWNET创建独立网络栈
• 隔离进程使用CLONE_NEWPID完全隔离进程视图
• WebView渲染进程额外使用CLONE_NEWIPC

Namespace创建时机：

应用启动流程中的Namespace设置：

1. Zygote收到启动请求（通过socket）
2. 调用forkAndSpecialize()
3. 设置namespace标志位
4. clone()创建新进程
5. 在子进程中设置UID/GID
6. 执行应用代码

Cgroup资源控制： Android使用Cgroup v1进行资源管理，在init.rc中配置：

• cpu：CPU时间片分配，支持前台/后台差异化
• cpuset：CPU亲和性设置，大小核调度优化
• memory：内存限制和统计，配合LMK/LMKD
• blkio：块设备I/O限制，应用存储配额
• freezer：进程冻结/解冻，Doze模式实现

关键cgroup路径和配置：

• /dev/cpuctl/：CPU控制组
• tasks：进程列表
• cpu.shares：CPU份额（默认1024）
• cpu.rt_runtime_us：实时调度时间
• /dev/cpuset/：CPU集合控制
• foreground/cpus：前台应用CPU集合
• background/cpus：后台应用CPU集合
• system-background/cpus：系统后台CPU集合
• /dev/memcg/：内存控制组
• memory.limit_in_bytes：内存上限
• memory.soft_limit_in_bytes：软限制
• memory.swappiness：交换倾向
• /dev/blkio/：块I/O控制
• blkio.weight：I/O权重（100-1000）
• blkio.throttle.read_bps_device：读取限速

Cgroup层次结构： Android定义了多个cgroup组，通过libprocessgroup管理：

• /: 根cgroup
• /foreground: 前台应用组
• /background: 后台应用组
• /system-background: 系统后台服务
• /top-app: 当前活跃应用（Android 10+）
• /restricted: 受限应用组（Android 11+）

性能调优配置： system/core/libprocessgroup/profiles/task_profiles.json定义了任务配置文件：

• HighPerformance：性能模式，大核运行
• PowerEfficient：省电模式，小核运行
• SystemBackground：系统后台，限制资源
• ProcessCapacityHigh：高处理能力
• ProcessCapacityLow：低处理能力

通过SetTaskProfiles()和SetProcessProfiles() API应用这些配置。

26.1.2 App沙箱与进程隔离机制

Android的应用沙箱是其安全模型的核心，每个应用运行在独立的Linux用户下。这种设计利用了Linux的DAC（Discretionary Access Control）机制，并通过额外的安全层进行增强。

UID分配机制：

• 应用UID范围：10000-19999（AID_APP_START到AID_APP_END）
• 普通应用：动态分配，安装时确定
• 共享UID：相同签名应用可共享（已废弃）
• 隔离进程UID：99000-99999（AID_ISOLATED_START到AID_ISOLATED_END）
• WebView渲染进程
• 媒体提取服务
• 其他高风险操作
• 系统UID：1000-9999（预定义系统服务）
• system(1000)：系统服务器
• radio(1001)：电话相关
• bluetooth(1002)：蓝牙服务
• graphics(1003)：图形系统
• input(1004)：输入系统

UID分配实现： PackageManagerService在应用安装时分配UID：

流程：

1. 检查是否为更新安装（保持原UID）
2. 查找共享UID（如果声明）
3. 从mFirstAvailableUid开始分配新UID
4. 更新packages.xml持久化

文件系统隔离：

• 私有数据目录：/data/data/<package_name>/
• files/：getFilesDir()返回
• databases/：SQLite数据库
• shared_prefs/：SharedPreferences
• cache/：getCacheDir()返回
• code_cache/：JIT代码缓存
• 外部存储隔离：/storage/emulated/<userId>/<package_name>/
• Android 10起的分区存储（Scoped Storage）
• MediaStore API访问共享媒体
• SAF（Storage Access Framework）授权访问
• OBB挂载点：/mnt/obb/<package_name>/
• 扩展文件存储
• FUSE文件系统实现
• 应用专属目录权限：
• 内部存储：700（仅所有者）
• 外部存储：基于FUSE动态控制

进程隔离增强：

• Seccomp-BPF：限制系统调用
• 白名单模式：仅允许必要调用
• 架构相关过滤：arm64/arm32差异
• 性能优化：BPF JIT编译
• SELinux域：u:r:untrusted_app:s0
• MLS级别：基于targetSdkVersion
• 类别集：基于应用UID计算
• 访问向量：严格限制文件和IPC
• 能力(Capabilities)剥离：capset()清空能力集
• 应用进程无任何Linux capabilities
• 特权操作通过系统服务代理
• 防止权限提升攻击

沙箱初始化流程： ActivityThread启动时的沙箱设置：

1. Zygote fork新进程
2. 设置进程UID/GID（setuid/setgid）
3. 设置补充组（setgroups）
4. 切换SELinux上下文（setcon）
5. 应用Seccomp过滤器
6. 关闭不需要的文件描述符
7. 设置进程优先级和调度策略

内存隔离机制：

• ASLR（地址空间布局随机化）
• 栈、堆、库加载地址随机
• mmap基址随机化
• PIE（Position Independent Executables）
• 堆保护
• 堆块元数据加密
• 双向链表完整性检查
• 随机化分配器（jemalloc/scudo）
• 栈保护
• 栈金丝雀（Stack Canaries）
• 栈不可执行（NX bit）
• 影子栈（Shadow Stack，硬件支持时）

26.1.3 Android Runtime Namespace (ART NS)

ART虚拟机层面的隔离机制提供了额外的安全保障。这层隔离不仅保护Java/Kotlin代码，还管理native代码的加载和执行，形成完整的运行时安全体系。

ClassLoader隔离：

• PathClassLoader：应用类加载
• 加载已安装APK中的类
• 继承自BaseDexClassLoader
• 不支持从任意路径加载
• DexClassLoader：动态加载
• 支持从文件系统加载DEX/JAR
• 需要指定优化目录
• 常用于插件化框架
• InMemoryDexClassLoader：内存DEX加载（Android 8.0+）
• 直接从ByteBuffer加载
• 不落盘，增强安全性
• 适用于动态代码生成
• DelegateLastClassLoader：委托末尾加载器（Android 8.0+）
• 优先查找自己的类
• 用于解决类冲突
• 支持隔离的类空间

ClassLoader层次结构：

BootClassLoader (系统类)
    ↓
SystemClassLoader (框架扩展)
    ↓
PathClassLoader (应用类)
    ↓
自定义ClassLoader (动态加载)

JNI命名空间： Native库加载通过linker命名空间实现隔离：

• 公共命名空间：系统库
• /system/lib64/：系统native库
• /apex/*/lib64/：APEX模块库
• 导出符号表控制可见性
• 应用命名空间：私有native库
• /data/app/*/lib/：应用私有库
• 隔离符号表，防止冲突
• 限制dlopen路径
• Vendor命名空间：厂商HAL库
• /vendor/lib64/：厂商实现
• /odm/lib64/：ODM定制
• VNDK版本控制
• Runtime命名空间：ART专用
• libart.so及其依赖
• JNI检查和调试库
• 性能分析库

通过android_dlopen_ext()控制库搜索路径：

• ANDROID_DLEXT_USE_NAMESPACE：指定命名空间
• ANDROID_DLEXT_USE_LIBRARY_FD：直接使用文件描述符
• ANDROID_DLEXT_USE_RELRO：共享RELRO段
• ANDROID_DLEXT_FORCE_LOAD：强制重新加载

命名空间配置： /system/etc/ld.config.*.txt定义命名空间规则：

[应用命名空间配置示例]
namespace.default.isolated = true
namespace.default.search.paths = /data/app/${APP}/${APP}/lib/${ABI}
namespace.default.permitted.paths = /data
namespace.default.links = system,vndk

JNI安全检查： ART运行时提供多层JNI安全检查：

• CheckJNI模式：开发时参数验证
• 验证JNI调用参数
• 检查引用有效性
• 监测内存越界
• JNI本地引用表：防止泄露
• 默认512个槽位
• 自动清理机制
• 溢出检测
• JNI全局引用限制
• 默认51200个全局引用
• 弱全局引用单独计数
• 防止内存泄露

方法解析隔离：

• dex2oat编译隔离
• 每个应用独立编译
• 验证DEX文件完整性
• Profile引导优化（PGO）
• 方法内联限制
• 跨包边界不内联
• 保持调用栈完整性
• Hidden API访问控制

Hidden API访问控制： Android 9起限制非SDK接口访问：

• 白名单：公开SDK接口
• 浅灰名单：targetSdk < 28可用
• 深灰名单：特定版本可用
• 黑名单：完全禁止访问

访问检查实现：

1. 运行时通过访问标志检查
2. 反射调用额外验证
3. JNI调用路径检查
4. 豁免机制（系统应用等）

26.1.4 容器化网络隔离

Android的网络隔离主要通过UID-based防火墙规则实现，这是一种独特的设计，不同于传统Linux的基于进程或namespace的网络隔离。

Netfilter/iptables规则架构： Android使用定制的iptables规则链：

• INPUT链：基于UID的入站控制

Chain INPUT
-A INPUT -j bw_INPUT      # 带宽统计
-A INPUT -j fw_INPUT      # 防火墙规则
-A INPUT -m owner --uid-owner 0 -j ACCEPT  # root访问

• OUTPUT链：应用出站流量控制

Chain OUTPUT
-A OUTPUT -j oem_out      # OEM定制规则
-A OUTPUT -j fw_OUTPUT    # 防火墙输出
-A OUTPUT -j st_OUTPUT    # 流量统计
-A OUTPUT -j bw_OUTPUT    # 带宽控制

• nat表：网络地址转换
• 热点共享NAT
• VPN重定向
• IPv6到IPv4转换
• mangle表：包标记和修改
• QoS标记
• 路由标记
• TTL调整

网络权限映射：

• INTERNET权限：允许网络访问
• 检查在NetworkManagementService
• 无此权限的应用被DROP
• 通过iptables uid-owner模块实现
• 特定UID范围：
• VPN应用（AID_VPN=1016）
• DNS解析（AID_DNS=1051）
• 网络栈（AID_NETWORK_STACK=1073）
• 系统应用特权：
• 绕过计量限制
• 后台数据访问
• 特定端口绑定

eBPF网络程序（Android 9+）： eBPF替代iptables实现高性能网络控制：

• 流量统计：BPF_PROG_TYPE_CGROUP_SKB

位置：/sys/fs/bpf/netd_shared/prog_netd_skfilter_*
功能：

- per-UID流量统计
- per-tag流量分组
- 实时流量监控

• 流量控制：BPF_PROG_TYPE_CGROUP_SOCK

功能：

- 限制socket创建
- 端口访问控制
- 协议类型限制

• 性能监控：BPF_PROG_TYPE_TRACEPOINT

监控点：

- TCP连接建立/断开
- 丢包统计
- 延迟测量

eBPF Map结构：

cookie_tag_map：应用标签映射
uid_counter_map：UID流量计数器
app_uid_stats_map：应用统计信息
iface_stats_map：接口统计

网络隔离实现细节：

1. Socket权限检查：

inet_create() -> check_net_admin_capability()

1. 检查INTERNET权限
2. 验证UID是否在允许范围
3. SELinux socket创建检查
4. 返回EACCES如果无权限

2. VPN隔离机制： - 每个用户独立VPN配置 - 通过路由表隔离（ip rule） - 标记（mark）区分VPN流量 - per-app VPN支持

3. 计量网络控制： - 后台数据限制 - 数据节省模式 - 应用待机限制 - 低电量限制

网络命名空间使用（特殊场景）： 虽然Android主要使用UID隔离，但在某些场景使用network namespace：

• 网络测试和诊断
• VPN客户端隔离
• 容器化应用（如Termux）
• 企业VPN隔离

创建网络namespace：

通过setns()和unshare()系统调用
需要CAP_SYS_ADMIN能力
主要由特权进程使用

防火墙规则持久化：

• 规则存储：/data/misc/net/
• 启动时恢复：netd服务
• 动态更新：通过netd socket
• 原子性更新：使用iptables-restore

26.1.5 与Linux容器技术的差异

Android容器化与传统Linux容器（如Docker）存在显著差异，这些差异反映了移动平台的特殊需求和约束。

设计目标差异：

| 特性 | Android | Linux容器 |

实现差异：

• 无完整的容器运行时
• Android无Docker/containerd等
• 直接使用kernel原语
• Zygote作为"容器管理器"
• 不支持容器镜像概念
• APK作为分发单元
• 无分层文件系统
• 应用数据持久化在/data
• 深度集成ActivityManager
• 生命周期由AMS管理
• 组件（Activity/Service）粒度控制
• 与用户交互紧密结合
• 针对移动设备优化
• 内存压力下的进程管理
• 电池优化的调度策略
• 传感器和硬件访问

技术栈对比：

Linux容器技术栈：          Android技术栈：
┌─────────────┐          ┌─────────────┐
│   应用镜像   │          │     APK      │
├─────────────┤          ├─────────────┤
│  Container  │          │ActivityThread│
│   Runtime   │          ├─────────────┤
├─────────────┤          │    Zygote    │
│    runc     │          ├─────────────┤
├─────────────┤          │   Binder     │
│ Namespaces  │          ├─────────────┤
│  Cgroups    │          │ UID隔离+NS   │
└─────────────┘          └─────────────┘

性能考量：

• 启动速度优先
• Zygote预加载减少冷启动
• 共享内存映射（系统库）
• Copy-on-Write fork优化
• 类预加载和验证
• 内存效率
• 共享系统库和资源
• Zygote堆共享
• 进程优先级和LMK
• 内存压缩（ZRAM）
• 电池寿命
• Doze模式进程冻结
• 应用待机限制
• 后台服务限制
• JobScheduler批处理

资源管理差异：

Android资源管理：

• OOM调整值（oom_adj）
• 前台：0
• 可见：100
• 服务：200-500
• 缓存：900+
• 内存压力响应
• onTrimMemory()回调
• 进程优先级调整
• 主动清理缓存

Linux容器资源管理：

• 硬限制（Hard Limits）
• 软限制（Soft Limits）
• CPU份额和配额
• 内存限制和swap

隔离粒度差异：

Android：

• 应用级隔离（每个APK）
• 组件级管理（四大组件）
• 权限级访问控制
• 数据共享需显式授权

Linux容器：

• 容器级隔离
• 进程组管理
• 网络namespace隔离
• 卷挂载数据共享

安全模型差异：

Android安全：

• 应用签名验证
• 权限声明和授予
• SELinux强制访问控制
• 应用沙箱默认开启

容器安全：

• 镜像签名（可选）
• Capabilities细粒度控制
• Seccomp配置文件
• AppArmor/SELinux（可选）

未来发展趋势：

Android向容器化靠拢：

• Microdroid轻量虚拟机
• APEX模块化
• 增强的namespace使用
• 更细粒度的资源控制

保持的差异：

• 以应用为中心
• 电池和性能优先
• 用户隐私保护
• 生态系统兼容性

26.2 多用户与工作资料

26.2.1 Multi-User架构设计

Android的多用户系统从Android 4.2开始引入，支持在同一设备上创建多个独立的用户环境。

用户类型分类：

• 主用户（Primary User）：userId=0
• 次要用户（Secondary User）：userId≥10
• 访客用户（Guest User）：临时用户
• 受限用户（Restricted User）：权限受限
• 管理用户（Managed Profile）：工作资料

UserManagerService核心功能：

• 用户创建/删除：createUser(), removeUser()
• 用户切换：switchUser()
• 用户状态管理：启动、停止、解锁
• 用户限制：setUserRestriction()

用户数据隔离：

• 用户数据目录：/data/user/<userId>/
• 用户系统目录：/data/system/users/<userId>/
• 媒体数据：/data/media/<userId>/
• 外部存储：/storage/emulated/<userId>/

26.2.2 用户切换流程

用户切换涉及系统多个组件的协调：

1. ActivityManager处理： - 停止当前用户Activity - 保存当前用户状态 - 冻结后台进程

2. 系统服务切换： - NotificationManager清理通知 - AudioService切换音频配置 - WallpaperManager更新壁纸

3. 存储卷切换： - 卸载当前用户存储 - 挂载新用户存储 - 更新存储权限

4. 界面切换： - SystemUI更新状态栏 - Launcher重新加载 - 锁屏界面更新

26.2.3 工作资料(Work Profile)技术架构

工作资料是Android Enterprise的核心功能，实现个人和工作数据的隔离。

Profile创建流程：

1. DevicePolicyManager.createAndManageUser()
2. 设置Profile Owner应用
3. 配置跨Profile权限
4. 启动Profile服务

跨Profile通信机制：

• CrossProfileApps API：应用间通信
• Intent转发：Intent.ACTION_SEND等
• 内容共享：FileProvider跨Profile
• 通知同步：部分通知可跨Profile显示

Profile管理策略：

• 应用白名单/黑名单
• 数据传输限制
• 相机/截屏禁用
• VPN强制连接

26.2.4 跨用户数据隔离机制

Android通过多层机制确保用户间数据隔离：

文件系统层：

• UID偏移：userId * 100000 + appId
• SELinux标签：包含userId信息
• 文件权限：严格的DAC控制

Framework层：

• ContentProvider：检查调用者userId
• Service绑定：限制跨用户绑定
• Broadcast：用户特定广播

存储加密：

• FBE（File-Based Encryption）：每用户独立密钥
• Keystore：用户特定密钥存储
• 凭据加密存储：/data/misc/keystore/user_<userId>/

26.2.5 Device Owner与Profile Owner权限模型

Android设备管理通过不同级别的所有者实现：

Device Owner权限：

• 设备级别策略：全局密码要求
• 系统更新控制：OTA延迟/强制
• 应用管理：静默安装/卸载
• 网络配置：全局代理设置

Profile Owner权限：

• Profile应用管理
• Profile数据擦除
• 证书管理
• VPN配置

DPC (Device Policy Controller) 实现：

• DeviceAdminReceiver：接收管理事件
• DevicePolicyManager：执行策略
• 策略同步：与EMM服务器通信

26.3 虚拟化安全增强

26.3.1 SELinux在虚拟化中的应用

SELinux是Android安全架构的核心组件，在虚拟化环境中提供强制访问控制。

SELinux域隔离：

• 应用域：untrusted_app, priv_app, system_app
• 隔离服务域：isolated_app
• 虚拟化域：virtualizationservice

类型转换规则：

# Zygote fork应用进程
type_transition zygote apk_data_file:process untrusted_app;

# 隔离进程转换
type_transition untrusted_app isolated_app_data_file:process isolated_app;

MLS (Multi-Level Security) 支持：

• 敏感度级别：s0-s0:c512,c768
• 类别隔离：基于应用UID
• 跨级别访问控制

26.3.2 Seccomp-BPF系统调用过滤

Seccomp-BPF提供细粒度的系统调用过滤，增强沙箱安全性。

过滤策略加载：

• Zygote预加载：InitializeSeccompFilter()
• 应用特定过滤：SetSeccompFilter()
• 架构相关规则：arm64/arm32差异处理

典型过滤规则：

• 禁用危险调用：mount, umount, ptrace
• 限制网络调用：仅允许特定socket类型
• 文件系统限制：禁止特定路径访问

性能优化：

• JIT编译BPF程序
• 缓存编译结果
• 批量规则加载

26.3.3 虚拟化环境下的权限隔离

Android在虚拟化环境中实施多层权限隔离：

Linux Capabilities剥离：

• 应用进程：完全剥离所有capabilities
• 系统服务：最小权限原则
• 特权操作：通过IPC请求系统服务

文件系统权限：

• 私有目录：700权限
• 共享存储：基于FUSE的动态权限
• 系统文件：只读挂载

Binder权限检查：

• UID/PID验证
• Permission检查
• AppOp额外控制

26.3.4 Hardware-backed Keystore隔离

硬件安全模块提供密钥隔离和加密操作：

Keymaster/KeyMint HAL：

• 密钥生成：硬件随机数
• 密钥存储：安全元件/TEE
• 加密操作：硬件加速

密钥隔离机制：

• 应用密钥绑定：UID + 别名
• 密钥访问控制：认证要求
• 密钥证明：证书链验证

StrongBox实现（Android 9+）：

• 专用安全芯片
• 抗物理攻击
• 独立安全处理器

26.3.5 Virtualization-based Security (VBS)

Android正在探索基于虚拟化的安全增强：

pKVM (Protected KVM)：

• Type-1 Hypervisor
• 保护客户VM内存
• 设备直通支持

应用场景：

• DRM内容保护
• 生物识别数据隔离
• 密钥管理服务

性能考量：

• 硬件虚拟化扩展（VHE）
• Stage-2页表管理
• 中断虚拟化

26.4 与iOS虚拟化对比

26.4.1 iOS沙箱模型分析

iOS采用了与Android不同的沙箱实现策略，更依赖于内核级强制和代码签名。

iOS沙箱特点：

• Seatbelt沙箱（基于TrustedBSD MAC）
• 沙箱配置文件（.sb文件）
• 强制代码签名
• Entitlements权限系统

沙箱Profile结构：

• 默认拒绝策略
• 细粒度文件系统规则
• Mach IPC限制
• 系统调用过滤

iOS容器结构：

• Bundle容器：应用二进制和资源
• Data容器：应用私有数据
• Group容器：应用组共享数据

26.4.2 Android vs iOS进程隔离策略

两个平台在进程隔离上采用了不同的技术路线：

Android进程隔离：

• 基于Linux UID/GID
• SELinux MAC层
• Namespace隔离
• Seccomp-BPF过滤

iOS进程隔离：

• BSD进程模型
• Seatbelt沙箱策略
• XPC服务架构
• Mach端口权限

隔离粒度对比：

| 特性 | Android | iOS |

26.4.3 虚拟化性能影响对比

Android性能特征：

• Zygote预加载减少启动时间
• 共享运行时库降低内存使用
• JIT/AOT混合编译
• 运行时GC开销

iOS性能特征：

• 原生代码执行效率
• 无GC开销
• Metal图形加速
• 统一内存架构优势

内存管理差异：

• Android：Dalvik/ART堆管理，LMK/LMKD
• iOS：Jetsam内存压力处理，内存压缩

启动性能对比：

• Android冷启动：200-800ms（取决于应用）
• iOS冷启动：150-600ms（取决于应用）
• Android温启动优势：Zygote fork
• iOS温启动：进程缓存

26.4.4 安全模型差异分析

权限模型：

Android权限系统：

• 安装时权限（Android 6.0前）
• 运行时权限（Android 6.0+）
• 特殊权限（系统设置授予）
• AppOps细粒度控制

iOS权限系统：

• 首次使用时请求
• 隐私设置集中管理
• 临时精确位置权限
• App Tracking Transparency

数据保护：

Android数据保护：

• 全盘加密（FDE，已废弃）
• 文件级加密（FBE）
• Adoptable Storage
• 密钥派生函数

iOS数据保护：

• 数据保护类（Protection Classes）
• 文件级加密密钥层次
• Secure Enclave处理
• 硬件密钥包装

漏洞缓解措施对比：

| 缓解技术 | Android | iOS |

26.4.5 虚拟化技术发展趋势

Android未来方向：

• Microdroid轻量级VM
• pKVM保护虚拟机
• 基于Rust的安全组件
• eBPF增强运行时

iOS未来方向：

• 虚拟化框架（macOS技术下放）
• 更严格的沙箱策略
• 差分隐私技术
• 设备端机器学习隔离

共同趋势：

• 硬件安全特性利用
• 零信任安全架构
• 隐私计算技术
• 跨平台虚拟化标准

本章小结

本章深入探讨了Android虚拟化技术的各个层面：

1. 容器化技术：基于Linux Namespace和Cgroup的应用隔离，配合ART运行时隔离和网络隔离，构建了Android独特的容器化架构。

2. 多用户系统：通过UserManagerService实现的多用户支持，以及工作资料（Work Profile）提供的企业级数据隔离方案。

3. 安全增强：SELinux强制访问控制、Seccomp-BPF系统调用过滤、硬件安全模块支持等多层防护机制。

4. 平台对比：Android基于Linux的虚拟化方案与iOS基于BSD的沙箱模型各有特色，在性能和安全性上各有权衡。

关键技术要点：

• UID隔离是Android安全模型的基础
• Namespace提供进程级资源隔离
• SELinux实施强制访问控制
• 工作资料实现企业数据隔离
• 硬件安全特性提供可信执行环境

练习题

基础题

1. Android应用沙箱UID分配

2. Namespace隔离机制

3. SELinux域转换

挑战题

4. 多用户数据隔离实现

5. 虚拟化安全增强设计

6. Work Profile架构扩展

常见陷阱与错误 (Gotchas)

1. UID计算错误

问题：直接使用appId作为UID，忽略了多用户偏移 后果：跨用户数据泄露 正确做法：始终使用UserHandle.getUid(userId, appId)

2. SELinux策略遗漏

问题：添加新功能时忘记更新SELinux策略 症状：权限拒绝（avc: denied） 调试方法：adb logcat | grep avc查看拒绝日志

3. Namespace泄露

问题：在隔离进程中错误地保留了父进程的Namespace 后果：隔离失效 检查方法：/proc/<pid>/ns/目录下的符号链接

4. 跨用户组件启动

问题：尝试直接启动其他用户的Activity/Service 症状：SecurityException 正确做法：使用CrossProfileApps API或系统权限

5. Work Profile数据混淆

问题：个人应用访问工作数据或反之 原因：URI授权不当 预防：严格检查UserHandle.getUserId()

6. 虚拟化性能退化

问题：过度的安全检查导致性能问题 症状：应用响应缓慢 优化：缓存安全决策、批量处理

最佳实践检查清单

设计阶段

• [ ] 明确数据隔离边界和安全需求
• [ ] 选择合适的隔离级别（普通应用/隔离进程/独立用户）
• [ ] 设计跨边界通信机制
• [ ] 考虑性能影响和优化方案

实现阶段

• [ ] 正确计算和使用UID
• [ ] 实施最小权限原则
• [ ] 添加必要的SELinux策略
• [ ] 使用Framework提供的隔离API

安全加固

• [ ] 启用所有可用的安全特性
• [ ] 自定义Seccomp-BPF规则
• [ ] 实施运行时完整性检查
• [ ] 添加审计日志

测试验证

• [ ] 多用户场景测试
• [ ] Work Profile兼容性测试
• [ ] 权限和隔离边界测试
• [ ] 性能基准测试

维护优化

• [ ] 监控安全日志和异常
• [ ] 定期更新安全策略
• [ ] 跟踪平台安全更新
• [ ] 用户反馈和问题处理