Docker 컨테이너에서 애플리케이션을 실행하려고 합니다. 이 애플리케이션을 실행하려면 루트 권한이 필요합니다.
sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image
내 질문은: --network 호스트 옵션을 사용하여 NET_ADMIN 기능을 추가할 때의 위험은 무엇입니까?
공격자가 내 응용 프로그램에서 일부 코드를 실행할 수 있는 경우 루트로 실행하고 있으므로 공격자는 무제한의 권한을 갖게 됩니까, 아니면 커널의 네트워크 부분에만 액세스할 수 있습니까? 그렇다면 그의 공격 표면은 무엇입니까? 즉, NET_ADMIN 기능 세트만 사용하여 호스트 OS에서 루트 권한을 얻을 수 있습니까?
답변1
Q1. 공격자가 NET_ADMIN 함수만 사용하여 내 호스트 운영 체제에 대한 루트 권한을 얻을 수 있습니까?
예(경우에 따라).
CAP_NET_ADMINSIOCETHTOOL네임스페이스 내의 모든 네트워크 장치에서 ioctl()을 사용할 수 있습니다 . 여기에는 ETHTOOL_FLASHDEVie 와 같은 명령이 포함됩니다 ethtool -f.
이것이 게임이다. 자세한 설명은 아래 인용문에 있습니다.
SIOCETHTOOL모든 네트워크 네임스페이스에서 허용됩니다.5e1fccc0bfac 제출, "net: 사용자 루트가 네트워크 스택의 핵심을 제어할 수 있도록 허용합니다". 이전에는 CAP_NET_ADMIN"루트" 네트워크 네임스페이스에서만 이것이 가능했습니다. 이는 당시 안전 고려 사항이 언급되었기 때문에 흥미롭습니다. 나는 살펴보았다커널 버전 5.0의 코드, 나는 다음 의견이 여전히 적용된다고 생각합니다.
Re: [PATCH net-next 09/17] net: 네트워크 스택의 핵심에 대한 사용자 루트 제어를 허용합니다.
같은 이유로 user_ns별로 허용되는 ethtool 명령을 선택적으로 선택하는 것이 가장 좋습니다
CAP_NET_ADMIN. 이것을 먼저 고려하십시오:
ETHTOOL_SEEPROM=> NIC 브릭
ETHTOOL_FLASHDEV=> IOMMU를 사용하지 않는 경우 NIC를 소유합니다.기본적으로 실제 하드웨어에 액세스할 수 없으면 이러한 문제를 피할 수 있습니다. 물리적 네트워크 인터페이스에 액세스하려면 네트워크 네임스페이스로 이동해야 합니다.
네, 알고 있어요. 문제는 물리적 네트워크 장치가 할당된 경우에도 컨테이너의 어떤 것이 이러한 작업을 수행할 수 있을 것으로 기대하는지 여부입니다.
실제로 컨테이너를 고려하지 않더라도 동일한 질문이 있습니다.
CAP_NET_ADMIN네트워크 하드웨어이기 때문에 실제로 하드웨어에 대한 하위 수준 제어를 제공해야 할까요? 이러한 ethtool 작업 중 일부와 비표준 MDIO 레지스터에 대한 액세스에는 추가 기능(CAP_SYS_ADMIN또는CAP_SYS_RAWIO?)이 필요할 수 있다고 생각합니다.
그런 것 같아요봉쇄함수에도 비슷한 문제가 있습니다. 검색하는 동안 결과에서 잠긴 패치를 발견하지 못했습니다. 기능을 잠그는 해결책은 서명만 허용하는 커널 모듈을 잠그는 것과 유사한 일종의 디지털 서명이라고 생각합니다.
Q2. 그들이 어떻게든 내 애플리케이션에서 일부 코드를 실행하게 되면 무제한의 권한을 갖게 될까요?
귀하의 명령에 따라 더 좁은 경우로 분류하겠습니다.
sudo docker run --restart always --network host --cap-add NET_ADMIN -d -p 53:53/udp my-image
기능 외에도 이 docker명령은 seccomp 제한 사항도 적용해야 합니다. 또한 시스템(SELinux 또는 AppArmor)에서 사용 가능한 경우 LSM 기반 제한을 적용할 수도 있습니다. 그러나 이들 중 어느 것도 다음에 적용되지 않는 것 같습니다 SIOCETHTOOL.
seccomp-bpf차단하는데 사용할 수 있을 것 같아요 SIOCETHTOOL. 하지만, 그Docker의 기본 seccomp 구성ioctl() 호출을 필터링하려는 시도는 없습니다.
내가 살펴본 커널 함수에서 LSM 후크를 발견하지 못했습니다.
나는 Ben Hutchings가 좋은 점을 지적했다고 생각합니다. 이상적인 해결책은 이를 CAP_SYS_RAWIO. 당신 :-P. (특히 안전 부팅으로 인해 이 문제를 다루는 경우) 그런 다음 변경 사항이 되돌려지고 가장 덜 보기 흉한 해킹이 무엇인지 알아낼 수 있습니다.
즉, 커널은 이전 버전과의 호환성을 유지하고 CAP_NET_ADMIN루트 네임스페이스의 프로세스를 허용하도록 강제될 수 있습니다. 이 경우에도 seccomp-bpfdocker 명령을 보호해야 합니다. 이 경우 커널을 변경하려고 시도할 가치가 있는지 잘 모르겠습니다. 커널은 (일부) 컨테이너만 보호하기 때문입니다. 어쩌면 컨테이너 런타임이 기본적으로 차단되도록 docker수정될 수도 있습니다 . SIOCETHTOOL이는 LXC/systemd-nspawn과 같은 "OS 컨테이너"의 작동 기본값일 수도 있습니다.