수퍼유저가 아닌 실행 프로세스가 스스로 포크 및 복제하도록 허용(중복 가능)

수퍼유저가 아닌 실행 프로세스가 스스로 포크 및 복제하도록 허용(중복 가능)

질문

자신을 복제할 수도 있고 복제하지 않을 수도 있는 프로세스를 실행하는 Docker 컨테이너를 시작하고 싶습니다.

내 컨테이너에 슈퍼유저로 로그인한 사용자가 없도록 일반 + clone_newuts 권한을 가진 사용자를 설정할 수 있습니까?

원래 이 질문에는 태그가 CLONE_NEWUTS permission only잘못되었습니다. @sourcejedi님이 아래에 성실히 답변해주셔서 이해도가 많이 좋아졌습니다.

편집-1

su 플래그가 저장된 위치를 찾았습니다. /usr/include/linux/sched.h원숭이가 컨테이너 생성 시 특정 사용자 권한을 패치하는 것과 같은 대답이기를 바랍니다. 나는 지금 그 길을 따라가며 그것이 나를 어디로 데려가는지 볼 것입니다.

편집 2

사용자/파일 기능을 설정할 수 있는 곳을 찾았습니다. 읽어야 할 내용이 많지만 파일에 특정 권한(기능)을 부여하는 것이 가능하다고 생각합니다(이 경우 파일은 실행 가능합니다). 함수 매뉴얼 페이지에서: Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute. 따라서 파일이나 사용자에게 특정 함수(해당 플래그는 위 헤더에서 찾을 수 있음)를 적용하는 것이 가능해야 합니다. 아직 어느 것이 확실하지 않지만 그것을 알아내는 것은 매우 흥미롭고 심층적일 것입니다.

편집-3

@sourcejedi가 지적했듯이 필요한 것을 오해했습니다. 필요한 정보는 man limits.conf지정된 사용자 수준에서 프로세스를 실행할 수 있는 위치(이 경우 ) 에 있습니다 root.

편집 4

불행히도 EDIT-3에서 선택한 경로도 올바르지 않습니다. 이를 통해 지정된 사용자가 실행할 수 있습니다.모두uesr 수준 프로세스를 지정합니다. @sourcejedi는 여전히 맞지만, 정말 필요한 것이 무엇인지 묻는 새로운 질문을 드리겠습니다. 관련된:루트가 아닌 사용자로 분기 및 복제할 수 있는 단일 프로세스를 실행합니다.

답변1

CLONE_NEWUTS이 플래그를 사용하여 특별히 clone() 호출을 허용하는 기능은 없습니다 .

CLONE_NEWUTS새로운 "UTS 네임스페이스"를 생성하고 입력하는 데 사용됩니다. 모든 네임스페이스 유형은 CAP_SYS_ADMIN생성이 필요하지만 한 가지 예외는 업스트림 Linux 커널을 사용하면 권한 없는 사용자가 새 사용자 네임스페이스를 생성하고 입력할 수 있다는 것입니다.

사용자 네임스페이스를 만들 때 자신에게 루트/전체 권한을 허용할 수 있습니다.~에이 네임스페이스에는 가 포함되어 있습니다 CAP_SYS_ADMIN. 시스템이 이 기능을 지원하는 경우 를 사용하여 볼 수 있습니다 unshare -r. 새 사용자 네임스페이스에서 루트 셸을 엽니다.

권한이 없는 사용자가 네임스페이스를 사용하는 예상 방법은 새 사용자 네임스페이스 내입니다. 그러나 일부 Linux 배포판에서는 이 기능을 허용하지 않도록 커널을 구성합니다.

CAP_SYS_ADMIN더 이상 특정 기능이 없는 항목에 대한 일반적인 용어로 사용됩니다. 너무 강력해요. 다른 프로그램을 대신하여 추가 기능을 얻는 데 사용할 수 있다고 가정해야 합니다. [1]

Docker 데몬의 기본 구성새 사용자 네임스페이스에 컨테이너를 배치하지 마십시오.. 따라서 CAP_SYS_ADMINDocker 컨테이너를 명시적으로 부여하면 전체 권한으로 컨테이너를 이스케이프할 수 있다고 가정해야 합니다 . [1]

권한이 없는 사용자가 모든 유형의 네임스페이스를 직접 생성할 수 있고 네임스페이스를 사용하여 setuid 프로그램이 수행해서는 안 되는 권한 있는 작업을 수행하도록 혼동할 수 있는 경우 문제가 발생할 수 있습니다. 상호 참조:"마운트된 네임스페이스를 공유 해제하는 데 CAP_SYS_ADMIN이 필요한 이유는 무엇입니까?"

또 다른 옵션은 특정 작업만 수행하도록 허용하는 setuid/capability가 있는 도우미 실행 파일을 사용하는 것입니다. sudo특정 권한이 있는 명령만 실행하도록 구성하는 방법과 같습니다 . 이것이 취해진 접근 방식입니다버블 랩, FlatPak에서 사용됩니다.

bubblewrap 추가 정보에서는 Linux 배포판이 사용자 네임스페이스를 제한하게 만드는 보안 문제에 대한 일부 참조 자료도 제공합니다.

이 이야기는 기본 Docker 데몬의 중요한 보안 기능을 비활성화하지 않고는 "Docker in Docker"가 실제로 지원되지 않거나 불가능한 이유와 겹친다고 생각합니다. 정확히 동일하지는 않지만.


[1] 예를 들어 CAP_SYS_ADMIN커널 개발자는 블록 파일 시스템을 마운트하는 기능을 악성 FS 이미지로부터 안정적으로 보호하는 것으로 간주하지 않았습니다.

새 사용자 네임스페이스 내에서는 CAP_SYS_ADMIN블록 파일 시스템을 마운트할 수 없습니다. 그러나 새 마운트 네임스페이스도 생성하는 경우(예 unshare -rm: CAP_SYS_ADMIN을 사용하면 바인드 마운트, 마운트 파일 시스템을 생성할 수 proc있으며 커널 4.18 이상에서는 FUSE 파일 시스템을 마운트할 수 있습니다.)

Docker는 또한 사용 가능한 시스템(SELinux 또는 AppArmor)에서 LSM 기반 보안을 사용합니다. 이러한 레이어는 CAP_SYS_ADMIN어떤 면에서 제한될 수 있습니다. 이는 Docker의 다른 보안 계층보다 더 모호합니다. 특정 LSM의 세부적인 작동에 의존한다면 편리하고 이식 가능한 Docker 컨테이너를 구축하는 요점 중 하나가 무산되는 것 같습니다.

관련 정보