Android System & AOSP Engineering/Android Security & SELinux

AOSP 보안 가이드라인을 준수하는 SELinux 정책 검토 및 분석 방법

임베디드 친구 2025. 5. 15. 20:22
반응형

안드로이드 시스템 보안의 핵심인 SELinux는 시스템 무결성을 유지하는 강력한 방패입니다. 하지만 AOSP(Android Open Source Project) 기반의 프로젝트를 진행하다 보면, 새로운 하드웨어나 기능을 추가하기 위해 '사용자 정의 정책(Custom Policy)'을 작성해야 할 때가 많습니다. 이때 가이드라인을 무시하고 무분별하게 권한을 허용하면 시스템 전체가 보안 취약점에 노출될 수 있습니다.

이번 포스팅에서는 작성한 사용자 정의 정책이 AOSP 보안 가이드라인을 철저히 준수하는지 검토하고, 빌드 오류를 방지하기 위한 전문적인 분석 도구 활용법을 알아보겠습니다.

Generated by Gemini AI.

📌 핵심 요약 3줄

  1. AOSP의 4대 원칙(최소 권한, 정확한 타입 지정, neverallow 준수, 정책 분리)을 이해합니다.
  2. sepolicy-analyze와 audit2allow 등 전문 도구를 사용하여 정책의 논리적 결함을 찾아냅니다.
  3. 빌드 전 neverallow 위반 여부를 미리 확인하여 보안 취약점과 빌드 실패를 예방합니다.

1. AOSP SELinux 보안 가이드라인 핵심 원칙

AOSP 환경에서 정책을 작성할 때 반드시 지켜야 할 4가지 기본 원칙입니다.

원칙 상세 내용 목적
최소 권한(PoLP) 프로세스 실행에 필요한 필수 권한 외 모두 차단 공격 표면 최소화
타입 및 속성 지정 객체(파일/프로세스)에 구체적인 Type 부여 의도치 않은 권한 상속 방지
neverallow 준수 시스템 핵심 영역에 대한 접근을 강제로 금지 보안 모델의 강제성 유지
정책 영역 분리 AOSP(System)와 Vendor 정책의 물리적 분리 업데이트 및 유지보수 효율화

2. SELinux 정책 검토 및 분석 도구 활용

정책 파일(.te)을 작성한 후, 실제 시스템에 적용하기 전에 다음 도구들을 순차적으로 활용하여 검증해야 합니다.

2.1. 구문 및 논리 검사 (checkpolicy)

작성된 정책의 문법적 오류나 논리적 충돌을 점검합니다.

  • 명령어: checkpolicy -M -c 30 policy.conf

2.2. 보안 금지 규칙 위반 확인 (sepolicy-analyze)

가장 중요한 단계입니다. AOSP 빌드 시스템은 neverallow 위반 시 빌드를 중단시킵니다. 미리 확인하여 빌드 시간을 절약하세요.

검사 항목 설명 명령어 예시
neverallow 금지된 권한 부여 여부 확인 sepolicy-analyze policy.conf neverallow
dups 중복 정의된 정책 확인 sepolicy-analyze policy.conf dups
unused_types 정의 후 사용하지 않는 타입 확인 sepolicy-analyze policy.conf unused_types

2.3. 거부 로그 분석 (audit2allow & audit2why)

실제 기기에서 발생하는 거부 로그(AVC Denied)를 분석하여 정책에 반영할지 판단합니다.

  • audit2allow: 거부 로그를 정책 문구(allow ...)로 자동 변환해줍니다.
  • audit2why: 왜 해당 권한이 거부되었는지 구체적인 이유(부족한 권한 등)를 설명해줍니다.

3. 실전! 파일 컨텍스트(file_contexts) 검토

파일 시스템에 올바른 보안 라벨이 붙어있는지 확인하는 것은 매우 중요합니다. 설정이 잘못되면 프로세스가 파일에 접근하지 못해 'Permission Denied'가 발생합니다.

  • 확인 방법: ls -Z [파일경로]
  • 수정 예시: 벤더 전용 앱 데이터 경로 설정 시
경로 패턴 보안 컨텍스트 (Label) 비고
/data/vendor/app_data(/.*)? u:object_r:vendor_app_data_file:s0 재귀적 적용 필요
/vendor/bin/my_service u:object_r:my_service_exec:s0 실행 파일 전용 라벨

💡 개발을 위한 꿀팁 (Tips)

  • 빌드 단위 테스트: 전체 빌드를 돌리기 전에 mmm system/sepolicy 명령어를 통해 정책 파일만 빠르게 컴파일하여 구문 오류를 확인하세요. 시간 절약에 매우 효과적입니다.
  • 속성(Attribute) 활용: 유사한 권한이 필요한 여러 도메인이 있다면 개별적으로 allow를 쓰지 말고, 공통 attribute를 정의하여 관리하세요. 정책 파일이 훨씬 간결해집니다.
  • Contexts 우선순위: file_contexts 파일에서 하단에 위치한 규칙이 상단보다 우선순위가 높습니다. 구체적인 경로일수록 아래에 배치하는 것이 관례입니다.

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

  • neverallow 우회 시도: 빌드 오류가 난다고 해서 AOSP 기본 neverallow 규칙을 직접 수정하거나 삭제하지 마세요. 이는 보안 모델을 파괴하는 행위이며, 추후 보안 인증(CTS/VTS) 통과가 불가능해집니다.
  • 불필요한 domain_human_readable 사용: 디버깅 용도로 만든 도메인을 배포 시점에 일반 도메인으로 전환하지 않으면 보안 허점이 됩니다.
  • 잘못된 파일 라벨링: /data 영역의 파일에 system_file 라벨을 붙이는 등의 행위는 지양해야 합니다. 각 파티션 용도에 맞는 라벨을 사용하세요.

4. 결론

커스텀 안드로이드 시스템 개발에서 SELinux 정책을 올바르게 정의하고 검토하는 것은 개발자의 숙명과도 같습니다. 단순히 기능을 동작시키기 위해 모든 권한을 여는 것이 아니라, AOSP 가이드라인 내에서 도구를 활용해 정밀하게 권한을 조절하는 과정이 필요합니다.

오늘 소개한 분석 도구들을 워크플로우에 통합하여, 빌드 오류 없는 안전하고 견고한 임베디드 보안 환경을 구축해 보시기 바랍니다!

반응형