요약

  • Amoeba의 케이퍼빌리티는 128비트 무기명 참조였다. 48비트 서버 포트, 24비트 객체 번호, 8비트 권한 맵, 48비트 검사 필드가 결합되어 중앙 케이퍼빌리티 관리자 없이 명명, 허용 연산, 검증을 처리했다.
  • 토큰을 수락한 서버는 그 필드들이 서버의 검증 규칙을 충족하고 요청된 연산이 권한 비트 범위 안에 있음을 확인했다. 그러나 명명된 보유자, 승인된 목적, 완료된 하류 효과, 영속적 저장을 입증하지는 않았다.

가장 중요한 사실은 빠진 필드 안에 있었다

한 프로세스가 압축된 비트 패턴을 들고 Amoeba 서버에 접근했다. 서버 포트는 요청을 특정 서비스로 안내했다. 객체 번호는 그 서버가 알고 있는 하나의 객체를 선택했다. 권한 비트는 보유자가 어떤 연산을 요청할 수 있는지 말해 주었다. 검사 필드는 서버가 위조된 토큰이나 권한 확장 시도를 탐지하게 했다.

거기에는 ‘사람’ 필드가 없었다.

이 부재는 신원 레지스트리를 기다리던 누락이 아니었다. 그것은 메커니즘의 일부였다. Amoeba는 케이퍼빌리티를 중앙 커널 기능으로 보호하지 않고 사용자 프로세스가 직접 다룰 수 있는 분산형 명명·보호 모델을 추구했다. 권한은 참조와 함께 이동했다. 유효하고 충분한 권한을 지닌 케이퍼빌리티를 소유한 프로세스는 그것을 제시할 수 있었다. 서버가 검증한 것은 경력이 아니라 케이퍼빌리티였다.

이 설계는 ‘수락된 모든 자격 증명이 모든 승인 질문에 답하는 것처럼 다루는’ 반복되는 운영 오류에 대한 유용한 역사적 해독제다. Amoeba의 케이퍼빌리티는 정확한 질문에 답했다 — 보유자가 이 서버에 대해 이 객체에 대한 이 연산을 요청할 수 있는가? 그러나 조직적 관점에서 보유자가 누구인지, 요청이 왜 이루어졌는지, 승인자가 그것을 의도했는지, 이후 실제 결과가 발생했는지는 답하지 않았다.

네 개의 필드, 네 개의 한정된 역할

1986년 논문Using Sparse Capabilities in a Distributed Operating System은 이 형식을 정확히 제시한다. 케이퍼빌리티는 48비트 서버 포트, 24비트 객체 번호, 8비트 권한 필드, 48비트 검사 필드를 담는다. 총 128비트다.

서버 포트와 객체 번호는 서로 다른 역할을 수행한다. 포트는 Amoeba의 RPC 모델에서 서비스 엔드포인트를 식별한다. 객체 번호는 그 서비스 내부에서만 의미를 가지며, 1991년 상태 보고서는 파일 서버의 객체 번호를 inode 번호에 비유한다. 커널은 포트로 서버를 찾을 수 있지만 나머지 케이퍼빌리티는 서버에 그대로 전달한다. 따라서 위치 지정과 객체 해석은 분리된 채 유지된다.

권한 바이트는 보편적인 8개 명령 헌법이 아니다. 그 의미는 서버의 객체 인터페이스에서 오는 비트맵이다. 파일 객체는 읽기, 쓰기, 삭제를 노출할 수 있고, 프로세스 객체는 시작, 정지, 검사를 노출할 수 있다. 같은 필드 폭이라고 그 연산들이 동등해지는 것은 아니다. 각 서비스에 보유자 권한을 선언할 작고 명시적인 표면을 제공할 뿐이다.

검사 필드는 그 선언을 보호한다. Amoeba는 일반 프로세스가 케이퍼빌리티를 저장하고 복사할 수 있게 했으므로, 토큰은 접근 불가능한 커널 태그에 의존할 수 없었다. 서버는 객체 비밀값을 보관하고 일방향 변환을 사용해 제출된 검사값이 표시된 객체·권한 값과 짝을 이루는지 검증했다. 클라이언트는 메모리에서 권한 비트를 바꿀 수 있지만, 그렇게 해서 대응하는 유효한 검사 필드를 만들어 낼 수는 없었다.

이 때문에 ‘위조 불가능한 참조’라는 표현에는 신중한 문구가 필요하다. 역사적 구성은 자신의 가정 아래에서 위조를 비현실적으로 만들도록 설계되었다. 그러나 이는 오늘날의 공격 규모에 맞서 48비트 필드를 보증하거나, 승인된 보유자에게서 복사된 토큰을 보호하거나, 안전하지 않은 채널에 노출된 케이퍼빌리티를 암호화하는 것은 아니다. 1991년 보고서 자체도 안전하지 않은 환경에서 우발적 유출을 막기 위해 암호화가 필요할 수 있다고 적는다.

권한 축소는 뺄셈이었지 위임 연극이 아니었다

소유자 케이퍼빌리티는 모든 권한 비트가 켜진 상태로 시작한다. 다른 프로세스에 더 적은 권한을 주려면, 보유자는 서버에 마스크로 제한을 요청할 수 있었다. 서버는 먼저 원본 케이퍼빌리티를 검증하고, 기존 권한과 요청된 마스크를 교차시키고, 같은 객체에 대해 권한이 더 적고 검사 필드가 파생된 새 케이퍼빌리티를 만들었다. 프로그래밍 가이드의std_restrict예제는 핵심 연산을rights &= mask로 단순하게 표현한다.

방향이 중요하다. 이 연산은 권한을 제거할 수 있다. 제출된 케이퍼빌리티가 이미 갖고 있지 않은 권한을 비트 마스크로 추가할 수는 없다. 사용자가 표시된 권한을 바꿔 더 많은 권한을 주장하면, 검사값이 더 이상 일치하지 않고 서버는 토큰을 거부한다.

또한 논문들은 설계 변형을 하나로 뭉개며 읽어서는 안 된다. 1986년 스파스 케이퍼빌리티 논문은 권한을 보호하는 여러 방식을 검토한다. 하나는 저장된 임의값과 권한을 일방향 함수로 결합한다. 또 하나는 서버가 제한된 토큰을 발행하도록 한다. 세 번째는 교환 가능한 일방향 함수군으로 로컬 권한 축소를 탐구한다. 1991년 상태 보고서는 Amoeba에 대한 서술에서 서버 지원 방식을 설명한다. 이들은 관련된 실험이지 구별할 수 없는 하나의 알고리즘이 아니다.

이 구별은 실제 저자 경계도 지켜 준다.Using Sparse Capabilities는 Andrew S. Tanenbaum, Sape J. Mullender, Robbert van Renesse가 썼다.The Amoeba Distributed Operating System—A Status Report는 Tanenbaum, M. Frans Kaashoek, van Renesse, Henri E. Bal이 썼다. Amoeba는 집단적 시스템 작업이었다. Tanenbaum은 합법적인 인간적 진입점이지 다른 설계자와 구현자를 지워버릴 면허가 아니다.

소유는 권한이었지, 신원은 아니었다

1986년 논문은 보유자가 비트 패턴을 보냄으로써 다른 프로세스에 정확한 복사본을 줄 수 있다고 밝힌다. 또한 시스템이 누가 어떤 케이퍼빌리티를 보유하는지 중앙 기록을 유지할 필요가 없다고 적는다. 이 성질들은 메커니즘을 휴대 가능하고 위치 투명하게 만들었다. 동시에 그것의 증거적 한계를 정의한다.

성공한 검사는 제출된 토큰이 서버의 현재 비밀값 아래에서 명명된 객체와 표시된 권한에 대해 유효하다는 것을 말한다. 그것은 제시하는 프로세스가 토큰을 객체 생성자에게서 직접 받았는지, 디렉터리를 통해 상속받았는지, 다른 프로세스에게서 받았는지, 노출되어서는 안 되는 곳에서 복사했는지는 말해 주지 않는다. 다른 메커니즘이 그 결합을 공급하지 않는 한, 인간 직원, 계약상 역할, 법적 주체와 결합하지도 않는다.

유효성이 목적을 입증하지도 않는다. 같은 쓰기 가능 토큰은 루틴 유지보수, 긴급 복구, 승인되지 않은 실험 어느 쪽에도 쓰일 수 있다. 권한은 서버가 수락할 동사를 제한할 뿐, 그 동사를 지금 선택한 사업적 근거를 인코딩하지 않는다.

폐기도 같은 한정된 형태를 지닌다. 서술된 모델에서 서버가 저장한 임의값을 바꾸면 그 객체의 기존 케이퍼빌리티를 무효화할 수 있다. 이는 강력한 객체 전체 리셋이다. 모든 복사본에 대한 선택적 지식, 과거 사용에 대한 소급적 귀속, 유출된 비트 패턴이 모든 프로세스와 아카이브에서 지워졌다는 증거는 아니다.

응답은 서버의 의미적 경계에서 멈춘다

유효한 케이퍼빌리티가 한 연산을 허용하고 서버가 성공을 반환했다고 하자. 보증할 수 있는 가장 강한 주장은 그 서버 연산이 정의하는 것이다. 연산이 서버 객체를 수정한다면, 응답은 서버가 자신의 구현에 따라 그 수정을 수락하고 수행했다는 것을 입증할 수 있다. 그러나 그 변경이 크래시에서 살아남았는지, 모든 복제본에 도달했는지, 물리 액추에이터를 움직였는지, 외부 결제를 완료했는지, 조직의 변경 정책을 충족했는지를 자동으로 증명하지는 않는다.

그것들은 별개의 제어 표면이다. 영속성은 저장·복구 경계에 속한다. 트리거된 물리적·네트워크 동작은 그것을 실행하고 관찰하는 하위 시스템에 속한다. 인간 승인은 권한을 설정하는 조직에 속한다. 압축된 토큰은 하나의 연산을 열 수 있지만, 이후 기대되는 모든 것에 대한 보편적 영수증이 되지는 않는다.

이것이 Amoeba 사례의 지속적 기여다. 명명과 보호를 드물 정도로 명확하게 결합한 다음, 거기서 멈춘다. 그 경계는 숨겨야 할 약점이 아니라, 메커니즘을 이해할 수 있게 만드는 것이다.

출처