AppArmor: una mejora del kernel para confinar programas a un conjunto limitado de recursos.

DESCRIPCIÓN

AppArmor es una mejora del kernel para confinar programas a un conjunto limitado de recursos. El modelo de seguridad único de AppArmor consiste en vincular atributos de control de acceso a programas en lugar de a usuarios.

El confinamiento de AppArmor se proporciona a través de perfiles cargados en el kernel mediante apparmor_parser(8), normalmente a través de la unidad systemd apparmor.service, que se utiliza de la siguiente manera:

systemctl start apparmor

systemctl reload apparmor

AppArmor puede funcionar en dos modos: aplicación y modo de advertencia o aprendizaje:

aplicación: los perfiles cargados en modo de aplicación darán como resultado la aplicación de la política definida en el perfil, así como el envío de intentos de violación de la política a syslogd.

advertencia: los perfiles cargados en modo "advertencia" no aplicarán la política. En cambio, informarán sobre los intentos de violación de la política. Este modo es conveniente para desarrollar perfiles. Para administrar el modo de advertencia para perfiles individuales, se pueden usar las utilidades aa-complain(8) y aa-enforce(8). Estas utilidades toman el nombre de un programa como argumento.

Tradicionalmente, los perfiles se almacenan en archivos en /etc/apparmor.d/ bajo nombres de archivo con la convención de reemplazar la barra (/) en las rutas con un punto (.) (excepto para la raíz /), para que los perfiles sean más fáciles de administrar (por ejemplo, el perfil /usr/sbin/nscd tendría el nombre usr.sbin.nscd).

Los perfiles se aplican a un proceso en el momento de exec(3) (tal como se ve a través de la llamada al sistema execve(2)): una vez que se carga un perfil para un programa, ese programa se limitará en el siguiente exec(3). Si un proceso ya se está ejecutando bajo un perfil, cuando se reemplace ese perfil en el kernel, el perfil actualizado se aplicará inmediatamente a ese proceso. Por otro lado, un proceso que ya se está ejecutando sin confinamiento no se puede confinar.

AppArmor es compatible con el sistema de archivos securityfs del kernel de Linux y pone a disposición la lista de perfiles cargados actualmente; para montar el sistema de archivos:

mount -tsecurityfs securityfs /sys/kernel/security

$ cat /sys/kernel/security/apparmor/profiles /usr/bin/mutt /usr/bin/gpg ...

Normalmente, el script de inicio montará securityfs si aún no se ha hecho.

AppArmor también restringe las operaciones con privilegios que puede ejecutar un proceso confinado, incluso si el proceso se está ejecutando como root. Un proceso confinado no puede llamar a las siguientes llamadas al sistema:

create_module(2) delete_module(2) init_module(2) ioperm(2) iopl(2) ptrace(2) reboot(2) setdomainname(2) sethostname(2) swapoff(2) swapon(2) sysctl(2)

Modo de advertencia

En lugar de denegar el acceso a los recursos para los que el perfil no tiene una regla, AppArmor puede "permitir" el acceso y registrar un mensaje para la operación que lo activa. Esto se llama modo de advertencia. Es importante tener en cuenta que las reglas que están presentes en el perfil siguen aplicándose, por lo que las reglas de permiso seguirán silenciando o forzando mensajes de auditoría, y las reglas de denegación seguirán dando como resultado denegaciones y el silenciamiento de los mensajes de denegación (vea Desactivar el silenciamiento de las auditorías de denegación si esto es un problema).

El modo de advertencia se puede utilizar para desarrollar perfiles de forma incremental a medida que se ejecuta una aplicación. Los accesos registrados se pueden agregar al perfil y luego se puede ejecutar la aplicación para descubrir más adiciones que se necesiten. Debido a que AppArmor permite los accesos, la aplicación se comportará como si AppArmor no la estuviera confinando.

Advertencia: el modo de advertencia no proporciona ninguna seguridad, solo auditoría, mientras está habilitado. No debe utilizarse en un entorno hostil o pueden registrarse comportamientos incorrectos y agregarse al perfil como si fueran accesos a recursos que debería utilizar la aplicación.

Tenga en cuenta que el modo de advertencia puede ser muy ruidoso con perfiles nuevos o vacíos, pero con perfiles desarrollados, es posible que no registre nada si el perfil cubre bien el comportamiento de la aplicación. Consulte la limitación de la frecuencia de auditoría si el modo de advertencia está generando demasiados mensajes de registro.

Para establecer un perfil y cualquier hijo o perfiles "hat" que el perfil pueda contener en modo de advertencia, utilice

aa-complain /etc/apparmor.d/

Para establecer manualmente un perfil específico en modo de advertencia, agregue el indicador "advertencia" y luego vuelva a cargar manualmente el perfil:

profile foo flags=(complain) { ... }

Tenga en cuenta que el indicador "advertencia" también debe agregarse manualmente a cualquier "hat" o perfil secundario del perfil, de lo contrario, seguirán utilizando el modo anterior.

Para habilitar el modo de advertencia globalmente, ejecute:

echo -n complain > /sys/module/apparmor/parameters/mode

o para configurarlo al inicio, agregue:

apparmor.mode=complain

como parámetro de inicio del kernel.

Advertencia: establecer el modo de advertencia globalmente desactiva todas las protecciones de seguridad de AppArmor. Puede ser útil durante la depuración o el desarrollo de perfiles, pero establecerlo de forma selectiva en cada perfil es más seguro.

ERRORES

Cuando un proceso confinado intenta acceder a un archivo al que no tiene permiso de acceso, el kernel informará de un mensaje a través de audit, similar a:

audit(1386511672.612:238): apparmor="DENIED" operation="exec"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0

audit(1386511672.613:239): apparmor="DENIED" operation="open"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

audit(1386511772.804:246): apparmor="DENIED" operation="capable"
parent=7246 profile="/tmp/sh" pid=7589 comm="sh" pid=7589
comm="sh" capability=2 capname="dac_override"

Los permisos solicitados por el proceso se describen en operation= y denied_mask= (para archivos, las capacidades, etc., se utiliza un formato de registro ligeramente diferente). Se informa el "nombre" y el ID del proceso del programa que se está ejecutando, así como el nombre del perfil, incluido cualquier "hat" que pueda estar activo, separados por "//". ("Nombre" está entre comillas, porque el nombre del proceso está limitado a 15 bytes; es el mismo que se informa a través de la contabilidad de procesos de Berkeley).

Para los procesos confinados que se ejecutan bajo un perfil que se ha cargado en modo de denuncia, la aplicación de las políticas no se realizará y los mensajes de registro que se informen a audit tendrán el siguiente formato:

audit(1386512577.017:275): apparmor="ALLOWED" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

audit(1386512577.017:276): apparmor="ALLOWED" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Si el auditd del espacio de usuario no se está ejecutando, el kernel enviará eventos de auditoría a klogd; klogd enviará los mensajes a syslog, que registrará los mensajes con la instalación KERN. Por lo tanto, los mensajes de RECHAZO y PERMISO pueden ir a /var/log/audit/audit.log o /var/log/messages, dependiendo de la configuración local.

DEPURACIÓN

AppArmor proporciona algunas funciones para registrar más información, lo que puede ayudar a depurar los perfiles.

Habilitar el modo de depuración

Cuando se habilita el modo de depuración, AppArmor registrará algunos mensajes adicionales en dmesg (no a través del subsistema de auditoría). Por ejemplo, los registros indicarán si se ha aplicado el filtrado de variables de entorno.

Para habilitar el modo de depuración, ejecute:

echo 1 > /sys/module/apparmor/parameters/debug

o para configurarlo al inicio, agregue:

apparmor.debug=1

como parámetro de arranque del kernel.

Desactivar el silenciamiento de la auditoría de denegación

De forma predeterminada, las operaciones que activan las reglas de "denegación" no se registran. Esto se denomina silenciamiento de la auditoría de denegación.

Para desactivar el silenciamiento de la auditoría de denegación, ejecute:

echo -n noquiet >/sys/module/apparmor/parameters/audit

o para configurarlo al inicio, agregue:

apparmor.audit=noquiet

como parámetro de arranque del kernel.

Forzar el modo de auditoría

AppArmor puede registrar un mensaje para cada operación que active una regla configurada en la política.

Esto se denomina modo de auditoría forzada.

¡Advertencia! El modo de auditoría forzada puede generar una gran cantidad de mensajes, incluso para un solo perfil, y mucho más cuando se habilita a nivel global.

Para configurar un perfil específico en modo de auditoría forzada, agregue el indicador "audit":

profile foo flags=(audit) { ... }

Para habilitar el modo de auditoría forzada a nivel global, ejecute:

echo -n all > /sys/module/apparmor/parameters/audit

o para configurarlo al inicio, agregue:

apparmor.audit=all

como parámetro de arranque del kernel.

Limitación de la tasa de auditoría

Si auditd no se está ejecutando, para evitar perder demasiados de los mensajes de registro adicionales, probablemente deberá desactivar la limitación de la tasa ejecutando:

echo 0 > /proc/sys/kernel/printk_ratelimit

Pero incluso entonces, el búfer de anillo del kernel puede desbordarse y es posible que se pierdan mensajes.

De lo contrario, si auditd se está ejecutando, consulte auditd(8) y auditd.conf(5).

ARCHIVOS

/etc/apparmor.d/
/var/cache/apparmor/
/var/log/audit/audit.log
/var/log/messages

VER TAMBIÉN

apparmor_parser(8), aa_change_hat(2), apparmor.d(5), aa-autodep(1), clean(1), auditd(8),