This is just a quick test to see if we can jailbreak rootless Docker-in-Docker.
The pod we're using has 2 containers, one that runs the daemon, and one that keeps the user separated from the privileged pod completely.
We have created deploy.yaml and we have dind-rootless running.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
dind-rootless-5ddddf649b-sk9bv 2/2 Running 0 106s
Now we open a shell in the user container in the dind-rootless-$HASH pod.
$ kubectl exec -it dind-rootless-5ddddf649b-sk9bv -c user -- sh
Lets see if we can actually be root.
/ $ docker run --privileged --rm -it -v /:/host/ ubuntu:20.04 chroot /host/ sh
/ # fdisk -l
Disk /dev/vda: 60 GB, 63999836160 bytes, 124999680 sectors
61035 cylinders, 64 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/vda1 1,0,1 618,63,32 2048 124999679 124997632 59.6G 83 Linux
Well, looks like we're really root.
/ # mount /dev/vda1 /mnt
mount: permission denied (are you root?)
Lets go fishing, I backed out of the container.
/ $ docker run --privileged --rm -it -v /:/host/ ubuntu:20.04 bash
root@bcebcc8770c4:/# apt update && apt install libcap2-bin -y
root@bcebcc8770c4:/# capsh --print
WARNING: libcap needs an update (cap=40 should have a name).
Current: =eip 38,39,40-eip
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=
Guessed mode: UNCERTAIN (0)
Let's try to get out of the namespace...
Can I write files outside of the container?
root@bcebcc8770c4:/# nsenter --target "1" --mount --uts --ipc --net --pid -- bash
root@bcebcc8770c4:/# echo hacked > /test-hack.txt
root@bcebcc8770c4:/# exit
root@bcebcc8770c4:/# cat /test-hack.txt
hacked
Can I see pids outside of the container?
root@bcebcc8770c4:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 4240 3516 pts/0 Ss 03:41 0:00 bash
root 758 0.0 0.0 5904 3020 pts/0 R+ 03:49 0:00 ps aux
root@bcebcc8770c4:/# nsenter --target "1" --mount --uts --ipc --net --pid -- bash
root@bcebcc8770c4:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 4240 3516 pts/0 Ss 03:41 0:00 bash
root 759 0.0 0.0 3436 700 pts/0 S 03:49 0:00 nsenter --target 1 --mount --uts --ipc --net --pid -- bash
root 760 0.0 0.0 4116 3412 pts/0 S 03:49 0:00 bash
root 763 0.0 0.0 5904 3016 pts/0 R+ 03:49 0:00 ps aux
Try messing with modules.
root@bcebcc8770c4:/# apt install kmod -y
root@bcebcc8770c4:/# lsmod
Module Size Used by
grpcfuse 16384 0
xfrm_user 36864 2
xfrm_algo 16384 1 xfrm_user
vmw_vsock_virtio_transport 16384 0
vmw_vsock_virtio_transport_common 28672 1 vmw_vsock_virtio_transport
vsock 36864 5 vmw_vsock_virtio_transport_common,vmw_vsock_virtio_transport
root@bcebcc8770c4:/# modprobe -r vsock
root@bcebcc8770c4:/# lsmod
Module Size Used by
grpcfuse 16384 0
xfrm_user 36864 2
xfrm_algo 16384 1 xfrm_user
vmw_vsock_virtio_transport 16384 0
vmw_vsock_virtio_transport_common 28672 1 vmw_vsock_virtio_transport
vsock 36864 5 vmw_vsock_virtio_transport_common,vmw_vsock_virtio_transport
I also can't get anything else mentioned here to work.
I would love to see if anyone else could break this. I doubt it's bulletproof.