☰

가상머신/운영체제

tag-icon • tag-icon permissions non-root-user jails
가상머신/운영체제

내가 루트라면 간단히 더미 사용자/그룹을 만들고 그에 따라 파일 권한을 설정하고 해당 사용자로 프로세스를 실행할 수 있습니다. 하지만 저는 그렇지 않습니다. 루트 없이 이를 달성할 수 있는 방법이 있습니까?

답변1

더 유사한 질문, 더 주목할만한 답변:

노트:거기에 있는 답변 중 일부는 여기에 아직 언급되지 않은 특정 솔루션을 가리킵니다.

실제로 다양한 구현을 갖춘 꽤 많은 감옥 도구가 있지만 그 중 다수는 설계상 안전하지 않거나(예 fakeroot: LD_PRELOAD기반) 불완전합니다( 예 : fakeroot-ng기반 ptrace)chrootplashfakechroot 경고 라벨).

이것은 단지 예일 뿐입니다. 두 가지 기능("신뢰할 수 있습니까?", "설정하려면 루트가 필요합니까?")을 나란히 배치하고 싶었습니다.운영 체제 수준 가상화 구현.

일반적으로 여기에 대한 답변은 설명된 모든 가능성과 그 이상을 포괄합니다.

가상머신/운영체제

커널 확장(예: SELinux)

  • (여기 댓글에서 언급됨)

chroot

chrootChroot 기반 도우미(그러나 루트가 필요하므로 setUID 루트여야 합니다 . 그렇지 않으면 chroot격리된 네임스페이스에서 작동할 수 있습니다. 아래 참조):

[그들에 대해 더 알려주세요! ]

알려진 chroot 기반 격리 도구:

  • 해셔그리고 그 hsh-run명령 hsh-shell. (하셸안전하고 반복 가능한 방식으로 소프트웨어를 구축하는 것을 목표로 하세요. )
  • 슈루트에서 언급된또 다른 대답
  • ...

길

또 다른 신뢰할 수 있는 격리 솔루션(외에seccomp을 기반으로ptrace) 맨페이지에 설명된 대로 전달하여 완전한 시스템 호출 차단이 됩니다.fakeroot-ng:

이전 구현과 달리 fakeroot-ng는 추적된 프로세스가 fakeroot-ng의 "서비스" 사용 여부를 선택할 수 없게 만드는 기술을 사용합니다. 프로그램의 정적 컴파일, 커널에 대한 직접 호출 및 자신의 주소 공간 조작은 모두 LD_PRELOAD 기반 프로세스 제어를 우회하는 데 사용할 수 있는 기술이며 fakeroot-ng에는 적용되지 않습니다. 이론적으로 fakeroot-ng는 추적 프로세스를 완벽하게 제어할 수 있는 방식으로 구성될 수 있습니다.

이론적으로는 가능하지만 아직 구현되지 않았습니다. Fakeroot-ng는 추적된 프로세스에 대해 특정 "잘 작동하는" 가정을 하며 이러한 가정을 깨는 프로세스는 완전히 탈출하지는 않더라도 fakeroot가 해당 프로세스에 부과하는 일부 "가짜" 환경을 우회할 수 있습니다. 따라서 fakeroot-ng를 보안 도구로 사용하지 말 것을 강력히 경고합니다. 프로세스가 의도적으로(우연히가 아니라) fakeroot-ng 제어를 벗어날 수 있다고 주장하는 버그 보고서는 "버그 아님"으로 닫히거나 낮은 우선순위로 표시됩니다.

이 정책은 향후 재검토될 수 있습니다. 그러나 지금은 경고를 받았습니다.

그러나 읽어보셨듯이 fakeroot-ng이 기능 자체는 이러한 목적으로 설계되지 않았습니다.

seccomp(그런데 왜 그들이 Chromium에 대해 기반 접근 방식 대신 ptrace기반 접근 방식을 사용하기로 선택했는지 궁금합니다 ...)

위에 언급되지 않은 도구의 경우조르디나 자신을 위해서 하스켈로 제어 프로그램을 작성하는 것을 좋아하기 때문이다.

알려진 ptrace 기반 격리 도구:

보안 컴퓨팅

격리를 달성하는 알려진 방법 중 하나는 다음과 같습니다.Google Chromium에서 사용되는 seccomp 샌드박스 방식. 그러나 이 접근 방식은 일부 (허용된) "가로채기된" 파일 액세스 및 기타 시스템 호출을 처리하는 도우미 프로그램을 작성한다고 가정합니다. 물론 시스템 호출을 "가로채서" 도우미 프로그램으로 리디렉션하려는 노력도 있습니다. 아마도 이는 제어되는 프로세스의 코드에서 가로채는 시스템 호출을 대체하는 것을 의미할 수도 있습니다. 따라서 관심이 있다면 내 답변뿐만 아니라 세부 사항을 읽어 보는 것이 좋습니다.

추가 관련 정보(Wikipedia 참조):

( Chromium 외부에서 일반 기반 솔루션을 찾는 사람이라면 seccomp이 마지막 항목이 흥미로울 것 같습니다 . "seccomp-nurse" 작성자도 읽어볼 만한 블로그 게시물이 있습니다.샌드박스 솔루션으로서의 SECCOMP?.)

이 접근 방식에 대한 지침은 다음에서 제공됩니다.“seccomp-nurses” 프로젝트:

                      여기에 이미지 설명을 입력하세요.

미래에 Linux에 "유연한" seccomp가 가능합니까?

2009년에도 등장Linux 커널 패치 팁이를 seccomp통해 모델의 유연성이 향상되어 "현재 우리가 필요로 하는 많은 곡예를 피할 수 있습니다". ("곡예"는 감옥에 갇힌 프로세스를 대신하여 잠재적으로 무해한 시스템 호출을 많이 수행하고 감옥에 갇힌 프로세스 내에서 잠재적으로 무고한 시스템 호출을 대체해야 하는 도우미 작성의 복잡성을 의미합니다.)LWN 기사이 시점까지 작성:

한 가지 제안은 seccomp에 새로운 "모드"를 추가하는 것이었습니다. API는 서로 다른 애플리케이션이 서로 다른 보안 요구 사항을 가질 수 있다는 생각으로 설계되었습니다. 여기에는 적용되어야 하는 제한 사항을 지정하는 "모드" 값이 포함되어 있습니다. 오리지널 모드만 구현되어 있지만, 다른 모드도 물론 추가될 수 있습니다. 시작된 프로세스에서 허용되는 시스템 호출을 지정할 수 있는 새 모드를 생성하면 Chrome 샌드박스와 같은 상황에서 도구가 더 유용해집니다.

Adam Langley(또한 Google 출신)는 이를 달성하기 위한 패치를 출시했습니다. 새로운 "모드 2" 구현에서는 액세스 가능한 시스템 호출을 설명하는 비트마스크를 허용합니다. 이들 중 하나가 prctl()인 경우 샌드박스 코드는 자체 시스템 호출을 추가로 제한할 수 있습니다(그러나 거부된 시스템 호출에 대한 액세스는 복원할 수 없습니다). 전체적으로 이것은 샌드박스 개발자의 삶을 더 쉽게 만들어 주는 합리적인 솔루션처럼 보입니다.

즉, 논의가 다른 가능성으로 옮겨갔기 때문에 이 코드는 결코 병합되지 않을 수도 있습니다.

이 "유연한 seccomp"는 Linux가 복잡한 도우미를 작성하지 않고도 운영 체제에서 필요한 기능을 제공하는 데 더 가까워지도록 해줍니다.

(본질적으로 이 답변과 내용이 동일한 블로그 게시물:http://geofft.mit.edu/blog/sipb/33.)

네임스페이스( unshare)

네임스페이스(unshare기반 솔루션) - 여기서는 언급되지 않았습니다.공유 마운트 지점 취소(FUSE와 결합?) 신뢰할 수 없는 프로세스에 대한 파일 시스템 액세스를 제한하려는 경우 작업 솔루션의 일부일 수 있습니다.

이제 구현이 완료됨에 따라 네임스페이스에 대한 추가 정보가 제공됩니다(이 격리 기술은 nme에서도 알려져 있음)."Linux 컨테이너" 또는 "LXC", 그렇지 않나요? ..):

"네임스페이스의 전반적인 목표 중 하나는 (다른 목적 중에서도) 경량 가상화 도구인 컨테이너의 구현을 지원하는 것입니다.".

새로운 사용자 네임스페이스를 생성하여 "프로세스가 사용자 네임스페이스 외부에서는 권한이 없는 일반 사용자 ID를 가질 수 있고 네임스페이스 내부에서는 사용자 ID 0을 가질 수 있습니다. 이는 프로세스가 작업에 대한 전체 루트 권한을 가짐을 의미합니다. 사용자의 네임스페이스는 있지만 네임스페이스 외부 작업에 대한 권한은 없습니다."

이를 수행하는 실제 작업 명령은 여기에서 답변을 참조하세요.

그리고 특별한 사용자 공간 프로그래밍/컴파일

그러나 물론 필요한 "감옥" 보장은 사용자 공간(이 기능에는 추가 운영 체제 지원이 필요하지 않습니다.;아마도 이것이 바로 이 기능이 애초에 OS 설계에 포함되지 않은 이유일 것입니다.) 다소 복잡한 문제가 있습니다.

거기에 언급된ptrace-또는seccomp샌드박싱은 "블랙박스", 즉 임의의 Unix 프로그램으로 처리되는 다른 프로세스를 제어할 수 있는 샌드박스 도우미를 작성하여 달성되는 보장의 일부 변형으로 생각할 수 있습니다.

또 다른 접근 방식은 비활성화해야 하는 효과를 고려하는 프로그래밍 기술을 사용하는 것입니다. (그러면 프로그램은 사용자가 작성해야 하며 더 이상 블랙박스가 아닙니다.) 예를 들어 다음을 사용하십시오.순수 프로그래밍 언어(이렇게 하면 부작용 없이 프로그래밍하게 됩니다.)하스켈프로그램의 모든 효과를 명시적으로 작성하면 프로그래머가 허용되지 않는 효과가 없음을 쉽게 확인할 수 있습니다.

자바 등 다른 언어로 프로그래밍하는 사람들을 위한 샌드박스 기능도 있는 것 같아요.

이 주제에 대한 정보를 축적하는 일부 페이지도 답변에서 지적됩니다.

답변2

이는 Unix 권한 모델의 근본적인 제한 사항입니다. 루트만 위임할 수 있습니다.

가상 머신을 실행하기 위해 루트가 될 필요는 없지만(모든 가상 머신 기술이 그렇지는 않음) 이는 매우 강력한 솔루션입니다.

사용자 모드 리눅스비교적 가벼운 Linux-on-Linux 가상화 솔루션입니다. 설정하기가 쉽지 않습니다. 최소한 부팅에 필요한 최소 항목(몇 개의 파일 /etc과 해당 /sbin/init종속성, 로그인 프로그램, 셸 및 유틸리티) 으로 루트 파티션(디렉토리)을 채워야 합니다 .

답변3

일부 파일에 대한 액세스를 가로채는 것이 운이 좋을 수도 있지만 LD_PRELOAD매우 까다로울 수 있습니다.

답변4

전체 목록에서 다음을 추가합니다.

  • fakeroot (debian package maintener에서): 목표는 패키지를 빌드하기 위해 "친숙한" 도구를 사용하는 것입니다. 이는 완전한 격리는 아니지만 다양한 사용자와 가짜 장치, 기타 특수 더미 파일로 패키지를 구축하는 데 도움이 됩니다.

  • fakechroot(fakeroot 사용) 이 앱에는 버그가 많습니다. 예를 들어, "/etc/hosts"는 glibc에 하드코딩되어 있으므로 이 도구를 사용하여 변경할 수 없습니다.

  • qemu: Linux 커널을 컴파일해야 하지만 결과가 매우 빠르고 실제 루트 권한이 있는 "가짜"(즉, 가상) 머신입니다. 모든 부팅 이미지를 빌드하고 설치할 수 있습니다.

관련 정보