신뢰의 아키텍처: 증명 가능한 보안 운영체제 (PSOS)를 다시 살펴보다
1979년, SRI International의 Richard J. Feiertag와 Peter G. Neumann은 "The foundations of a provably secure operating system (PSOS)"를 발표했습니다. 클라우드 컴퓨팅과 도처에 깔린 멀웨어의 현대적 시대가 도래하기 수십 년 전에 작성되었음에도 불구하고, 이 논문은 여전히 놀라울 정도로 유의미한 운영체제 보안에 대한 비전을 제시합니다. PSOS의 핵심은 단순히 기존 커널에 보안 기능을 추가하는 것이 아니라, 보안 속성이 수학적으로 증명될 수 있도록 형식적 방법(formal methods)을 사용하여 기초부터 시스템을 구축하는 것이었습니다.
계층적 개발 방법론 (HDM)
PSOS는 SRI Hierarchical Development Methodology (HDM)를 사용하여 설계되었습니다. 많은 운영체제에서 흔히 볼 수 있는 임시방편적인(ad-hoc) 개발과 달리, HDM은 공식적으로 명시된 요구사항과 사양에 의존합니다. 시스템은 계층적으로 조직된 모듈의 집합으로 구조화되어 있으며, 각 모듈의 설계는 SPECIAL이라는 언어를 사용하여 공식적으로 명시됩니다.
이 접근 방식은 두 단계의 형식적 검증 프로세스를 가능하게 합니다:
- 사양 검증 (Specification Verification): 공식 사양(formal specifications)이 원하는 보안 요구사항을 충족하는지 증명합니다.
- 구현 검증 (Implementation Verification): 실제 프로그램(하드웨어, 펌웨어 또는 소프트웨어)이 해당 사양과 일치하는지 증명합니다.
핵심 메커니즘: Capability
PSOS의 결정적인 특징은 capabilities의 균일한 사용입니다. PSOS에서 capability는 객체에 대한 접근 권한을 부여하는 위조 불가능한 토큰입니다. 프로세스가 객체에 대한 capability를 보유하지 않으면, 어떤 경우에도 해당 객체에 접근할 수 없습니다.
Capability의 구조
각 capability는 두 개의 불변하는 부분으로 구성됩니다:
- Unique Identifier (UID): 객체를 고유하게 식별하는 시스템 생성 ID입니다.
- Access Rights: 허용되는 작업(read, write, execute, delete)을 정의하는 Boolean array입니다.
집행 및 보안
프로그램이 자체적으로 capability를 위조하는 것을 방지하기 위해, PSOS는 tagging을 채택합니다. Capability는 프로세서와 메모리 내의 사용자 프로그램이 접근할 수 없는 태그 비트(tag bit)로 표시됩니다. 이를 통해 capability가 변경되거나 무에서 생성되는 것을 방지합니다. capability는 시스템에 의해 생성되거나, 기존 capability로부터 restrict_access 작업을 통해 파생될 수만 있습니다. 이 작업은 권한을 제거할 수는 있지만 결코 추가할 수는 없습니다 (단조성 규칙, monotonicity rule).
추상화 및 Type Manager
PSOS는 기능을 Level 0 (Capabilities)부터 Level 16 (User Request Interpretation)까지의 추상화 계층으로 조직합니다. 이를 통해 시스템은 원시 물리적 자원(레지스터 및 인터럽트 등) 위에 복잡한 복잡한 가상 자원(디렉토리 및 사용자 프로세스 등)을 구축할 수 있습니다.
여기서 핵심적인 혁신은 Type Manager입니다. Type manager는 특정 유형의 객체를 담당하는 프로그램입니다. 이는 capability의 UID를 추상 객체의 실제 표현으로 매핑합니다. capability 메커니즘이 매우 단순하고 시스템의 최하위 레벨에 위치하기 때문에, 아키텍처의 모든 레벨에서 균일하게 사용될 수 있으며, 다양한 유형의 시스템 객체를 위한 특수 목적 시설의 필요성을 제거합니다.
PSOS vs. 커널 방식
Feiertag와 Neumann은 PSOS를 당시 다른 보안 시스템에서 흔히 사용되던 "커널" 아키텍처와 대조합니다. 전통적인 커널 방식에서는 보안 정책을 집행행하는 작고 필수적인 코드 조각(커널)이 격리되어 있습니다.
하지만 저자들은 이것이 종종 "신뢰 프로세스(trusted processes)"로 이어짐을 주장합니다. 즉, 커널 외부의 프로그램이지만 보안을 위해 필수적임에도 불구하고 그렇게 표시되지 않은 프로그램들을 의미합니다. 이는 실제 TCB (Trusted Computing Base)를 비대대하게 만들고 검증을 복잡하게 만듭니다.
PSOS는 다른 경로를를 택합니다. 단일하고 경직된 커널이 하나의 정책을 집행하는 대신, PSOS는 매우 확장 가능한 프레임워크를 제공합니다. 이는 여러 서브시스템을 생성할 수 있게 하여, 각 서브시스템이 특정 작업을 위한 "커널" 역할을 수행하게 함으로써, 시스템이 잠재적으로 충돌할 수 있는 여러 보안 정책을 동시에 지원할 수 있도록 합니다.
현대적 성찰: 인터넷 시대
PSOS가 1979년의 이론적 토안이었을 때, 그 철학학은 현대적 보안 위협에 공지합니다. Hacker News 토론의 댓글에서 사용자들은 현재 업계가 안티바이러스 소프트웨어, 시그니처, 앱스토어 검증과 같은 계층적 방식에 의존하는 것이 근본적인 아키텍처적 결차함: capability-based system의 부재에 대한 반응적 접근 방식이라고 지적했습니다.
"1979년에... capability OS 아키텍처가 왜 무관하게 느껴졌을지 이해합니다... 하지만 그 이후로는, 어디서든 무엇이든 다운로드하고 실행할 수 있는 인터넷 시대에 적합한 유일한 아키텍처처럼 들립니다... 프로그램이 기본적으로 아무것에도 접근할 수 없도록 만드는 것입니다."
오늘날 우리는 가상화 및 컨테이너화(예: Docker)의 부상에서 PSOS 철학의 메아리를 봅니다. 컨테이너 내에서 프로그램을 격리함으로써, 개발자들은 수십 년 전 PSOS가 제안한 capability-based isolation의 투박한 버전을 효과적으로 구축하고 있습니다. 이는 서드파티 패키지의 멀웨어 위험을 완체화하기 위해 프로세스가 기본적으로 무엇을 "볼 수" 있고 "만질 수" 있는지 제한하는 것입니다.
PSOS를 다시 살펴봄으로써, 우리는 진정으로 보안한 시스템을 구축하는 길은 더 많은 보안 소프트웨어를 추가하는 것이 것이 아니라, 보안이 시스템 자체의 내재적이고 증명 가능한 속성이 되도록 아키텍처를 설계하는 데 있음을 상기하게 됩니다.