Kiedy uruchamiasz kontener jako uprzywilejowany, wyłączasz następujące zabezpieczenia:
Montowanie /dev
W uprzywilejowanym kontenerze wszystkie urządzenia mogą być dostępne w /dev/. Dlatego możesz uciec przez zamontowanie dysku hosta.
# docker run --rm -it alpine shls/devconsolefdmqueueptmxrandomstderrstdouturandomcorefullnullptsshmstdinttyzero
# docker run --rm --privileged -it alpine shls/devcachefilesmapperportshmtty24tty44tty7consolemempsauxstderrtty25tty45tty8coremqueueptmxstdintty26tty46tty9cpunbd0ptsstdouttty27tty47ttyS0[...]
Systemy plików jądra tylko do odczytu
Systemy plików jądra zapewniają mechanizm, który pozwala procesowi modyfikować zachowanie jądra. Jednak w przypadku procesów kontenerowych chcemy zapobiec ich wprowadzaniu jakichkolwiek zmian w jądrze. Dlatego montujemy systemy plików jądra jako tylko do odczytu w obrębie kontenera, zapewniając, że procesy kontenerowe nie mogą modyfikować jądra.
# docker run --rm --privileged -it alpine shmount|grep'(ro'
Maskowanie nad systemami plików jądra
System plików /proc jest selektywnie zapisywalny, ale dla bezpieczeństwa, niektóre części są chronione przed dostępem do zapisu i odczytu poprzez nałożenie na nie tmpfs, co zapewnia, że procesy kontenera nie mogą uzyskać dostępu do wrażliwych obszarów.
tmpfs to system plików, który przechowuje wszystkie pliki w pamięci wirtualnej. tmpfs nie tworzy żadnych plików na twoim dysku twardym. Więc jeśli odmontujesz system plików tmpfs, wszystkie pliki w nim zawarte zostaną na zawsze utracone.
# docker run --rm -it alpine shmount|grep/proc.*tmpfstmpfson/proc/acpitypetmpfs (ro,relatime)tmpfson/proc/kcoretypetmpfs (rw,nosuid,size=65536k,mode=755)tmpfson/proc/keystypetmpfs (rw,nosuid,size=65536k,mode=755)
# docker run --rm --privileged -it alpine shmount|grep/proc.*tmpfs
Możliwości Linuxa
Silniki kontenerowe uruchamiają kontenery z ograniczoną liczbą możliwości, aby kontrolować, co dzieje się wewnątrz kontenera domyślnie. Privileged mają wszystkiemożliwości dostępne. Aby dowiedzieć się więcej o możliwościach, przeczytaj:
# docker run --rm -it alpine shapkadd-Ulibcap; capsh--print[...]Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
[...]
# docker run --rm --privileged -it alpine shapkadd-Ulibcap; capsh--print[...]Current:=eipcap_perfmon,cap_bpf,cap_checkpoint_restore-eipBounding 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
[...]
Możesz manipulować możliwościami dostępnymi dla kontenera bez uruchamiania w trybie --privileged, używając flag --cap-add i --cap-drop.
Seccomp
Seccomp jest przydatny do ograniczeniasyscalli, które kontener może wywołać. Domyślny profil seccomp jest włączony domyślnie podczas uruchamiania kontenerów docker, ale w trybie uprzywilejowanym jest wyłączony. Dowiedz się więcej o Seccomp tutaj:
# docker run --rm -it alpine shgrepSeccomp/proc/1/statusSeccomp:2Seccomp_filters:1
# docker run --rm --privileged -it alpine shgrepSeccomp/proc/1/statusSeccomp:0Seccomp_filters:0
# You can manually disable seccomp in docker with--security-optseccomp=unconfined
Również zauważ, że gdy Docker (lub inne CRI) są używane w klastrze Kubernetes, filtr seccomp jest domyślnie wyłączony.
AppArmor
AppArmor to ulepszenie jądra, które ogranicza kontenery do ograniczonego zestawu zasobów z profilami per program. Gdy uruchamiasz z flagą --privileged, ta ochrona jest wyłączona.
# You can manually disable seccomp in docker with--security-optapparmor=unconfined
SELinux
Uruchomienie kontenera z flagą --privileged wyłącza etykiety SELinux, powodując, że dziedziczy on etykietę silnika kontenerowego, zazwyczaj unconfined, co przyznaje pełny dostęp podobny do silnika kontenerowego. W trybie bezrootowym używa container_runtime_t, podczas gdy w trybie rootowym stosuje spc_t.
# You can manually disable selinux in docker with--security-optlabel:disable
Co nie ma wpływu
Przestrzenie nazw
Przestrzenie nazw NIE są dotknięte flagą --privileged. Mimo że nie mają włączonych ograniczeń bezpieczeństwa, nie widzą wszystkich procesów w systemie ani hosta sieciowego, na przykład. Użytkownicy mogą wyłączyć poszczególne przestrzenie nazw, używając flag silnika kontenerów --pid=host, --net=host, --ipc=host, --uts=host.
# docker run --rm --privileged -it alpine shps-efPIDUSERTIMECOMMAND1root0:00sh18root0:00ps-ef
Domyślnie silniki kontenerów nie wykorzystują przestrzeni nazw użytkownika, z wyjątkiem kontenerów bezrootowych, które ich wymagają do montowania systemu plików i używania wielu UID. Przestrzenie nazw użytkownika, niezbędne dla kontenerów bezrootowych, nie mogą być wyłączane i znacznie zwiększają bezpieczeństwo, ograniczając uprawnienia.
