여기서는 멈추세요
- 명령 출력의 서버·서비스·경로가 예상 대상과 다르면 변경 단계로 넘어가지 않습니다.
- 현재 접속 세션, 백업 또는 콘솔 복구 경로를 확보하지 못했다면 상태 변경 명령을 실행하지 않습니다.
MANDATORY ACCESS
AppArmor DENIED로 애플리케이션이 차단될 때
일반 파일 권한과 AppArmor 정책을 분리하고 DENIED 로그의 profile·operation·name을 해석해 최소 규칙만 반영합니다.apparmor DENIEDaa-statusPermission deniedAppArmor profileaudit type 1400
환경Ubuntu LTS · AppArmor enforce profile
분류웹·보안
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
변경 전 설정과 출력값을 기록하고, 예상과 다른 결과가 나오면 추가 변경을 멈춘 뒤 승인된 운영 복구 절차로 되돌립니다.
담당자에게 전달할 자료
- 장애 발생 시각·정상화 시각과 원문 오류 메시지
- 민감정보를 제거한 조회 명령 출력과 변경 전후 차이
- 조치 후 동일 조건으로 수행한 재검증 결과
BEFORE YOU START
이런 증상에서 시작합니다
- 일반 권한은 맞지만 접근 실패
- journal에 apparmor=DENIED
- 패키지·경로 변경 후 서비스 실패
- operation open·sendmsg 거부
CHECK THE BRANCH
놓치기 쉬운 원인 분기
일반 권한 오류
namei·stat·서비스 사용자 검증이 실패하면 AppArmor보다 UNIX 권한을 먼저 해결합니다.
AppArmor enforce 거부
profile, operation, name, requested_mask를 읽어 필요한 작업과 경로만 규칙 후보로 만듭니다.
명시적 deny
일부 explicit deny는 로그가 남지 않을 수 있으므로 profile의 deny 규칙과 include도 검토합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
AppArmor 활성 상태와 profile 확인
Ubuntu에서는 AppArmor가 기본 MAC 체계이므로 비활성화를 해결책으로 사용하지 않습니다.
AppArmor 상태
sudo aa-status커널 보안 모듈
cat /sys/kernel/security/lsm결과 읽기
대상 실행 파일의 profile이 enforce인지 complain인지 확인합니다.
다음 판단
profile이 없으면 일반 권한·systemd sandbox·다른 보안 계층을 확인합니다.
조회시스템을 변경하지 않는 확인 단계
장애 시각의 DENIED 레코드 수집
전체 로그를 공유하지 말고 장애 시각과 대상 profile로 범위를 좁힙니다.
최근 AppArmor 거부
sudo journalctl -k --since '-30 min' -g 'apparmor="DENIED"' --no-pageraudit 로그 사용 환경
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log | tail -50결과 읽기
profile은 적용 정책, operation은 작업, name은 대상, requested_mask와 denied_mask는 요청·거부 권한입니다.
다음 판단
정확한 profile 파일과 필요한 동작을 기록합니다.
조회시스템을 변경하지 않는 확인 단계
UNIX 권한과 profile 경로를 함께 확인
/path/to/resource와 PROFILE_NAME을 실제 값으로 바꿉니다.
일반 경로 권한
namei -l /path/to/resourceprofile 파일 후보
sudo find /etc/apparmor.d -maxdepth 2 -type f -name '*PROFILE_NAME*' -print로컬 override 디렉터리
sudo ls -la /etc/apparmor.d/local/결과 읽기
일반 권한과 AppArmor 모두 허용해야 작업이 성공합니다. 패키지 파일 직접 수정 대신 local override 지원 여부를 확인합니다.
다음 판단
허용하려는 경로를 넓은 wildcard가 아니라 필요한 최소 범위로 정합니다.
주의서버 부하나 권한을 고려할 단계
규칙 후보와 변경 전 상태 검토
aa-logprof는 로그를 바탕으로 대화형 규칙 후보를 제시하지만 모든 제안이 안전하거나 필요한 것은 아닙니다.
profile 규칙과 include 펼쳐 보기
sudo apparmor_parser -p /etc/apparmor.d/PROFILE_NAME현재 파일 checksum
sha256sum /etc/apparmor.d/PROFILE_NAME결과 읽기
쓰기·실행·네트워크 권한이 요청 목적보다 넓어지지 않았는지 diff로 확인합니다.
다음 판단
변경 전 파일과 승인된 최소 규칙을 확보합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
profile을 다시 읽고 동일 작업 재검증
profile을 disable하거나 전역 AppArmor를 끄지 않습니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
profile 원본 백업
sudo cp -a /etc/apparmor.d/PROFILE_NAME /etc/apparmor.d/PROFILE_NAME.before-change대화형 최소 규칙 검토
sudo aa-logprofprofile 재로딩
sudo apparmor_parser -r /etc/apparmor.d/PROFILE_NAMEenforce 상태 유지
sudo aa-enforce /path/to/executable새 DENIED 확인
sudo journalctl -k --since '-5 min' -g 'apparmor="DENIED"' --no-pager결과 읽기
필요 작업은 성공하고 profile은 enforce 상태이며 새로운 불필요한 DENIED가 없어야 합니다.
다음 판단
오작동하면 백업 profile을 복원하고 apparmor_parser -r로 되돌립니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.