QNX RTOS: 3. Security Policies

개발자가 작성한 코드가 최종적으로 어떤 하드웨어 환경에서, 어떤 목적으로 쓰일지 개발 당시에는 알 수 없음. QNX Security Policy는 이러한 불확실성을 해결하고, 보안의 책임을 개별 개발자가 아닌 시스템 통합자(System Integrator)에게 부여하는 강력한 메커니즘임.

1. 왜 Security Policy가 필요한가?

1.1. 개발자의 한계

드라이버나 파일 시스템을 개발하는 개발자는 최종 시스템의 환경을 완벽히 알 수 없음.

• Serial Driver 예시: 개발자는 코드를 짤 때 이 드라이버가 몇 번 인터럽트를 쓸지, 컨트롤 레지스터의 물리 주소가 어디인지 모름. 이건 실행 시 인자(Argument)로 결정됨.
• File System 예시: 개발자는 동적 마운트(USB 연결 등) 기능을 넣었지만, 실제 시스템은 정적인 환경이라 런타임에 마운트 기능이 필요 없을 수도 있음.

1.2. 책임의 이동

개별 컴포넌트가 알아서 보안을 챙기는 건 불가능함. 최종 시스템의 보안은 System Integrator가 책임져야 함. Security Policy는 보안 설정을 코드에서 분리하여 텍스트 파일 형태의 정책으로 만들고, 이를 통합자가 제어할 수 있게 해주는 도구임.

2. Security Policy의 정체와 툴체인

Security Policy는 기본적으로 호스트상의 텍스트 파일로 존재하며, 컴파일되어 타겟에 로드됨.

2.1. 정책 파일의 라이프사이클

1. Text Policy (*.txt): 사람이 읽을 수 있는 형태로 보안 규칙 정의.
2. Binary Policy: 툴을 통해 컴파일된 바이너리 형태.
3. Kernel Load: 부팅 시 커널(procnto)에 로드되어 시스템 전체의 보안 상태를 강제함.

2.2. 핵심 툴체인 (Software Components)

• secpolcompile (Host): 텍스트 정책을 바이너리로 컴파일함. 기능 안전(Safety Qualified) 도구임.
• secpolpush (Target): 바이너리 정책을 커널에 밀어 넣음. 기능 안전 인증(Safety Certified) 받음.
• secpol (Target): 디버깅 및 정보 확인용 유틸리티. (인증 안 됨)
• libsecpol.so (Target): 정책을 프로그래밍적으로 다룰 수 있는 API 라이브러리. (Safety Certified)
• secpolgenerate (Host/Target): 테스트 시스템을 돌리면서 프로세스들이 하는 행동을 관찰하고, 이를 바탕으로 초기 정책 파일을 자동으로 생성해줌. (매우 유용함)
• secpollaunch: 낮은 권한의 프로세스가 높은 권한이 필요한 프로세스를 안전하게 실행시킬 때 사용하는 쐐기(Wedge) 역할의 도구.

3. 개발자의 의무: 코드는 어떻게 짜야 하는가?

통합자가 정책을 잘 짤 수 있도록, 개발자는 코드 레벨에서 두 가지를 지원해줘야 함.

3.1. Privilege Transition (권한 전이) 지원

대부분의 데몬이나 드라이버는 생명주기가 두 단계로 나뀜.

1. Initialization (초기화): 하드웨어 매핑, 인터럽트 연결 등 높은 권한이 필요함.
2. Operation (운영): 초기화가 끝나면 실제 서비스만 하면 되므로 낮은 권한이면 충분함.

개발자는 초기화가 끝나는 시점에 secpol_transition_type(NULL, NULL, 0) 함수를 호출해야 함.

• 이 함수가 호출되면 프로세스의 보안 타입(Type)이 변경됨 (예: random_t -> random_t__run).
• 즉, 초기화 때 썼던 강력한 권한(Ability)을 버리고, 운영에 필요한 최소 권한만 남기게 됨. (Least Privilege 원칙 구현)

3.2. 리소스 매니저 등록 방식 변경

리소스 매니저가 /dev/ser1 같은 경로를 생성할 때 resmgr_attach 대신 secpol_resmgr_attach를 사용해야 함.

• resmgr_attach: 개발자가 코드에 권한(777, 755 등)을 하드코딩하거나 추측해서 넣어야 함.
• secpol_resmgr_attach: 권한 설정을 정책 파일에 위임함. 통합자가 정책 파일에서 "이 디바이스는 root만 읽을 수 있음"이라고 정하면 그대로 적용됨.

4. 정책 파일의 구조 (예시 분석)

정책 파일은 'Type'과 'Rule'로 구성됨. 영상에 나온 random 프로세스 예시를 분석해봄.

• Type 정의:
  • type random_t: 초기화 단계의 타입.
  • type random_t__run: 운영 단계의 타입.
• Allow Rule (권한 부여):
  • allow random ability ...: random_t에게 메모리 매핑, 인터럽트 사용 등 강력한 권한 부여.
  • set type id: 타입 변경 권한 부여.
• Derived Type (전이 규칙):
  • derived type random_t random_t__run: secpol_transition_type이 호출되면 random_t는 자동으로 random_t__run으로 변신함.
• 런타임 권한 축소:
  • random_t__run 타입에는 srandom (커널에 시드값 넣기) 권한 딱 하나만 부여됨.
  • 결과적으로 해커가 운영 중인 random 프로세스를 탈취해도, 메모리를 맵핑하거나 다른 짓을 할 수 없음.

 

---

💡 요약 및 인사이트 (Zero Trust 관점)

1. 책임의 분리: 개발자는 기능 구현에 집중하고, 보안 정책은 시스템 통합자가 전담하도록 구조화됨.
2. 동적 권한 축소: Initialization -> Operation 단계로 넘어갈 때 권한을 스스로 버리는 메커니즘은 Zero Trust의 최소 권한 원칙(Least Privilege)을 시스템 레벨에서 강제하는 아주 훌륭한 예시임.
3. 자동화: secpolgenerate를 통해 "정상 행위"를 학습하고 이를 정책으로 만듦으로써, 알려지지 않은 행위(이상 징후)를 원천 차단하는 화이트리스트 보안을 구축할 수 있음.