setuid/setgid mode bit만 검색해서는 파일 capability까지 확인했다고 볼 수 없습니다. Linux는 전통적인 root 권한을 더 작은 capability 단위로 나눌 수 있고, 파일 capability는 실행 파일에 특정 능력을 연결할 수 있습니다. getcap은 파일의 capability를 표시하고 -r은 재귀 검색 옵션입니다.
capability가 발견됐다는 사실만으로 취약점이나 악성 행위를 확정하지 않습니다. 파일 소유자·패키지 출처·업무 승인·필요 권한을 확인해 과도한 권한인지 검토해야 합니다. 예시는 가상 인벤토리이며 실제 서버에서 검색하거나 설정하지 않습니다.
파일 권한 비트 목록과 capability 목록은 서로 다릅니다
setuid와 setgid는 파일 mode에서 볼 수 있는 특수 비트입니다. 하지만 Linux는 root가 전통적으로 가진 권한을 여러 capability 단위로 나누어 프로세스에 줄 수 있습니다. 파일에 setuid가 없어도 실행 파일에 별도 capability 속성이 설정될 수 있으므로, 특수 비트 검색 하나만으로 모든 권한 부여 경로를 확인했다고 말할 수 없습니다. 반대로 capability가 보인다고 파일이 반드시 실행되거나 실제 침해가 있었던 것도 아닙니다.
가상 인벤토리에서 CAP_NET_RAW 한 건을 읽습니다
| 파일 | mode 비트 | capability | 다음 질문 |
|---|---|---|---|
| /usr/local/sbin/netdiag | setuid 없음 | cap_net_raw=ep | 이 도구가 raw/packet socket을 업무상 써야 하나? |
| /usr/local/bin/report | setuid 없음 | 표시 없음 | 현재 목록 범위와 파일시스템 지원을 확인했나? |
| /usr/local/sbin/legacy | setuid 있음 | 별도 조사 필요 | 소유자·패키지·기존 승인 기록이 있나? |
Linux capabilities 매뉴얼은 CAP_NET_RAW가 RAW 및 PACKET 소켓 사용 등의 권한을 포함한다고 설명합니다. 이 capability가 netdiag에 나타나면 ‘왜 붙었는가’를 조사할 근거가 생기지만, 이름만으로 해당 파일이 공격 도구라고 결론 내릴 수는 없습니다. 네트워크 진단 프로그램이 필요로 했을 수도 있고, 오래된 패키지 설치 과정에서 남았을 수도 있으며, 잘못된 변경일 수도 있습니다. 업무 소유자와 배포 출처를 대조해야 구별할 수 있습니다.
표의 cap_net_raw=ep에서 p는 permitted, e는 effective를 나타냅니다. 파일 capability의 effective 표시는 파일 실행 시 산출된 permitted capability를 effective 집합에도 반영하도록 하는 비트입니다. 다만 실제 프로세스가 얻는 권한은 실행 규칙과 제한 조건을 함께 따릅니다. 파일에 적힌 문자열만 보고 현재 실행 중인 프로세스의 권한을 그대로 확정할 수는 없습니다.
승인된 범위에서 mode와 capability를 각각 인벤토리화합니다
- 점검 대상 파일시스템과 서비스 소유자, 허가 범위를 먼저 정합니다.
- setuid/setgid mode bit 목록과 파일 capability 목록을 별도 증거로 수집합니다.
- 각 발견 파일의 패키지 소유자, SHA-256, 변경 이력, 업무 담당자를 대조합니다.
- capability가 제공하는 정확한 기능을 해당 Linux 버전의 문서에서 확인합니다.
- 업무상 필요한 최소 권한인지 승인 기록과 비교하고, 해제는 별도 변경 승인 후 검토합니다.
Linux man-pages의 getcap 매뉴얼은 지정 파일을 표시하고 -r 재귀 검색을 지원한다고 설명합니다. 하지만 검색이 읽지 못한 디렉터리, 제외한 파일시스템, 컨테이너·mount namespace, 사용자 namespace 때문에 전체 범위가 빠질 수 있습니다. 결과에 없는 파일은 ‘검사 범위에서 발견하지 못했다’는 뜻이지, 어떤 환경에도 capability가 없다는 증명은 아닙니다.
권한 이름보다 필요한 기능과 경계를 확인합니다
Linux capability는 root의 권한을 분할하지만 각 항목의 영향 범위는 다릅니다. 이 글이 참고한 NISTIR 8176 초안은 2017년 10월 최종본으로 대체된 역사 자료이며, 현재 권고로 제시하지 않습니다. 당시 컨테이너 최소권한 설명과 별개로, 파일 capability의 동작은 직접 Linux 매뉴얼에서 확인해야 합니다. 컨테이너의 설정값과 실행 파일의 확장 속성을 같은 자료로 취급하지 마세요.
목록에 한 건이 나왔다고 취약점으로 분류하지 않습니다
흔한 실수는 getcap 결과 한 줄을 보안 사고나 취약점으로 바로 표시하는 것입니다. capability가 필요한 프로그램도 있고, 패키지 업데이트로 정상적으로 설정된 파일도 있을 수 있습니다. 반대로 승인 문서가 없다는 이유만으로 즉시 파일을 바꾸면 서비스 장애를 일으킬 수 있습니다. 발견값, 필요한 권한, 소유자 확인, 승인 상태를 별도 열로 기록하고 추가 증거가 없으면 결론은 미확인으로 남깁니다.
시험 답안에서 비트 검색과 capability 검색을 분리합니다
답안을 작성할 때는 ‘setuid/setgid 특수 비트 파일을 확인한다’와 ‘Linux file capability도 별도 도구로 조사한다’를 나누어 적습니다. 가상 결과 CAP_NET_RAW는 raw/packet socket 권한을 시사하며, 이 값이 필요한 업무인지 파일 소유자와 승인 기록을 검토해야 합니다. 한쪽 목록이 비어 있다는 사실을 다른 권한 목록까지 확인했다는 의미로 확장하지 마세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
setuid/setgid 파일 목록은 비어 있지만 승인된 재귀 getcap 인벤토리에 가상 netdiag 파일과 cap_net_raw=ep가 보입니다. 무엇을 결론 내리고 무엇을 더 확인해야 하나요?
정답과 해설 확인
mode-bit 목록만으로 권한 점검이 끝났다고 할 수 없습니다. CAP_NET_RAW의 필요성, 파일 출처·소유자·승인 범위와 실제 점검 범위를 확인하되 발견만으로 침해를 단정하지 않습니다.Linux capability는 특수 mode bit와 다른 권한 분할 경로입니다. getcap은 파일 capability를 표시하지만 결과의 위험도는 사용 목적·파일 출처·환경을 확인한 뒤 평가해야 합니다.