AppArmor (Application Armor) es un módulo de seguridad de Linux que protege un sistema operativo y sus aplicaciones de las amenazas de seguridad. Para usarlo, un administrador del sistema asocia un perfil de seguridad de AppArmor con cada programa. Docker espera encontrar una política de AppArmor cargada y aplicada.
Docker genera y carga automáticamente un perfil predeterminado para contenedores denominados docker-default. En las versiones de Docker 1.13.0 y luego, el binario de Docker genera este perfil en tmpfs y luego lo carga en el kernel. En versiones de Docker anteriores a 1.13.0, este perfil se genera en /etc/apparmor.d/docker en lugar de.
Nota: Este perfil se utiliza en contenedores, no en el Docker Daemon.
Existe un perfil para el demonio de Docker Engine, pero actualmente no está instalado con el deb paquetes. Si está interesado en la fuente del perfil del demonio, se encuentra en contrib / apparmor en el repositorio de origen de Docker Engine.
Entender las políticas
los docker-default profile es el valor predeterminado para ejecutar contenedores. Es moderadamente protector al tiempo que proporciona una amplia compatibilidad de aplicaciones. El perfil se genera a partir de lo siguiente plantilla.
Cuando ejecuta un contenedor, usa el docker-default política a menos que la anule con la security-opt opción. Por ejemplo, lo siguiente especifica explícitamente la política predeterminada:
$ docker run --rm -it --security-opt apparmor=docker-default hello-world
Cargar y descargar perfiles
Para cargar un nuevo perfil en AppArmor para usar con contenedores:
$ apparmor_parser -r -W /path/to/your_profile
Luego, ejecute el perfil personalizado con --security-opt al igual que:
$ docker run --rm -it --security-opt apparmor=your_profile hello-world
Para descargar un perfil de AppArmor:
# unload the profile $ apparmor_parser -R /path/to/profile
Recursos para escribir perfiles
La sintaxis del globbing de archivos en AppArmor es un poco diferente a la de otras implementaciones de globbing. Se recomienda encarecidamente que eche un vistazo a algunos de los recursos a continuación con respecto a la sintaxis del perfil de AppArmor.
Perfil de ejemplo de Nginx
En este ejemplo, crea un perfil de AppArmor personalizado para Nginx. A continuación se muestra el perfil personalizado.
#includeprofile docker-nginx flags=(attach_disconnected,mediate_deleted) #include network inet tcp, network inet udp, network inet icmp, deny network raw, deny network packet, file, umount, deny /bin/** wl, deny /boot/** wl, deny /dev/** wl, deny /etc/** wl, deny /home/** wl, deny /lib/** wl, deny /lib64/** wl, deny /media/** wl, deny /mnt/** wl, deny /opt/** wl, deny /proc/** wl, deny /root/** wl, deny /sbin/** wl, deny /srv/** wl, deny /tmp/** wl, deny /sys/** wl, deny /usr/** wl, audit /** w, /var/run/nginx.pid w, /usr/sbin/nginx ix, deny /bin/dash mrwklx, deny /bin/sh mrwklx, deny /usr/bin/top mrwklx, capability chown, capability dac_override, capability setuid, capability setgid, capability net_bind_service, deny @PROC/* w, # deny write for all files directly in /proc (not in a subdir) # deny write to files not in /proc/ /** or /proc/sys/** deny @PROC/[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*/** w, deny @PROC/sys/[^k]** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel) deny @PROC/sys/kernel/?,??,[^s][^h][^m]** w, # deny everything except shm* in /proc/sys/kernel/ deny @PROC/sysrq-trigger rwklx, deny @PROC/mem rwklx, deny @PROC/kmem rwklx, deny @PROC/kcore rwklx, deny mount, deny /sys/[^f]*/** wklx, deny /sys/f[^s]*/** wklx, deny /sys/fs/[^c]*/** wklx, deny /sys/fs/c[^g]*/** wklx, deny /sys/fs/cg[^r]*/** wklx, deny /sys/firmware/** rwklx, deny /sys/kernel/security/** rwklx,
-
Guarde el perfil personalizado en el disco en el
/etc/apparmor.d/containers/docker-nginxexpediente.La ruta del archivo en este ejemplo no es un requisito. En producción, podría usar otro.
-
Cargue el perfil.
$ sudo apparmor_parser -r -W /etc/apparmor.d/containers/docker-nginx
-
Ejecute un contenedor con el perfil.
Para ejecutar nginx en modo independiente:
$ docker run --security-opt "apparmor=docker-nginx" -p 80:80 -d --name apparmor-nginx nginx -
Ejecutar en el contenedor en ejecución.
$ docker container exec -it apparmor-nginx bash
-
Pruebe algunas operaciones para probar el perfil.
[email protected]:~# ping 8.8.8.8 ping: Lacking privilege for raw socket. [email protected]:/# top bash: /usr/bin/top: Permission denied [email protected]:~# touch ~/thing touch: cannot touch 'thing': Permission denied [email protected]:/# sh bash: /bin/sh: Permission denied [email protected]:/# dash bash: /bin/dash: Permission denied
¡Felicitaciones! ¡Acaba de implementar un contenedor protegido con un perfil de apariencia personalizado!
Depurar AppArmor
Puedes usar dmesg para depurar problemas y aa-status comprobar los perfiles cargados.
Utilice dmesg
A continuación, se incluyen algunos consejos útiles para depurar cualquier problema que pueda tener con AppArmor.
AppArmor envía mensajes bastante detallados a dmesg. Por lo general, una línea de AppArmor tiene el siguiente aspecto:
[ 5442.864673] audit: type=1400 audit(1453830992.845:37): apparmor="ALLOWED" operation="open" profile="/usr/bin/docker" name="/home/jessie/docker/man/man1/docker-attach.1" pid=10923 comm="docker" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
En el ejemplo anterior, puede ver profile=/usr/bin/docker. Esto significa que el usuario tiene la docker-engine Se cargó el perfil (Docker Engine Daemon).
Nota: En la versión de Ubuntu> 14.04, todo está bien, pero los usuarios de Trusty pueden tener algunos problemas al intentar
docker container exec.
Mira otra línea de registro:
[ 3256.689120] type=1400 audit(1405454041.341:73): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=17651 comm="docker" requested_mask="receive" denied_mask="receive"
Esta vez el perfil es docker-default, que se ejecuta en contenedores de forma predeterminada a menos que en privileged modo. Esta línea muestra que apparmor ha negado ptrace en el contenedor. Esto es exactamente como se esperaba.
Utilice aa-status
Si necesita verificar qué perfiles están cargados, puede usar aa-status. La salida se ve así:
$ sudo aa-status apparmor module is loaded. 14 profiles are loaded. 1 profiles are in enforce mode. docker-default 13 profiles are in complain mode. /usr/bin/docker /usr/bin/docker///bin/cat /usr/bin/docker///bin/ps /usr/bin/docker///sbin/apparmor_parser /usr/bin/docker///sbin/auplink /usr/bin/docker///sbin/blkid /usr/bin/docker///sbin/iptables /usr/bin/docker///sbin/mke2fs /usr/bin/docker///sbin/modprobe /usr/bin/docker///sbin/tune2fs /usr/bin/docker///sbin/xtables-multi /usr/bin/docker///sbin/zfs /usr/bin/docker///usr/bin/xz 38 processes have profiles defined. 37 processes are in enforce mode. docker-default (6044) ... docker-default (31899) 1 processes are in complain mode. /usr/bin/docker (29756) 0 processes are unconfined but have a profile defined.
La salida anterior muestra que el docker-default El perfil que se ejecuta en varios PID de contenedor está en enforce modo. Esto significa que AppArmor está bloqueando y auditando activamente en dmesg cualquier cosa fuera de los límites del docker-default perfil.
La salida anterior también muestra el /usr/bin/docker El perfil (demonio del motor de Docker) se está ejecutando en complain modo. Esto significa AppArmor solamente se registra en dmesg actividad fuera de los límites del perfil. (Excepto en el caso de Ubuntu Trusty, donde se aplican algunos comportamientos interesantes).
Contribuya con el código de AppArmor de Docker
Los usuarios avanzados y los administradores de paquetes pueden encontrar un perfil para /usr/bin/docker (Docker Engine Daemon) debajo contrib / apparmor en el repositorio de origen de Docker Engine.
los docker-default perfil para contenedores vive en perfiles / apparmor.
AppArmor, seguridad, estibador, documentación
Puntuaciones y comentarios
Tienes la opción de añadir valor a nuestra información contribuyendo tu experiencia en las referencias.