AppArmor

módulo de seguridad del kernel Linux

AppArmor ("Application Armor") es un módulo de seguridad del kernel Linux que permite al administrador del sistema restringir las capacidades de un programa. Para definir las restricciones asocia a cada programa un perfil de seguridad. Este perfil puede ser creado manual o automáticamente. Complementa el modelo tradicional de control de acceso discrecional de Unix (DAC) proporcionando el control de acceso obligatorio (MAC). Está implementado utilizando el framework del núcleo Linux Security Modules.

AppArmor
Información general
Tipo de programa Linux Security Module
Autor Immunix
Desarrollador Canonical (desde 2009), Novell (2005-2009) e Immunix (1998-2005)
Licencia GPL
Estado actual En desarrollo
Información técnica
Programado en
Versiones
Última versión estable 3.1.72 de febrero de 2024
Enlaces

Actualmente se encarga de mantenerlo la empresa Canonical Ltd.

Historia editar

Desarrollado por la compañía Immunix en código fuente cerrado, fue adquirido por la compañía Novell en mayo de 2005 y en enero de 2006 fue publicado como de código fuente abierto.[1]​ Desde mayo de 2009, Canonical Ltd. se hace cargo del mantenimiento y desarrollo de AppArmor.

AppArmor fue creado en parte como alternativa a SELinux, que era criticado por los administradores por ser demasiado difícil de instalar y mantener. Al contrario que SELinux, que se basa en añadir etiquetas a los archivos, AppArmor trabaja con las rutas de los ficheros. Según sus autores, AppArmor es menos complejo y más fácil de aprender a utilizar para un usuario medio que SELinux; incluso sus procesos de auditoría son más claros al público en general.[2]

Mecanismo editar

AppArmor necesita realizar pocas modificaciones en el sistema de ficheros, a diferencia de SELinux que necesita un sistema de ficheros que soporte sus atributos extendidos, lo que implica que no pueda controlar el acceso a archivos montados vía NFS. Con AppArmor no importa en qué clase de sistema de ficheros estén montados los archivos ya que trabaja con las rutas de los archivos o URL.

Además de la especificación manual de perfiles, AppArmor incluye un modo de aprendizaje, en el que las violaciones del perfil son registradas pero no prevenidas. Este registro puede utilizarse para crear un perfil basado en el comportamiento típico del programa.[3]

Aunque en las versiones iniciales se incluían reglas acerca de establecer conexiones UDP y TCP, no fueron incluidas al momento de su lanzamiento.[4]​ Sin embargo Novell asegura en su manual que para la versión 2.1 sí goza de tales características.[5]

Otros sistemas editar

AppArmor representa una aproximación al problema de restringir las acciones que el software instalado puede realizar según una lista de control de acceso, concepto definido en la RFC 4949.

Otra aproximación similar a AppArmor es SELinux. Una diferencia importante es que identifica los objetos del sistema de ficheros por el nombre del inodo en lugar de hacerlo por la ruta. Esto significa que, por ejemplo:

  • Hay datos inaccesibles bajo AppArmor y SELinux y luego un usuario crea una nueva versión del mismo (una técnica usada con frecuencia):
    • Bajo SELinux los datos se vuelven accesibles.
    • Bajo AppArmor se continúa negando el acceso.
  • Hay datos inaccesibles bajo AppArmor y SELinux y luego un usuario crea un enlace permanente:
    • En SELinux se continúa negando el acceso.
    • En AppArmor los datos se vuelven accesibles.[6]

(En ambos casos, una política por defecto de "ningún acceso" evitaría el problema.)

Mientras se sigue debatiendo cual de las dos aproximaciones es mejor, hasta la fecha no hay ninguna evidencia definitiva que haga a uno preferible al otro. La discusión sobre las ventajas y desventajas de cada método suele girar en torno a cual de los dos se alinea más con los mecanismos de control de UNIX/Linux, pero UNIX y Linux usan una combinación de control de acceso basado en la ruta y en el inodo de los ficheros. Observar también que cualquier sistema operativo tiene mecanismos de control de acceso.

SELinux y AppArmor también se diferencian significativamente en cómo se administran e integran en el sistema.

El aislamiento de procesos también se puede lograr por los mecanismos como la virtualización; el proyecto de OLPC, por ejemplo, usa cajas de arena (sandboxes) individuales para las aplicaciones en VServer.

Disponibilidad editar

AppArmor empezó a utilizarse en SUSE y openSUSE. En los últimos lanzamientos, está disponible desde la herramienta de administración (YaST), pero no está activado por defecto. En abril de 2007 fue portado/empaquetado para Ubuntu. La distribución francesa Mandriva Linux incluye AppArmor como uno de los componentes de su distribución en la edición Mandriva Linux 2008 [1]. Desde la versión 10, Debian lo activa por defecto [2]

Véase también editar

Referencias editar

  1. Brown, Chris (22 de agosto de 2006). «Protect your applications with AppArmor» (html). Linux.com (en inglés). Archivado desde el original el 25 de marzo de 2018. Consultado el 25 de marzo de 2019. «AppArmor is a product that Novell acquired when they bought the company Immunix in May 2005. (...) AppArmor was originally a closed-source product, but became open source in January 2006.» 
  2. «Why I Like AppArmor More Than SELinux» (html). InsanityBit (en inglés). 1 de junio de 2012. Archivado desde el original el 25 de septiembre de 2014. Consultado el 25 de marzo de 2018. «They’re both incredibly secure but AppArmor is far easier to audit because of the simplicity. I respect that a properly configured SELinux profile is potentially much stronger than a properly configured AppArmor profile but if I can’t audit the policy I can’t verify the policy and that’s important.» 
  3. Brown, Chris (22 de agosto de 2006). «Protect your applications with AppArmor» (html). Linux.com (en inglés). Archivado desde el original el 25 de marzo de 2018. Consultado el 25 de marzo de 2019. «In complain mode (used by the create profile wizard), AppArmor logs a line to /var/log/audit/audit.log through the kernel logging daemon klogd for each resource that the application accesses.» 
  4. Brown, Chris (22 de agosto de 2006). «Protect your applications with AppArmor» (html). Linux.com (en inglés). Archivado desde el original el 25 de marzo de 2018. Consultado el 25 de marzo de 2019. «Earlier versions of AppArmor included rules that restricted the establishment of UDP and TCP connections. These rules have been removed from the current version of the product, but may be restored in a future version.» 
  5. «Breaking a Novell AppArmor Profile into Its Parts» (html). Novell (en inglés). 25 de marzo de 2018. Archivado desde el original el 25 de marzo de 2018. Consultado el 25 de marzo de 2018. «AppArmor allows mediation of network access based on the address type and family. The following illustrates the network access rule syntax:». 
  6. Boelen, Michael (2 de febrero de 2015). «An Introduction Into Linux Security Modules» (html). Linux Audit (en inglés). Archivado desde el original el 19 de abril de 2015. Consultado el 25 de marzo de 2018. «When creating a hardlink of a file, it may become accessible again (as the inode has changed)». 

Enlaces externos editar