SUSE anunció SLES 16.0 el 4 de noviembre de 2025, con SELinux reemplazando a AppArmor como marco de control de acceso obligatorio predeterminado. Si su servidor ejecuta SLES 16, no dé por sentado que AppArmor está instalado o activo: confirme el marco compatible con esa implementación antes de usar estos comandos. El procedimiento que se describe a continuación sigue la documentación de AppArmor de SUSE para SLES 15 SP7, donde AppArmor está instalado y en ejecución de forma predeterminada.
En SLES 15 SP7, la ruta práctica para una aplicación personalizada consiste en aa-genprofcrear un perfil inicial, probar la aplicación en modo de queja, revisar cada solicitud registrada y, finalmente, confirmar que el perfil se está aplicando correctamente. El ejemplo utiliza un ejecutable hipotético en /usr/local/bin/report-worker; reemplácelo con la ruta real del ejecutable de su aplicación.
Los perfiles de AppArmor son políticas de texto almacenadas en /etc/apparmor.d. El apparmor-utilspaquete proporciona las herramientas de creación de perfiles. Compruebe el host e identifique el ejecutable real, incluyendo si una unidad systemd inicia un proceso contenedor o un proceso hijo:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE indica que AppArmor está habilitado por defecto en las instalaciones de SLES 15. Si faltan las herramientas o el patrón completo de AppArmor, instálelo con sudo zypper in -t pattern apparmor. Si AppArmor no está activo, averigüe la causa antes de crear un perfil, en lugar de asumir que un archivo de perfil por sí solo proporciona protección. Un perfil se adjunta a una ruta ejecutable; crear un perfil de un contenedor cuando la carga de trabajo real se ejecuta como otro binario puede dejar el proceso importante sin protección.
Inicie el generador. Detenga la aplicación si ya se está ejecutando y, a continuación, inicie la generación del perfil:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
El nombre del servicio es un ejemplo. Use el nombre real de la unidad o omita el comando de parada si el programa no se está ejecutando. aa-genprofCrea un perfil aproximado cuando no existe, lo pone en modo de queja (aprendizaje), lo recarga y marca el registro. El modo de queja registra las solicitudes que no cumplen con la política, pero las permite; es un estado de aprendizaje temporal, no de aplicación de la normativa.
Simula el comportamiento de una aplicación real. Mantén el generador abierto. En otra terminal, inicia el servicio y ejecuta trabajos o funciones representativas:
sudo systemctl start report-worker
sudo journalctl -f
Cubre el inicio normal, las rutas de entrada y salida esperadas, las tareas programadas, el manejo de errores y cualquier programa auxiliar que la aplicación inicie. Un perfil solo puede aprender las solicitudes generadas durante la prueba. No uses cargas de trabajo sensibles a la producción solo para generar eventos; es preferible un entorno de prueba seguro y datos de prueba representativos.
Revise cada solicitud de acceso. Vuelva a la pantalla anterior aa-genprofy pulse Spara escanear el rango de registros marcado. Para cada solicitud, determine si la aplicación realmente necesita ese archivo, capacidad o transición de programa secundario. Permita la ruta y el permiso útiles más limitados. Acepte una abstracción cuando cubra con precisión una tarea común; utilice un patrón solo cuando los archivos coincidentes compartan los mismos requisitos de confianza y acceso. Deniegue u omita las solicitudes que sean incidentales o inexplicables.
Preste especial atención a la ejecución de las solicitudes. Una transición sin restricciones puede permitir que un elemento secundario eluda la política del elemento principal; úsela solo cuando exista una necesidad de diseño justificada. Repita el ejercicio y el ciclo de escaneo después de agregar reglas legítimas. Cuando el perfil cubra el comportamiento probado, finalice el generador. SUSE indica que completar un nuevo aa-genprofciclo de aprendizaje normalmente activa el modo de aplicación del perfil.
Inspeccione la política generada. Para esta ruta de ejemplo, la convención de nomenclatura de SUSE convierte las barras diagonales en la ruta del ejecutable en puntos, produciendo /etc/apparmor.d/usr.local.bin.report-worker. Revise el resultado en lugar de tratar las reglas generadas como automáticamente seguras:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Verifique que el perfil nombre el ejecutable previsto, utilice las inclusiones necesarias y otorgue acceso únicamente a la configuración, los datos, los registros, los sockets y los programas auxiliares que la aplicación realmente necesita. Evite reglas generales, como el acceso sin restricciones a un /árbol de directorios completo o a todo un árbol de directorios con permisos de escritura, solo para evitar una denegación. La aplicación sigue dependiendo de la propiedad y los permisos habituales de Unix; AppArmor añade una capa de restricción independiente.
Establezca explícitamente el modo deseado. Tras la revisión, aplique el perfil al programa personalizado:
sudo aa-enforce /usr/local/bin/report-worker
Si editaste el perfil manualmente después de que el generador finalizara, vuelve a cargar el conjunto de perfiles con sudo systemctl reload apparmor. Los documentos de SUSE se recargan como perfiles que vuelven a escanear sin liberar los procesos en ejecución. Reinicia el servicio de la aplicación para que la nueva política se aplique a su proceso.
Vuelva a ejecutar las mismas tareas representativas mientras el perfil esté en modo de aplicación. Confirme que el servicio se inicia, lee las entradas previstas, escribe la salida esperada y puede realizar las operaciones auxiliares o de red necesarias. A continuación, inspeccione tanto el estado del perfil como los mensajes recientes del kernel.
sudo aa-status
sudo journalctl -k -g apparmor --since today
El ejecutable personalizado debería aparecer como cargado y en modo de aplicación. Las denegaciones de AppArmor en el registro del kernel identifican las solicitudes que la política bloqueó; úselas para diagnosticar un fallo real de la aplicación, no como motivo para permitir todas las rutas registradas. Para un permiso faltante legítimo, ejecute sudo aa-logprof, revise la sugerencia, actualice la regla de forma específica, recargue si la editó manualmente y vuelva a ejecutar la ruta de la aplicación afectada.
Para un servicio en ejecución continua cuyo análisis de rendimiento debe abarcar reinicios o periodos de observación prolongados, SUSE documenta un flujo de trabajo sistémico independiente que utiliza aa-autodepescaneos aa-complainrepetidos aa-logprof. El método independiente aa-genprofes más sencillo cuando la ejecución de aprendizaje puede permanecer abierta durante toda la prueba. Ninguno de los flujos de trabajo puede inferir el comportamiento de la aplicación que nunca se ha probado, por lo que es importante revisar el perfil cuando se produzcan cambios en el software o la configuración.
Configure la ruta de Live Patching correcta para SLES 16.0 o 15 SP7, aplique las correcciones del kernel que cumplan los requisitos y confirme qué está activo sin confundirlo con una actualización del kernel que requiera reiniciar el sistema.
SLES 15 SP5 puede migrar en línea a SP6, pero cada nodo debe reiniciarse. Utilice una actualización progresiva probada o una transición azul-verde para mantener las cargas de trabajo accesibles.
Cree, refine y verifique un perfil de AppArmor con privilegios mínimos en SLES 15 SP7, con una nota clara sobre la configuración predeterminada de SELinux en SLES 16.
Utilice el perfil STIG compatible con SUSE para analizar SLES 15, probar la remediación, revisar los hallazgos restantes y conservar la evidencia de la evaluación.
Para rastrear una conexión fallida a Cockpit, utilice DNS, el puerto 9090, el socket systemd, firewalld, TLS y la configuración de inicio de sesión, siguiendo las directrices actuales de SUSE.
Cree una conexión Ethernet redundante en SLES 15 con YaST y Wicked, configure la agregación de enlaces activo-pasivo y verifique ambos puertos y la conmutación por error.
Convierta un sistema SLES 15 existente en un perfil AutoYaST revisado, valídelo y utilícelo para implementar un servidor de prueba con menos pasos manuales.
Instale las herramientas SLES 15 KVM y libvirt, habilite el servicio de host correcto y configure las máquinas virtuales seleccionadas para que se inicien después de un reinicio.
Utilice las tareas de systemd y el registro de arranque anterior para localizar un servicio lento, un punto de montaje o una dependencia de almacenamiento, y luego corríjalo sin enmascarar la causa.
Utilice firewall-cmd para inspeccionar la zona activa, permitir HTTP de forma segura, preservar el acceso SSH y verificar que la regla se mantenga tras una recarga en SLES 15.
