Android 10부터 14까지: 버전별 SELinux 정책 변화 및 보안 강화 총정리

안드로이드는 버전이 거듭될수록 사용자 데이터 보호와 시스템 무결성을 위해 보안 모델을 진화시켜 왔습니다. 그 중심에는 시스템의 모든 접근 권한을 세밀하게 통제하는 SELinux(Security-Enhanced Linux)가 있습니다. 특히 Android 10 이후부터는 시스템 구조의 파편화와 샌드박스 강화에 따라 정책이 매우 복잡하고 엄격해졌습니다.

이번 포스팅에서는 임베디드 및 안드로이드 시스템 개발자들이 반드시 숙지해야 할 Android 10(Q)부터 최신 Android 14(U)까지의 SELinux 주요 정책 변화를 비교 분석해 보겠습니다.

Generated by Gemini AI.

📌 핵심 요약 3줄

1. Android 10~11: APEX 모듈 도입 및 Scoped Storage 적용으로 시스템과 벤더, 앱 데이터 간의 경계가 엄격해졌습니다.
2. Android 12~13: 권한 있는(Privileged) 앱의 접근을 제한하고, Bluetooth 및 미디어 통신의 보안 샌드박스를 강화했습니다.
3. Android 14: AdServices, Health Connect 등 신규 서비스 전용 도메인이 추가되고, UID 기반의 프로세스 격리가 더욱 심화되었습니다.

---

1. Android 버전별 SELinux 주요 변화 비교

각 버전에서 가장 핵심이 되는 변경 사항을 표로 정리했습니다.

버전	코드네임	핵심 변경 사항	주요 영향 범위
Android 10	Q	APEX 도입, System/Vendor 분리 강화	모듈형 시스템 업데이트, 벤더 접근 제한
Android 11	R	Scoped Storage 본격 적용	미디어 및 외부 저장소 접근 권한 축소
Android 12	S	Privileged App 및 System Server 강화	시스템 앱의 네트워크/IPC 접근 제한
Android 13	T	Bluetooth 및 Media Provider 세분화	블루투스 스택 보호, 미디어 데이터 격리
Android 14	U	AdServices, Health Connect, UID 격리	신규 프라이버시 서비스 도메인 추가

---

2. 버전별 상세 분석 및 정책 예시

2.1 Android 10 (Q): 모듈화와 경계 강화

APEX 도입으로 인해 /apex 경로에 대한 보안 컨텍스트가 신설되었습니다. 또한, init 프로세스가 벤더 영역을 직접 수정하는 것을 금지하는 등 상호 간섭을 최소화했습니다.

• 예시: /apex(/.*)? u:object_r:system_apex_file:s0

2.2 Android 11 (R): 저장소 보안의 혁명

Scoped Storage 적용으로 untrusted_app이 공용 저장소의 모든 파일에 접근하는 것이 차단되었습니다.

• 예시: /storage/emulated(/.*)? u:object_r:media_rw_data_file:s0

2.3 Android 12 (S) & 13 (T): 샌드박스 고도화

시스템 앱(Privileged App)조차도 네트워크 소켓 생성에 제약을 받기 시작했으며, Bluetooth 서비스에 대한 직접적인 IPC 통신이 엄격히 제한되었습니다.

• 예시: neverallow untrusted_app bluetooth_service:service_manager find;

2.4 Android 14 (U): 서비스별 도메인 파편화

광고(AdServices)와 건강 데이터(Health Connect)를 별도의 도메인으로 분리하여, 특정 앱이 권한 없이 해당 데이터 영역을 넘볼 수 없도록 설계되었습니다.

• 예시: neverallow untrusted_app other_apps:dir read; (UID 격리 강화)

---

💡 개발을 위한 꿀팁 (Tips)

• 버전별 테스트 자동화: OS 버전을 올릴 때 기존에 동작하던 기능이 SELinux에 막히는 경우가 많습니다. VTS(Vendor Test Suite)의 SELinux 테스트 항목을 활용해 조기에 위반 사항을 체크하세요.
• 호환성 도메인 확인: 새로운 버전으로 마이그레이션할 때 AOSP에서 제공하는 compat 관련 정책 파일(system/sepolicy/private/compat/)을 참고하면 변경된 타입을 파악하기 쉽습니다.
• 로그 캡처 타이밍: 부팅 직후에만 발생하는 AVC Denied 로그가 있으므로, 부팅 과정 전체의 dmesg를 확보하는 습관을 들이는 것이 좋습니다.

⚠️ 흔히 하는 실수 (Common Mistakes)

• 구 버전 정책 답습: Android 10 이전의 관습대로 system_app에 넓은 권한을 주는 것은 최신 버전 빌드 시 neverallow 위반으로 이어집니다.
• 공용 도메인 남용: 모든 벤더 파일을 vendor_file로 라벨링하면 보안 검토에서 반려될 확률이 높습니다. 가급적 서비스 전용 타입을 세분화하여 정의하세요.
• UID 격리 무시: Android 14 환경에서 다른 앱의 디렉토리를 직접 탐색하려는 로직은 SELinux 정책상 원천 차단되므로, 반드시 공식적인 Content Provider나 API를 사용해야 합니다.

---

3. 결론

Android 10부터 14까지의 여정은 "더 좁고, 더 깊은 격리"로 요약될 수 있습니다. 시스템 개발자는 단순히 기능을 구현하는 것을 넘어, 구글이 지향하는 최신 보안 모델에 맞게 정책을 설계해야 합니다. 각 버전의 neverallow 규칙 변화를 주기적으로 점검하여, 보안성과 호환성을 모두 갖춘 시스템을 구축하시기 바랍니다.