Android sepolicy 구조 완벽 분석: file_contexts부터 빌드 과정까지

안드로이드 시스템 개발이나 커스텀 펌웨어를 제작하다 보면 가장 까다로운 부분 중 하나가 바로 sepolicy(Security Policy) 설정입니다. 기능을 정상적으로 구현했음에도 불구하고 SELinux 거부 로그(AVC Denied) 때문에 동작하지 않는 경우가 허다하기 때문입니다.

Android는 SELinux를 기반으로 매우 세밀하고 복잡한 보안 정책을 운용합니다. 원활한 시스템 개발과 보안 강화를 위해서는 system/sepolicy 내부에 흩어져 있는 다양한 설정 파일들의 역할을 정확히 파악해야 합니다. 오늘은 Android sepolicy의 전체적인 구조와 빌드 과정을 상세히 살펴보겠습니다.

Generated by Gemini AI.

---

📌 핵심 요약 3줄

1. 구조적 할당: file, service, property 등 각 자원 유형별로 컨텍스트 파일을 분리하여 보안 라벨을 관리합니다.
2. 정책의 모듈화: Android 8.0(Project Treble)부터 플랫폼(System)과 벤더(Vendor) 영역의 정책을 독립적으로 관리합니다.
3. 컴파일 기반 적용: 다양한 .te 및 컨텍스트 파일들은 빌드 과정을 거쳐 커널이 이해할 수 있는 바이너리 정책 파일로 변환됩니다.

---

1. Android sepolicy 주요 디렉터리 및 파일 역할

Android sepolicy는 단순히 하나의 파일이 아니라, 대상에 따라 여러 개의 컨텍스트 파일로 나뉩니다.

파일 및 디렉터리	주요 역할	설정 예시 및 설명
file_contexts	파일 시스템 경로별 보안 라벨 지정	/system(/.*)? u:object_r:system_file:s0
seapp_contexts	앱의 UID/패키지명에 따른 도메인 할당	user=_app domain=untrusted_app
property_contexts	시스템 속성(System Property) 접근 제어	ro.build.type u:object_r:build_prop:s0
service_contexts	바인더(Binder) 서비스 보안 라벨 지정	activity u:object_r:activity_service:s0
genfs_contexts	procfs, sysfs 등 가상 파일 시스템 라벨링	genfscon proc / u:object_r:proc:s0
public / private	정책의 공개 범위 설정	플랫폼 정책의 인터페이스 분리

---

2. 정책의 분리: 플랫폼(Plat) vs 벤더(Vendor)

현대 안드로이드 아키텍처(Project Treble)에서는 OS 업데이트 효율성을 위해 정책을 두 영역으로 나눕니다.

• plat_sepolicy.cil: 구글이 제공하는 핵심 OS 정책입니다. /system 파티션에 위치합니다.
• vendor_sepolicy.cil: 칩셋 제조사(AP)나 OEM이 추가한 하드웨어 관련 정책입니다. /vendor 파티션에 위치합니다.
• mapping: 플랫폼 버전이 업데이트되어도 기존 벤더 정책이 호환되도록 연결해주는 매핑 파일이 존재합니다.

---

3. Android sepolicy 빌드 및 로드 과정

sepolicy는 텍스트 기반의 .te 파일과 컨텍스트 파일들을 결합하여 바이너리 형태로 생성됩니다.

1. 정책 결합: system/sepolicy와 device/vendor/common/sepolicy 등 여러 경로의 정책을 수집합니다.
2. M4 매크로 확장: .te 파일 내의 매크로를 실제 SELinux 규칙으로 확장합니다.
3. 컴파일 및 검사: checkpolicy 툴을 사용해 문법 오류 및 neverallow 위반 여부를 검사합니다.
4. CIL 변환: 최종적으로 커널이 로드할 수 있는 .cil 또는 바이너리 형태로 빌드됩니다.

💡 빌드 팁: 수정된 정책만 빠르게 확인하려면 m selinux_policy 명령어를 활용하세요.

---

🛠️ 개발자를 위한 팁 & 흔히 하는 실수

✅ 개발 팁 (Best Practices)

• 속성(Attribute) 활용: 여러 도메인에 공통 권한을 줄 때는 개별 allow 규칙을 나열하기보다 attribute를 정의하여 그룹화하세요. 코드 가독성과 유지보수성이 크게 향상됩니다.
• 분리된 디렉터리 준수: 벤더 전용 하드웨어 제어 정책은 반드시 device/ 또는 vendor/ 하위의 sepolicy 디렉터리에 작성하여 플랫폼 업데이트 시 충돌을 방지하세요.

❌ 흔히 하는 실수 (Common Mistakes)

• file_contexts 정규식 오류: 정규식 맨 뒤에 (/.*)?를 빠뜨려 하위 디렉터리나 파일에 라벨이 제대로 적용되지 않는 경우가 많습니다.
• neverallow 위반: 구글이 설정한 강력한 보안 규칙(neverallow)을 위반하는 정책을 작성하면 빌드 시점에 에러가 발생합니다. 권한을 무작정 넓히기보다 시스템 설계를 다시 검토해야 합니다.
• 속성(Property) 이름 오타: property_contexts에 정의한 이름과 실제 setprop으로 사용하는 이름이 다르면 접근 거부 로그 없이 동작만 안 할 수 있으니 주의하세요.

---

4. 결론

Android sepolicy는 파일 시스템부터 시스템 속성, 바인더 서비스에 이르기까지 안드로이드 전반을 감싸는 촘촘한 보안 그물망입니다. 각 컨텍스트 파일의 역할을 정확히 이해하면 AVC Denied 이슈를 해결하는 시간이 획기적으로 줄어듭니다.

이번 포스팅이 안드로이드 시스템 개발의 난관인 sepolicy 구조를 이해하는 데 도움이 되셨기를 바랍니다.