QNX RTOS: 1-10. Security

QNX의 보안 모델은 크게 익숙한 POSIX 표준 권한 모델과 QNX만의 고유한 기능인 능력(Abilities) 및 보안 정책(Security Policies)으로 나뉨.

1. 기본 보안: POSIX 파일 권한 (File Permissions)

QNX는 기본적으로 Unix/Linux와 동일한 POSIX 표준 파일 권한을 사용함.

• 모델: ls -l로 확인 가능한 rwx(Read/Write/Execute) 권한.
• 대상: 파일, 디렉토리, 그리고 QNX의 특징인 장치(Devices, /dev/*)까지 모두 파일로 취급되므로 이 권한 체계가 적용됨.
• 구분: User, Group, Other에 대한 접근 제어.

2. 개발 환경 vs 배포 환경의 리스크 관리

2.1. IFS와 Root 권한

초기 개발 단계에서 빌드하는 IFS(Image File System) 내의 모든 프로세스는 기본적으로 Root(UID 0) 권한으로 실행됨. 이는 개발 편의성을 높여주지만, 보안상 최악의 설정임. 제품 배포 시에는 반드시 최소 권한 원칙을 적용해야 함.

2.2. 위험한 도구: qconn

qconn은 Momentics IDE와 타겟 보드를 연결해 파일 복사, 디버깅(pDebug 실행) 등을 담당하는 에이전트임.

• 문제점: qconn은 기본적으로 Root 권한으로 실행됨.
• 주의사항: 개발 중에는 필수적이지만, 실제 상용 제품(Production) 이미지에는 절대로 qconn을 포함시키면 안 됨. 해커에게 Root 쉘을 열어주는 것과 다름없음.

2.3. Root 권한 제한 방법

프로세스가 UID 0(Root)으로 실행되는 것을 막기 위해 다음과 같은 기법들을 사용함.

• Launcher 프로그램 사용: 별도의 실행기가 권한을 낮춰서 앱을 실행.
• login 유틸리티 사용.
• setuid() API 사용: 코드로 명시적인 권한 변경.

3. 권한의 세분화: Abilities (능력)

"Root냐 아니냐"라는 이분법적인 접근(Coarse-grained)은 보안에 취약함. 특정 하드웨어 하나만 제어하면 되는 앱에 시스템 전체 통제권(Root)을 주는 것은 위험하기 때문임. QNX는 이를 해결하기 위해 Abilities라는 개념을 도입함.

3.1. Abilities란?

Process Manager(procnto)가 관리하는 특정 작업 수행 능력임. Root 권한을 쪼개 놓은 것이라고 이해하면 됨.

• 예시: 인터럽트 제어, I/O 포트 접근, 메모리 매핑(mmap), 타이머 설정, 스레드 우선순위 변경 등.
• 동작 원리: Root 프로세스는 모든 Ability를 다 가짐. Non-root 프로세스는 필요한 Ability만 선별적으로 가질 수 있음.

3.2. 제어 함수: procmgr_ability()

개발자는 C 코드 레벨에서 이 함수를 통해 프로세스가 가진 능력을 확인하거나 제어할 수 있음. 하지만 일일이 코드로 제어하는 것은 관리하기 어렵고 실수할 여지가 많음.

4. 보안의 완성: Security Policies (보안 정책)

Abilities를 개별적으로 설정하는 번거로움을 해결하고, 시스템 전체의 보안 무결성을 보장하기 위해 Security Policies를 사용함.

4.1. secpolgenerate (자동 생성 도구)

보안 정책을 처음부터 손으로 짜는 것은 매우 힘듦. QNX는 이를 자동화해주는 도구를 제공함.

1. 최소한의 시스템을 구동함.
2. secpolgenerate 툴을 실행함.
3. 툴이 시스템을 감시(Observe)하면서, 각 프로세스가 실제로 어떤 리소스(메모리, I/O 등)를 요청하고 어떤 행동을 하는지 추적함.
4. 관찰된 행동을 바탕으로 정책 파일(텍스트 포맷)을 자동으로 생성해 줌.

4.2. 정책 적용

• 생성된 정책 파일은 시스템 통합자(System Integrator)가 수정하거나 검토할 수 있음.
• 이 파일은 부팅 시 커널에 의해 로드됨.
• 커널은 이 정책에 따라 각 프로세스에게 딱 필요한 만큼의 권한(Abilities)만 부여함.

결과적으로, 어떤 프로세스가 해킹당하더라도 정책에 정의되지 않은 행동(예: 뜬금없이 네트워크 소켓을 연다거나, 커널 메모리를 건드리는 행위)은 커널 레벨에서 차단됨.

---

💡 정리 및 인사이트 (Zero Trust 관점)

1. 최소 권한의 원칙 (Least Privilege): Root 권한을 남용하지 말고, Abilities를 통해 딱 필요한 권한만 부여해야 함.
2. Zero Trust 구현의 핵심: 네가 연구하는 ZTHA 아키텍처에서, 각 Guest OS나 애플리케이션을 격리할 때 이 Security Policy가 핵심적인 역할을 할 것임.
3. 자동화된 보안: secpolgenerate를 사용하면 "정상적인 동작"을 화이트리스트 기반으로 정책화할 수 있음. 이는 알려지지 않은 공격을 방어하는 데 매우 효과적임.