30、车载系统安全加固：系统漏洞扫描与修复、SELinux策略强化、应用签名与验证、数据安全与隐私保护

车载系统安全，说实话，是个“平时没人管，出事全怪你”的活儿。我入行那会儿，大家更关心功能能不能跑起来，至于安全？嗯，先上线再说。直到有一次，我们一台测试车被白帽子远程打开了车门……从那以后，安全就成了我每次提测前必须过的鬼门关。

今天这一章，咱们就聊聊车载Android系统安全加固的几个核心方向。说白了，就是四件事：漏洞怎么扫、SELinux怎么锁、应用怎么验、数据怎么藏。

一、系统漏洞扫描与修复

漏洞扫描这事儿，我个人的习惯是把它分成两个阶段：构建时扫描和运行时监控。

构建时扫描，说白了就是在你编译系统镜像之前，先把所有依赖的第三方库、内核模块、甚至你写的native服务，全部过一遍CVE数据库。我见过太多团队，辛辛苦苦把功能做完了，结果一扫描，OpenSSL版本还是三年前的，一堆高危漏洞。嗯，那种感觉就像你装修完房子才发现地基是豆腐渣。

运行时监控呢？主要是针对那些“零日漏洞”。你不可能预知所有攻击，但你可以监控异常行为。比如，一个原本只读文件的进程突然开始写系统分区，这肯定有问题。我曾在某款车型上遇到过，一个第三方地图应用试图读取/data/system下的敏感文件，被SELinux直接拦了——这就是运行时监控的价值。

修复策略上，我建议按优先级排序：

• P0（紧急）：远程代码执行、提权漏洞。必须立即合入补丁，重新构建系统。
• P1（高）：信息泄露、拒绝服务。可以在下一个OTA版本中修复。
• P2（中）：本地低风险漏洞。记录在案，随大版本更新。

二、SELinux策略强化

SELinux，很多人觉得它烦。动不动就avc: denied，日志刷屏。但说实话，它是车载系统最后一道防线。你想想看，如果应用层被攻破了，SELinux还能拦住它乱搞系统文件，这就是它的价值。

我在项目中遇到过最典型的问题：某个车载hal服务需要访问GPS数据，但SELinux策略没写对，结果GPS死活拿不到数据。调试了一整天，最后发现是hal_gps_default.te文件里少了一条allow规则。

强化SELinux策略，我总结了三个核心原则：

1. 最小权限原则：只给进程它真正需要的权限。别图省事直接写allow domain domain:file read，那等于没开SELinux。
2. neverallow规则：这是你的“安全底线”。比如，绝对不允许普通应用域访问system_data_file。写一条neverallow appdomain system_data_file:file write，编译时就能拦住违规行为。
3. 域隔离：每个关键服务一个独立域。比如gpsd、mediaserver、surfaceflinger各玩各的，互不干扰。

下面是一个典型的SELinux策略文件示例，用于限制一个车载导航服务的权限：

# 文件: hal_navigation_default.te
type hal_navigation, domain;
type hal_navigation_exec, exec_type, file_type;

# 只允许访问自己的数据目录
allow hal_navigation hal_navigation_data_file:dir rw_dir_perms;
allow hal_navigation hal_navigation_data_file:file create_file_perms;

# 允许读取GPS数据
allow hal_navigation gps_device:chr_file rw_file_perms;

# 绝对不允许写系统分区
neverallow hal_navigation system_file:file write;

三、应用签名与验证

应用签名，说白了就是给每个APK发一张“身份证”。车载系统里，这张身份证尤其重要。因为车机上的应用来源比手机复杂得多——有主机厂自研的、有供应商的、还有第三方市场的。

Android从7.0开始支持APK Signature Scheme v2，从9.0开始支持v3。我建议车载系统直接上v3签名，因为它支持签名轮换。什么意思呢？就是你的签名密钥过期了，可以在不破坏已有签名链的情况下换一把新钥匙。这对车机这种长生命周期设备来说，太重要了。

验证流程上，我习惯在PackageManagerService里加一道自定义校验：

• 第一步：检查签名是否匹配白名单中的证书指纹。
• 第二步：验证APK完整性，确保没有被二次打包。
• 第三步：运行时定期重校验，防止运行时注入。

四、数据安全与隐私保护

数据安全这块，我把它拆成“存、传、用”三个环节。

存：全盘加密是标配。但要注意，车载系统的加密密钥不能像手机那样用用户密码派生。车机没有用户交互，所以密钥通常存储在安全芯片（SE）或TEE里。我建议使用dm-crypt + keymaster的组合，密钥由TEE管理，系统分区和用户数据分区分别加密。

传：车内外通信必须加密。车内用TLS 1.3，车外用mTLS（双向认证）。我曾经在某个项目里发现，OBD接口的数据竟然是明文传输的——随便一个蓝牙嗅探器就能读到发动机参数。嗯，那之后我们就把所有车内总线通信都加了TLS。

用：隐私保护的核心是“最小化采集”。比如，导航应用只需要你的位置，不需要你的通讯录。我建议在PermissionController里增加一个“隐私审计日志”，记录每个应用在什么时间、因为什么原因访问了敏感数据。这个日志只允许系统服务读取，普通应用看不到。