man 2 unshare우리에게 말해주세요
CLONE_NEWPID를 사용하려면 CAP_SYS_ADMIN 함수가 필요합니다.
그리고 더 읽어보라는 제안에서는 man 7 pid_namespacespid_namespaces를 루트/CAP_SYS_ADMIN으로 제한하는 데 필요한 가능한 위험에 대해 실제로 논의하지 않습니다.
CLONE_NEWPID루트가 아닌 사용자가 실행할 경우 어떤 위험이 있습니까?
클론에서아니요 CLONE_NEWPIDpid_namespace는 변경되지 않은 상태로 유지되므로 빈 pid_namespace를 새로 만드는 것보다 상황이 더 광범위하고 잠재적으로 더 위험할 수 있습니다.
아쉽게도 개념이 없네요UserPID 네임스페이스루트가 아닌 사용자에게는 Linux에서 하위 프로세스를 안정적으로 추적하는 것이 어려워집니다. pid_namespaces는 매우 편리한 기능이므로 왜 pid_namespaces를 CAP_SYS_ADMIN실행하는 것이 적절하다고 간주되는지 이해할 수 없습니다 CLONE_NEWPID. 그렇게 위험한 분주함으로 이어지는 지점을 제가 놓치고 있는 걸까요 CLONE_NEWPID?
답변1
나는 이것이 예방 조치라고 생각합니다. 권한이 없는 사용자는 sudo허용하지 않으려는 작업을 수행하는 데 혼란을 주지 않도록 set-user-id(또는 set-file 기능)와 같은 프로그램에 제한을 적용하는 것이 허용되지 않습니다 .
어떤 경우에는 set-uid 등의 상승을 방지하여 이를 시행합니다. 이는 seccomp를 사용하여 시스템 호출을 필터링할 때 취하는 접근 방식입니다.
그러나 네임스페이스의 목적은 네임스페이스 사용자 ID를 허용하는 것입니다. 네임스페이스는 가장 단순한 것부터 시작하여 최종적으로 사용자 네임스페이스를 형성하는 점진적인 방식으로 메인라인 Linux에 병합되었습니다. 아직 전체 권한이 없을 때 PID 네임스페이스에 들어갈 때 no-new-privs를 적용하는 특별한 경우를 추가하는 데 관심이 있는 사람은 아무도 없을 것 같습니다.
이러한 네임스페이스의 상호 작용은 매우 복잡해지기 때문에 이러한 케이스에 대한 수요가 그다지 높지 않은 경우 너무 많은 케이스를 추가하지 않는 것이 가장 좋습니다.