요약

  • RFC 2307은 Unix 계정, 그룹, 네트워크 정보를 LDAP 항목으로 표현하는 방식을 제안했다. posixAccount에는 시스템 조회 함수가 읽는 사용자 번호 uidNumber가 포함됐다.
  • RFC의 보안 절은 쓰기 권한을 잘못 부여했을 때의 결과를 적었다. 사용자가 uidNumber를 바꿀 수 있다면 자기 계정을 슈퍼유저와 동등하게 만들 수 있었다.

계정 조회는 숫자 하나에서 시작한다

Unix 프로세스는 디렉터리에 사용자의 사연을 묻지 않는다. C 라이브러리에 숫자를 건네고 그 번호에 연결된 계정 레코드를 받는다. RFC 2307은 getpwuid()를 예로 들며 사용자 ID에서 로그인 이름을 찾는 방식을 설명한다. 제안된 LDAP 모델에서 조회는 프로그램이 넘긴 숫자와 uidNumber가 일치하는 posixAccount 항목을 찾는다.

파일에서는 한 칸일 뿐이다. 소프트웨어는 그 값을 신원으로 취급한다.

LDAP가 등장하기 전에도 Unix 네트워크는 Network Information Service(NIS)로 계정과 호스트 정보를 공유했다. Sun의 Solaris 관리 안내서는 NIS 맵을 키와 값의 두 열로 된 표로 설명한다. 마스터 서버가 도메인 맵을 보관하고, 슬레이브 서버가 사본을 유지하며, 클라이언트는 둘 중 어느 쪽에도 질의할 수 있다. passwd.byname은 로그인 이름으로 계정을 찾고, passwd.byuid는 사용자 번호를 키로 쓴다. 관리자는 마스터의 로컬 파일을 바탕으로 맵을 만들고 슬레이브에 배포했다.

그 구조에서 로컬 파일 수정은 네트워크의 답변으로 바뀐다. 관리자가 원본 파일을 고쳐 맵을 다시 만들면 도메인의 클라이언트가 새 레코드를 받는다. 조회 코드는 그 번호가 타당한지 클라이언트 투표를 열지 않는다. 이름 서비스가 돌려준 값을 사용한다.

SunOS의 1999년 매뉴얼에는 이름에 관한 작은 사건도 남아 있다. NIS는 한때 Sun Yellow Pages라고 불렸지만 영국 상표권 때문에 이름을 바꿨고 기능은 그대로였다. 간판은 바뀌었지만 계정 맵이 시스템에 미치는 힘은 그대로였다.

LDAP는 보관 장소를 바꿨다. 수정 권한은 운영자의 몫이었다

1997년 12월 RFC 2251은 완전한 DAP보다 적은 자원으로 X.500 기반 디렉터리에 접근하는 LDAPv3를 정의했다. 약 세 달 뒤 나온 RFC 2307은 An Approach for Using LDAP as a Network Information Service라는 제목으로 Unix와 TCP/IP 데이터를 LDAP 클래스와 속성에 담는 방식을 제안했다.

대상은 호스트 이름에 그치지 않았다. 계정과 그룹, 서비스 이름과 프로토콜 번호, RPC 식별자, 부팅 매개변수, 네트워크 주소와 NIS 넷그룹이 포함됐다. posixAccount에는 로그인 이름, 표시 이름, uidNumber, gidNumber, 홈 디렉터리와 로그인 셸을 저장할 수 있었다. RFC는 /etc/passwd와 비슷한 한 줄을 디렉터리 속성으로 바꾸는 예도 실었다.

이 연결에는 실무적인 이유가 있었다. Unix 애플리케이션은 이미 C 라이브러리를 통해 계정 정보를 조회했다. 조회 방식은 유지하면서 원본을 로컬 파일에서 네트워크 디렉터리로 옮길 수 있었다. RFC 2307의 구현 절은 로컬 파일 대신 LDAP를 쓰는 NIS 서버, C 라이브러리 조회 참고 구현, /etc/passwd나 /etc/hosts를 LDAP로 가져오는 스크립트를 기록한다.

RFC 2307은 Experimental로 발행됐고 모든 Unix 사이트에 이행을 명령하지 않았다. 문서는 몇몇 성공적인 구현 사례가 있다고 적었지만 설치 수나 보급률을 집계하지 않았다.

숫자가 권한 경계가 됐다

RFC 2307의 보안 절은 디렉터리 레코드가 운영체제에서 갖는 힘을 직접 다룬다. 운영체제 엔터티를 나타내는 항목은 관리자만 바꿔야 한다고 말한다. 이유도 구체적이다. 사용자가 자기 uidNumber를 바꿀 수 있다면 보안을 무너뜨리고 자기 계정을 슈퍼유저와 동등하게 만들 수 있다.

RFC 2307은 조건이 붙은 위험과 통제 지점을 함께 제시했다. Unix 소프트웨어는 번호와 계정을 연결한다. 디렉터리는 그 연결을 많은 클라이언트에 전달할 수 있다. 쓰기 권한을 가진 사람은 클라이언트가 보게 될 신원을 바꿀 수 있다. 스키마는 필드의 모양을 정한다. 접근 규칙은 그 값을 누가 바꿀지를 정한다.

같은 절은 조회의 편리함과 비밀 보호가 충돌하는 지점도 짚었다. crypt() 같은 널리 쓰이는 방식으로 암호화한 비밀번호 해시를 비특권 사용자에게 노출하면 사전 대입이나 전수 대입 공격을 받을 수 있다. RFC는 이 구성이 기존 Unix와의 호환을 위한 것이라고 설명하고, 보안이 중요한 환경에는 강한 인증 서비스를 권했다. 공유 디렉터리는 검색을 쉽게 하지만 민감한 계정 데이터에 접근하는 클라이언트도 늘릴 수 있다.

이 자료가 확인해 주는 것은 제안된 설계와 RFC 자체가 기록한 경고다. LDAP 방식이 Unix 전반에서 얼마나 쓰였는지는 이 자료에 수치가 없다. 도입 규모를 판단하려면 별도의 설치 통계가 필요하다.

핵심 변화는 데이터베이스에 스키마가 하나 더 생긴 일이 아니었다. 운영체제가 로컬 질문에 대한 답을 네트워크에서 받기 시작했다. uidNumber는 표의 열이지만, 그 값을 읽는 프로그램이 의미를 부여한다. /etc/passwd에서 NIS나 LDAP로 옮겨 가면 권한을 관리할 자리도 함께 이동한다. 어느 출처가 기준인지, 어떤 복제본이 최신 맵을 가졌는지, 누가 신원 번호를 바꿀 수 있는지를 운영자가 계속 결정해야 한다.

출처