Android System & AOSP Engineering/Android Automotive

AOSP SEAndroid SELinux 권한 에러 해결: avc: denied 오디트(Audit) 로그 분석 및 .te 정책 파일 작성 가이드

임베디드 친구 2026. 8. 12. 20:42
반응형

1. AOSP 안드로이드 시스템 개발 시 SEAndroid(SELinux) 권한 거부(Access Denied) 이슈 발생 배경

Android Open Source Project(AOSP) 환경에서 신규 디바이스 드라이버를 추가하거나 시스템 서비스(System Service)를 통합할 때 SEAndroid(Security-Enhanced Android) 권한 거부 문제가 빈번히 발생합니다. 액세스 거부 오류가 발생하면 HAL(Hardware Abstraction Layer) 또는 Daemon 프로세스가 정상적으로 동작하지 못하고 초기화 단계에서 종료됩니다.대부분의 엔지니어는 보안 모드를 permissive로 설정하여 문제를 우회하지만, 상용 빌드(User Build)에서는 enforcing 모드가 강제되므로 반드시 올바른 .te(Type Enforcement) 정책 파일을 작성해야 합니다.본 가이드는 Kernel Audit 로그 분석법과 audit2allow 도구를 활용하여 SEAndroid 정책을 올바르게 정의하는 방법을 다룹니다.

2. SEAndroid Audit 로그 분석 및 .te 정책 수정 핵심 요약 (Technical Summary)

  • Audit Log Detection: Kernel log (dmesg) 또는 Logcat에서 avc: denied 검색을 수행하여 차단된 원인 Process(scontext), Target Resource(tcontext), Object Class(tclass), Permission(action) 정보를 추출합니다.
  • Policy Rule Generation: Audit 로그를 audit2allow -i log.txt 명령어로 분석하여 차단된 접근 권한에 부합하는 allow [scontext] [tcontext]:[tclass] { [permission] }; 구문을 생성합니다.
  • Build & Verification: 수정된 .te 파일을 device///sepolicy 경로에 반영 후 m mmma system/sepolicy 명령어로 컴파일하고 setenforce 1 상태에서 정상 동작 여부를 검증합니다.

3. SEAndroid(SELinux) 구조 분석 및 avc: denied 로그 기반 .te 정책 구현

3.1 SELinux 동작 모드 (Permissive vs Enforcing) 비교 분석

구분 (Mode) 보안 규격 적용 여부 (Enforcement) Audit 로그 생성 여부 (Log Generation) 주요 사용 환경 (Primary Usage)
Disabled 미적용 (보호 기능 비활성화) 생성 안 함 개발 초기 단계 (사용 권장하지 않음)
Permissive 미적용 (접근 허용 후 로그만 기록) 생성함 (avc: denied) 신규 드라이버/서비스 개발 및 디버깅 단계
Enforcing 적용 (정책 위반 시 접근 차단) 생성함 (avc: denied) 상용 양산 빌드 (User Build Default)

3.2 Kernel Audit Log (avc: denied) 구문 해석

디바이스 드라이버 노드(/dev/custom_dev) 접근 시 발생하는 대표적인 Audit 로그 예시는 다음과 같습니다.

type=1400 audit(0.0:25): avc: denied { read write open } for pid=1234 comm="custom_service" path="/dev/custom_dev" dev="tmpfs" ino=15234 scontext=u:r:custom_service:s0 tcontext=u:object_r:custom_dev_device:s0 tclass=chr_file permissive=0

위 로그를 분석하여 .te 파일 규칙으로 변환하는 매핑 구조는 다음과 같습니다.

Audit Log 요소 값 (Value) SELinux 의미 .te 파일 매핑 위치
scontext u:r:custom_service:s0 Subject Context (요청 프로세스 Domain) Allow 구문의 주어 (custom_service)
tcontext u:object_r:custom_dev_device:s0 Target Context (대상 리소스 Type) Allow 구문의 목적어 (custom_dev_device)
tclass chr_file Target Class (객체 유형) Allow 구문의 Class (chr_file)
denied { read write open } Blocked Permissions (차단된 권한 목록) Allow 구문의 Permission ({ read write open })

3.3 C++ Daemon 및 .te Policy 파일 구체적 작성 예시

새로운 캐릭터 디바이스 드라이버를 제어하기 위한 custom_service.te 및 file_contexts 구성 예시입니다.
1) file_contexts 파일 설정 (Device Node Labeling)

# Device node label mapping
/dev/custom_dev    u:object_r:custom_dev_device:s0

2) device.te 파일 설정 (Type Declaration)

# Define new device type
type custom_dev_device, dev_type;

3) custom_service.te 파일 설정 (Domain Definition & Allow Rules)

# Define domain for custom service
type custom_service, domain;
type custom_service_exec, exec_type, vendor_file_type, file_type;

# Init domain transition
init_daemon_domain(custom_service)

# Allow custom_service to access custom_dev_device character file
allow custom_service custom_dev_device:chr_file { read write open ioctl };

# Allow logging to logcat
binder_use(custom_service)

4. AOSP SEAndroid 디버깅 및 실무 개발 팁

  • audit2allow 자동 변환 도구 활용: Android 빌드 환경 세팅 후 아래 명령어를 실행하면 Audit 로그에서 직접 .te 규칙을 추출할 수 있습니다.
adb shell dmesg | grep "avc: denied" | audit2allow -p out/target/product/<board>/root/sepolicy
  • permissive_or_untyped() 메크로 활용: 새로운 Domain 개발 초기 단계에 전체 시스템을 permissive로 변경하지 않고, 해당 Domain만 단독으로 permissive 상태로 설정하여 디버깅할 수 있습니다.
# Set specific domain to permissive mode for debugging
permissive custom_service;
  • sepolicy-analyze를 통한 Neverallow 위반 검증: AOSP 메인 정책(system/sepolicy)에 정의된 neverallow 규칙을 위반할 경우 빌드 에러가 발생합니다. 작성한 정책이 neverallow에 위반되는지 사전에 검증합니다.

5. SEAndroid 정책 작성 시 흔히 하는 실수 및 해결책

  • neverallow 규칙 위반 (System Server / Shell Domain 권한 과도 부여):

    • 현상: 빌드 타임에 SELinux neverallow check failed 오류가 발생하며 AOSP 빌드가 실패합니다.
    • 원인: system_server 또는 app 도메인에 /dev/ 노드 직접 접근 권한을 부여하거나 untrusted_app에 raw socket 접근 권한을 부여했기 때문입니다.
    • 해결 방법: Direct HAL(Binderized HAL) 구조를 도입하여 권한을 격리하거나 vendor_init을 통해 하위 인프라에서 처리하도록 설계 구조를 변경합니다.
  • file_contexts 적용 후 SELinux Label 미갱신:

    • 현상: .te 파일 및 file_contexts 설정을 마쳤으나 여전히 avc: denied 오류가 발생합니다.
    • 원인: 런타임 파일 시스템 상의 기존 파일/디바이스 노드에 새로운 Security Context Label이 반영되지 않았기 때문입니다.
    • 해결 방법: restorecon 명령어를 실행하여 파일 라벨을 강제로 재설정합니다.
adb shell restorecon -R /dev/custom_dev

6. AOSP SEAndroid(SELinux) 정책 에러 해결 결론S

EAndroid(SELinux)는 AOSP의 커널 및 시스템 보안을 유지하는 핵심 매커니즘입니다. avc: denied Audit 로그의 scontext, tcontext, tclass, permission 구성을 정확히 분석하면 상용 빌드 환경에서도 보안 정책 위반 없이 안전하게 신규 드라이버 및 서비스를 통합할 수 있습니다.

반응형