先把结论放在前面：Android 从 4.3 起把 SELinux 打开，到 5.0 起对应用强制启用。对应用开发者来说，这带来的不是"配置一堆策略"，而是一条清晰的边界：进程能访问什么文件、能发起什么 IPC、能加载什么代码，都由策略决定，而不是由 root 权限决定。 应用侧的绝大多数安全问题，最终都能落到"这条边界被绕过"或"边界内的权限被滥用"上。面试里这题属于"安全专项"。答得浅的是"SELinux 是 Linux 的 MAC 机制，Android 有两套策略"；答得深的是能讲清enforce/permissive的区别与生产环境为何不能用 permissive 掩盖问题、Android 里的两套上下文（应用与 system_server）、以及最常见的几类avc: denied与各自成因。DAC 之外为什么需要 MAC先明确概念边界。Linux 的传统安全模型是 DAC（自主访问控制）：进程有 uid/gid，文件有 owner/group/other 权限位，访问与否取决于权限位与 uid 是否匹配。SELinux 是 MAC（强制访问控制）：策略里明确规定"哪个域（domain）能对哪个类型（type）做什么操作"，内核在每次访问时校验，进程无法自行放宽。两者的差别是决定性的：DAC 下，拿到 root 就等于绕过一切；MAC 下，即使是 root，如果不在允许的域里，访问一样被拒。Android 用它来保护系
