J

eśli nie używasz dockera z pomocą docker-machine (standardowo na systemie OSX oraz Windows) to może dojść do sytuacji, gdy polecenia dockera doprowadzą do przejęcia hosta na którym zostały uruchomione. Jeśli dodamy naszego użytkownika systemu do grupy dockera lub zmienimy uprawnienia do gniazda sieciowego – to Twój użytkownik lub szkodliwe oprogramowanie będzie mógło uzyskać uprawnienia administratora bez konieczności podawania hasła.

Jeśli wpisujesz na swoim laptopie sudo docker run, sudo docker-compose logs kilkanaście razy dziennie – zachodzi pokusa, aby darować sobie sudo, aby co chwilę nie wpisywać hasła. Dwoma “klasycznymi” rozwiązaniami są wcześniej wspomniane:

• dodanie użytkownika do grupy docker (gpasswd -a $USER docker),
• zmiana uprawnień do gniazda sieciowego dockera (chmod 777 /var/run/docker.sock)

Jeśli bierzemy jedno z tych rozwiązań pod uwagę to musimy zdawać sobie sprawę z kilku rzeczy:

$ docker run -v /:/hostOS -i -t ubuntu

root@7a064e899aa3:/# whoami
root
root@7a064e899aa3:/# cat /hostOS/etc/shadow
at:!:17339::::::

Co się stało?

Z poziomu uruchomionego dockera byliśmy w stanie odczytać plik z (zaszyfrowanymi) hasłami naszego, własnego laptopa. Oczywiście możemy je zmienić, usunąć lub stworzyć innego użytkownika z uprawnieniami administratora itd. Dzięki opcji -v “zamontowaliśmy” główny folder naszego laptopa pod folderem /hostOS na kontenerze. Uruchamianie dowolnego obrazu kontenera z użytkownika administratora (root – standard dla większości obrazów dockera) daje nam uprawnienia administratora w środku kontenera i zarazem uprawnienia administratora do wszystkich plików i poleceń na laptopie.

Możemy nawet utworzyć program należący do administratora z ustawionym bitem setuid – umożliwiając dowolnemu użytkownikowi stanie się administratorem systemu. Taka furtka mogłaby zostać użyta nawet po naprawie uprawnień lub usunięciu dockera z systemu.

Jakie jest ryzyko?

Istnieje wiele powodów, dla których uruchamianie programów z uprawnieniami administratora na komputerze może być niebezpieczne. Na przykład:

• bezpośrednie wykonywanie obcego, niezaufanego kodu (poprzez kopiuj / wklej: curl https://.../script.sh | sh),
• uruchamianie programów, które posiadają różne podatności (ostatnio było to zdalne wykonanie kodu w edytorze Atom),
• ściąganie i uruchamianie obrazów z ukrytym, szkodliwym oprogramowaniem (cyberprzestępcy również idą z duchem czasu i wykorzystali obrazy dockerowe do umieszczenia w nich koparek kryptowalut).

Co zrobić? Jak żyć?

Skoro już wiemy, czym właściwie grozi pozbycie się używania polecenia sudo – to mamy kilka dróg do wyboru:

• zawsze używanie sudo – gwarantuje to, że nadal możemy podnieść swoje uprawnienia do roli administratora, ale w bardziej kontrolowany i upominający nas sposób,
• zamknięcie dockera w dodatkowej maszynie wirtualnej – skoro OSX oraz Windows korzystają z Docker Machine (która jest w zasadzie wirtualną maszyną będącą pochodną systemu Linux) to nic nie stoi na przeszkodzie, byśmy zamknęli go w dodatkowej warstwie np. za pomocą systemu Linux uruchomionym na Virtual Box,
• zaakceptowanie ryzyka związanego z otwieraniem furtki poprzez eskalację uprawnień w swoim systemie (czego stanowczo odradzam)

Zawsze miejmy na uwadze, że nawet jeśli jesteśmy w stanie porzucić sudo na swojej maszynie i na tej konwencji zbudować swoje, dowolne rozwiązanie – to na serwerach produkcyjnych może okazać się, że przestaje ono działać, ponieważ ze względu na dostęp do wrażliwych danych uprawnienia dockera zostały mocno ograniczone.

Więcej informacji: Linux users: running docker without sudo is dangerous, Docker daemon attack surface