안드로이드 시스템 개발이나 커스텀 펌웨어 제작 시, 새로운 바이너리를 실행하거나 특정 하드웨어 노드에 접근할 때 'Permission Denied' 에러로 골머리를 앓는 경우가 많습니다. 대부분은 리눅스 기본 권한(chmod) 문제가 아니라 안드로이드의 핵심 보안 메커니즘인 SELinux(Security-Enhanced Linux)에 의한 차단입니다. SELinux는 시스템 보안을 획기적으로 높여주지만, 개발 단계에서는 까다로운 장벽이 되기도 합니다.
본 포스팅에서는 dmesg와 logcat을 활용해 SELinux 차단 로그를 실시간으로 모니터링하고, 발생한 avc: denied 메시지를 분석하여 문제를 해결하는 실무 디버깅 기법을 상세히 다루겠습니다.
📌 핵심 요약 3줄
- 로그 수집 도구: 커널 레벨의 dmesg와 안드로이드 시스템 레벨의 logcat을 활용해 avc: denied 로그를 필터링합니다.
- 모드 전환 테스트: getenforce와 setenforce 명령어를 통해 SELinux 강제(Enforcing) 모드와 허용(Permissive) 모드를 오가며 원인을 식별합니다.
- 해결 전략: 로그 분석 결과를 바탕으로 audit2allow로 신규 정책을 생성하거나, chcon을 통해 객체의 보안 컨텍스트를 수정합니다.
1. SELinux 디버깅 필수 도구 및 상태 확인
디버깅을 시작하기 전, 현재 시스템의 SELinux 동작 상태를 파악하는 것이 우선입니다.
[SELinux 디버깅 주요 명령어 모음]
| 명령어 | 용도 | 비고 |
| adb shell getenforce | 현재 SELinux 동작 모드 확인 | Enforcing(강제), Permissive(허용) |
| adb shell setenforce 0 | Permissive 모드로 일시 전환 | 재부팅 시 초기화됨 |
| adb shell dmesg | grep avc | 커널 메시지 내 SELinux 차단 로그 확인 | 가장 정확한 로우 레벨 로그 |
| adb logcat -b all | grep avc | 시스템 전체 로그 내 차단 로그 확인 | 앱 관련 차단 로그 확인 시 용이 |
| adb shell ls -Z [경로] | 파일/디렉터리의 보안 컨텍스트 확인 | 라벨링(Labeling) 상태 점검 |
2. avc: denied 로그 정밀 분석
차단 로그 한 줄에는 문제 해결을 위한 모든 정보가 담겨 있습니다. 예제 로그를 통해 각 필드를 뜯어보겠습니다.
예제 로그:
[ 123.45] avc: denied { read } for pid=1234 comm="my_app" name="example_file" scontext=u:r:untrusted_app:s0 tcontext=u:object_r:example_data_file:s0 tclass=file permissive=0
[SELinux 거부 로그 필드 상세 해설]
| 필드명 | 의미 | 상세 분석 |
| denied { read } | 차단된 동작 | 프로세스가 읽기(read)를 시도하다가 거부됨 |
| comm="my_app" | 주체 프로세스 | 접근을 시도한 실행 파일 이름 |
| scontext | Source Context | 요청 프로세스의 보안 라벨 (누가?) |
| tcontext | Target Context | 접근 대상 리소스의 보안 라벨 (무엇을?) |
| tclass | Target Class | 리소스의 종류 (file, dir, socket 등) |
| permissive=0 | 강제 적용 여부 | 0이면 실제로 차단됨, 1이면 로그만 남기고 허용됨 |
3. 실무 문제 해결 프로세스
로그 분석이 끝났다면 다음 세 가지 방법 중 상황에 맞는 해결책을 선택합니다.
[SELinux 이슈 해결 전략]
| 해결 방법 | 적용 상황 | 명령어 예시 |
| 방법 1. 정책 추가 | 정상적인 서비스인데 권한만 없는 경우 | audit2allow -i [로그파일] -M [모듈명] |
| 방법 2. 라벨 수정 | 대상 파일의 보안 컨텍스트가 잘못된 경우 | chcon u:object_r:[타입]:s0 [파일경로] |
| 방법 3. 모드 테스트 | 코드 문제인지 보안 문제인지 헷갈릴 때 | setenforce 0 후 동작 여부 재확인 |
💡 개발을 위한 팁
- 연쇄 로그 수집: Enforcing 모드에서는 첫 번째 차단 지점에서 프로세스가 멈춰 이후의 차단 로그를 볼 수 없습니다. setenforce 0으로 만든 뒤 프로세스를 끝까지 실행시켜 필요한 모든 로그를 한 번에 수집하는 것이 효율적입니다.
- Context 유지: chcon 명령어는 일시적인 변경입니다. 영구적으로 라벨을 적용하려면 file_contexts 설정 파일에 경로와 라벨을 등록해야 합니다.
- dmesg의 시간차: logcat은 버퍼가 금방 찰 수 있으므로, 부팅 직후의 로그나 커널 레벨의 이슈는 dmesg를 우선적으로 확인하세요.
⚠️ 흔히 하는 실수
[SELinux 디버깅 시 주의사항]
| 실수 유형 | 상세 내용 | 올바른 접근 |
| 무분별한 allow 적용 | audit2allow가 주는 대로 모든 권한을 다 허용함 | 보안 위협이 없는지 검토 후 최소 권한만 부여 |
| Permissive 모드 배포 | 개발 편의를 위해 배포용 빌드에서도 Permissive를 유지함 | CTS 인증 실패 및 보안 취약점의 주범. 반드시 Enforcing 유지 |
| Neverallow 무시 | AOSP 기본 정책(Neverallow)을 어기는 정책을 추가하려 함 | 빌드 에러 발생. 이 경우 도메인을 분리하거나 설계를 변경해야 함 |
4. 마무리
SELinux는 안드로이드의 보안을 책임지는 든든한 가드레일이지만, 개발자에게는 때로 넘기 힘든 벽처럼 느껴지기도 합니다. 하지만 오늘 살펴본 것처럼 dmesg와 logcat을 통해 원인을 분석하고, 표준 해결 절차를 따른다면 어떤 보안 이슈도 명쾌하게 해결할 수 있습니다.
작업 중에 도저히 풀리지 않는 독특한 avc: denied 로그가 나타난다면 댓글로 남겨주세요. 함께 고민하고 해결책을 찾아보겠습니다!
'Android System & AOSP Engineering > Android Security & SELinux' 카테고리의 다른 글
| SELinux 정책 최적화 가이드: 성능과 보안을 모두 잡는 5가지 기법 (0) | 2025.05.14 |
|---|---|
| 안드로이드 SELinux 보안의 핵심: neverallow 정책 개념 및 활용 가이드 (0) | 2025.05.13 |
| 안드로이드 SELinux 정책 생성 가이드: audit2allow 활용법 및 검증 정리 (0) | 2025.05.11 |
| 안드로이드 SELinux avc: denied 로그 분석 및 해결 완벽 가이드 (0) | 2025.05.10 |
| Android Third-party 앱 SELinux 정책 가이드: untrusted_app과 isolated_app 차이점 (0) | 2025.05.09 |