Curso de Ubuntu 26.04 / AppArmor: revisar perfiles y registros de denegación
AppArmor es un control de acceso adicional que restringe el comportamiento de archivos, ejecución, red, etc., mediante perfiles específicos para cada programa. Al investigar errores de permisos, se deben verificar juntos los permisos de archivos generales, los perfiles aplicados y los registros de denegación, y no se debe desactivar AppArmor por completo como primera solución.
Diferencia entre permisos generales y perfiles
Incluso si el UID, grupo y modo de archivo del usuario están permitidos, AppArmor puede bloquear el acceso de ese programa. Por el contrario, la ausencia de registros de AppArmor no significa necesariamente que los permisos de directorio generales, el montaje de solo lectura o los problemas de cuentas de servicio estén bien. Primero se deben registrar las rutas que realmente fallaron y las cuentas con las que se ejecutan los procesos.
Verificar los perfiles y modos actuales
sudo aa-status
systemctl status apparmor --no-pagerEnforce y complain en los perfiles funcionan de manera diferente. El modo enforce aplica la política. El modo complain registra infracciones de las reglas de permisos para facilitar la investigación, pero reduce la protección y no convierte las reglas deny explícitas en permisos. No se debe asumir que todos los procesos están restringidos solo por el estado del servicio, sino que se deben revisar los perfiles reales y los procesos asociados mediante aa-status.
Comparar los registros inmediatamente después del fallo con las solicitudes
sudo journalctl -k -b --since '10 minutes ago' --no-pager | grep 'apparmor="DENIED"'Se registra la hora en que se reprodujo un fallo y se comparan profile·operation·name·pid·requested_mask·denied_mask. Use la salida real para comprobar que el programa y la solicitud coinciden con el fallo; el ejemplo siguiente solo ilustra los campos. Como puede incluir rutas internas e información del usuario, deje solo la parte necesaria al compartir.
Si no hay salida, vuelva a verificar el arranque actual·intervalo de tiempo·ruta de recopilación de registros y el perfil real. Como las reglas de denegación explícitas, etc., pueden no generar registros de la manera esperada, la falta de registros no se considera evidencia de que la política permita la operación.
Leer los campos del registro de denegación como ejemplo
La siguiente línea es un ejemplo ficticio creado para explicar los campos y no es un resultado recopilado en un dispositivo Ubuntu específico. profile es la política del programa restringido, operation es la acción intentada, name es la ruta objetivo, y r en requested_mask y denied_mask indica solicitud y denegación de lectura.
apparmor="DENIED" operation="open" profile="/usr/sbin/example-app" name="/srv/example-data/settings.ini" requested_mask="r" denied_mask="r"En la investigación real, se comparan la hora del fallo, el proceso, la cuenta de ejecución y la ruta con los registros. No es una recomendación para agregar permisos de lectura a las rutas del ejemplo. Puede ser más apropiado restaurar la ubicación de datos de la aplicación incorrecta a la ubicación admitida originalmente y no se permiten todas las solicitudes que aparecen en los registros.
Encontrar el propietario del perfil y la configuración
El perfil general busca ese nombre y ruta de ejecución en /etc/apparmor.d. Las aplicaciones en las que las políticas se crean como Snap revisan la interfaz Snap y la configuración del proveedor en lugar de modificar directamente los archivos creados. No se estima el nombre del archivo para crear un nuevo perfil ni se copia la política de otro programa.
Si el cambio de ruta es la causa, primero se debe considerar cómo devolver los datos a la ubicación que la aplicación admite. Si se requiere modificar la política, se deben definir las acciones requeridas reales, la ruta exacta del archivo y los rangos de lectura/escritura, y respaldar el archivo original y la configuración local incluida. No se permite todo el disco con comodines amplios.
Inspeccionar el perfil sin cambiar la política del kernel
Revise un archivo real de un perfil general e introduzca su ruta cuando se le solicite a continuación. Las políticas generadas automáticamente por Snap están excluidas de esta práctica de edición. -Q omite la carga del kernel y -K omite tanto la lectura como la escritura de la caché. Incluso si la inspección se aprueba, no significa que se haya completado la prueba del acceso que debe permitirse o denegarse de la aplicación.
(
set -eu
read -r -p 'Actual ordinary profile path under /etc/apparmor.d/: ' profile
case "$profile" in
/etc/apparmor.d/*) ;;
*) printf 'Choose the verified profile source.\n' >&2; exit 1 ;;
esac
sudo test -f "$profile"
sudo apparmor_parser -Q -K "$profile"
)Si es necesario modificar la política real de manera restrictiva, primero haga una copia de seguridad del archivo original y de los archivos locales incluidos, luego, tras pasar la inspección, lea nuevamente ese perfil con sudo apparmor_parser -r archivo_de_perfil_real. Si falla, solo restaure la copia de seguridad del mismo archivo, inspeccione y aplique nuevamente, y verifique el estado de aa-status y el estado enforce original. Para solo practicar la inspección en este artículo, no ejecute el comando reload.
Cambios limitados y criterios de verificación/restauración
Verifique la sintaxis del perfil modificado usando las herramientas oficiales, luego haga que solo se vuelva a leer ese perfil y pruebe por separado las acciones que deben permitirse y las que deben seguir bloqueándose. No apruebe automáticamente todas las solicitudes en los registros basándose solo en las reglas de permisos sugeridas por las herramientas de diagnóstico; revise la necesidad de cada una.
Si falla, restaure solo este cambio de política y verifique nuevamente el estado original de enforce y el comportamiento de la aplicación. No ajuste los resultados usando comandos que apaguen todo el servicio de AppArmor o la protección de los espacios de nombres de usuario. Los registros de finalización deben incluir la causa, la ruta de la política, el alcance del cambio, las pruebas de permiso y denegación, y el método de restauración.
