프리BSD 감옥

FreeBSD jail

감옥 메커니즘은 FreeB의 구현입니다.SD의 OS 레벨 가상화 기능을 통해 시스템 관리자는 FreeBSD에서 파생된 컴퓨터 시스템을 여러 의 독립된 미니 시스템으로 분할할 수 있습니다.모두 같은 커널을 공유하며 오버헤드는 거의 없습니다[1].이것은 시스템 호출인 filen(2),[2] 사용자 랜드 유틸리티인 filen(8)[3] 및 시스템에 따라 다른 많은 유틸리티를 통해 구현됩니다.기능은 FreeB에 커밋되었습니다.1999년 Poul-Henning Kamp에 의해 호스팅 프로바이더에 의해 실가동된 SD는 FreeBSD 4.0과 함께 처음 출시되어 다수의 FreeB에서 지원되고 있습니다.Dragon Fly BSD를 포함한 SD의 후속 제품.

FreeB의 필요성SD Jails는 소규모 공유 환경 호스팅 프로바이더(R&D Associates, Inc.의 오너인 Derrick T)로부터 입수되었습니다.Woolworth)는 주로 보안과 관리의 용이성을 위해 자체 서비스와 고객 서비스 간의 깨끗하고 명확한 분리를 확립하고자 합니다(jail(8)).Poul-Henning Camp가 채택한 솔루션은 새로운 세분화된 구성 옵션을 추가하는 것이 아니라 적절한 사용자만 [4]적절한 컴파트먼트에 접근할 수 있도록 시스템(파일 및 리소스 모두)을 구분하는 것이었습니다.

역사

감옥은 FreeB에서 처음 도입되었다.2000년 3월 14일에 출시된 SD 버전 4.0(2000-03-14)[5]기존 기능의 대부분은 Dragon Fly에서 지원되며, 일부 새로운 기능도 이식되었습니다.

목표들

FreeBSD 감옥은 주로 세 가지 목표를 목표로 합니다.

  1. 가상화:각 감옥은 자체 파일, 프로세스, 사용자 및 슈퍼 사용자 계정을 사용하여 호스트 시스템에서 실행되는 가상 환경입니다.수감된 과정 안에서 보면 환경은 실제 시스템과 거의 구분할 수 없습니다.
  2. 보안:각 감옥은 다른 감옥과 격리되어 있어 보안이 강화됩니다.
  3. 위임의 용이성:감옥의 범위가 한정되어 있기 때문에 시스템 관리자는 시스템에 대한 완전한 제어권을 부여하지 않고 슈퍼 유저 액세스를 필요로 하는 몇 가지 작업을 위임할 수 있습니다.

파일 시스템의 특정 뷰에만 프로세스를 제한하는 chroot 감옥과는 달리 FreeB는SD 감옥 메커니즘은 감옥 내 프로세스의 활동을 시스템의 나머지 부분에 대해 제한합니다.실제로 수감된 프로세스는 샌드박스로 처리됩니다.이것들은 특정의 IP 주소에 바인드 되어 있어, 보호된 프로세스에서는, 전송 소켓이나 라우팅 소켓에 액세스 할 수 없습니다.raw 소켓도 디폴트로 디세블로 되어 있습니다만,security.jail.allow_raw_sockets sysctl 옵션.또한 동일한 교도소에서 실행되지 않는 프로세스 간의 상호 작용도 제한됩니다.

freeBSD 4.0에서 처음 등장한 것은 filen(8) 유틸리티와 filen(2) 시스템 콜입니다.FreeBSD 5.1에는 감옥 관리를 훨씬 쉽게 해주는 새로운 유틸리티(예를 들어 감옥 목록을 작성하기 위한 jls(8)와 시스템 호출(예를 들어 교도소에 새로운 프로세스를 부가하기 위한 jail_attach(2))가 추가되었습니다.교도소 서브시스템은 FreeBSD 7.2에서 교도소당 여러 IPv4 및 IPv6 주소 지원 및 특정 CPU에 대한 감옥 바인딩 지원 등 더욱 중요한 업데이트를 받았습니다.

가상화

감옥을 사용하면 다양한 가상 머신을 생성할 수 있으며, 각 가상 머신에는 자체 유틸리티 집합과 구성이 설치되어 있습니다.이를 통해 소프트웨어를 안전하게 시험할 수 있습니다.예를 들어, 다른 버전의 웹 서버 패키지를 실행하거나 다른 감옥에서 다른 구성을 시도할 수 있습니다.감옥은 좁은 범위로 한정되어 있기 때문에 (감옥 내 슈퍼 유저에 의해서 행해진 경우에도) 잘못된 구성이나 실수의 영향은 시스템의 나머지 무결성을 위태롭게 하지 않습니다.감옥 밖에서 실제로 수정된 것이 없기 때문에, "변경사항"은 감옥의 디렉토리 트리 복사본을 삭제함으로써 폐기될 수 있습니다.

가상화는 사용자에게 커스텀 구성을 제공하면서도 시스템 전체를 쉽게 유지 관리할 수 있는 기능을 제공하고자 하는 서비스 프로바이더에게 중요합니다.예를 들어, 서로 다른 두 고객에게는 서로 다른 버전의 동일한 소프트웨어가 필요할 수 있습니다.감옥이 없으면 여러 소프트웨어 버전을 서로 다른 디렉토리에 구성하고 서로 침해하지 않도록 하는 것이 항상 가능하거나 쉬운 일은 아닙니다(예: XFree86은 이동하기가 어렵기로 악명 높습니다).한편, 감옥은 소프트웨어 패키지가 시스템을 이기적으로 볼 수 있도록 합니다. 마치 각 패키지가 기계를 가지고 있는 것처럼요.감옥은 또한 그들 자신의 독립적인 수감된 슈퍼 유저들을 가질 수 있다.

프리비그러나 SD 감옥은 진정한 가상화를 실현하지 못합니다.가상 머신이 기본 시스템과 다른 커널 버전을 실행할 수 없습니다.모든 가상 서버는 동일한 커널을 공유하므로 동일한 버그와 잠재적인 보안 취약점이 노출됩니다.클러스터링 또는 프로세스 마이그레이션은 지원되지 않으므로 호스트 커널과 호스트 컴퓨터는 모든 가상 서버에 대해 단일 장애 지점입니다.새 소프트웨어를 안전하게 테스트하기 위해 감옥을 사용할 수 있지만 새 커널은 사용할 수 없습니다.

보안.

FreeBSD 감옥은 수감된 환경과 시스템의 나머지 부분(기타 감옥과 기본 시스템)이 분리되어 있기 때문에 서버의 보안을 강화하는 효과적인 방법입니다.

예를 들어, 비제일 시스템에서 사용자 www로 실행 중인 웹 서버가 PHP 포함 취약성을 도입하면 시스템 전체가 손상됩니다. 공격자는 일반적으로 웹 서버 상의 파일을 수정하고 디렉토리 트리를 돌아다니며 전체 사용자 목록, 및 정보 수집을 수행할 수 있는 사용자 www 권한을 가집니다./etc/passwd 홈디렉토리

그러나 웹 서버가 수감되면 사용자의 범위는 감옥으로 제한되며, 이는 결국 많은 것을 공개하지 않을 정도로 최소화할 수 있다.비록 공격자가 감옥의 슈퍼유저 계정에 접근할 수 있다 하더라도, 그들은 감옥 전체를 수정할 수 있을 뿐이지 전체 시스템은 수정할 수 없었다.

FreeBSD 감옥은 다음과 같은 방법으로 제한됩니다.

  • 수감된 프로세스는 다른 교도소 또는 주 호스트 내의 프로세스와 상호 작용할 수 없습니다.예를 들어 ps 명령어는 감옥 내에서 실행 중인 프로세스만 표시합니다.
  • 직접 액세스 및 모듈 로드에 의한 실행 중인 커널 수정은 금지됩니다.대부분의 sysctlssecure level은 변경할 수 없습니다.
  • 인터페이스, 인터페이스 또는 IP 주소, 라우팅 테이블 등의 네트워크 설정 변경은 금지됩니다.다이버트와 라우팅 소켓에의 액세스도 금지되어 있습니다.또한 raw 소켓은 기본적으로 비활성화되어 있습니다.감옥은 특정 IP 주소에만 바인딩되며 방화벽 규칙은 변경할 수 없습니다.VNET(가상 네트워크 스택)의 도입에 의해, 교도소에서의 vnet 가 유효하게 되어 있는 한, 감옥은 네트워크 설정(인터페이스, IP 주소등)을 자유롭게 변경할 수 있습니다.
  • 파일 시스템의 마운트 및 마운트 해제는 금지되어 있습니다.감옥은 루트 디렉터리 위에 있는 파일에 액세스할 수 없습니다(예: 감옥이 chroot'ed).
  • 보호된 프로세스에서는 디바이스 노드를 생성할 수 없습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ David Chisnall (2007-06-15). "DragonFly BSD: UNIX for Clusters?". InformIT. Prentice Hall Professional. Retrieved 2019-03-06.
  2. ^ "jail(2) — create and manage system jails". FreeBSD, DragonFly BSD.
  3. ^ "jail(8) — manage system jails". FreeBSD, DragonFly BSD.
  4. ^ Kamp, Poul-Henning; N. M. Watson, Robert (2000). "Jails: Confining the omnipotent root" (PDF). PHKs Bikeshed. Retrieved 15 June 2016.
  5. ^ "FreeBSD 4.0 Announcement". FreeBSD Project. 14 March 2000. Retrieved 3 October 2019.

외부 링크