En épocas anteriores, el modelo de seguridad estándar para los sistemas operativos de GNU/Linux y de Unix dio a usuarios generales un sistema mínimo de privilegios, mientras que concedía privilegios completos a una cuenta de solo usuario, es decir la raíz, que fue utilizada para administrar el sistema y a los usuarios, instalar los sistemas de ficheros del software, del montaje y del unmount, módulos cargados del núcleo, ata un proceso a un puerto privilegiado y funciona con muchos servicios.
Esta dependencia sobre la cuenta de raíz para realizar todas las acciones que requerían privilegio fue reconocida para ser algo peligrosa en que era toda o nada y no adaptada a la compartimentalización de papeles. Además, aumentó el riesgo de vulnerabilidades dentro de un uso del setuid que puede requerir solamente los privilegios de la raíz para una fracción muy pequeña de su actividad tal como apertura de un fichero del sistema o de un atascamiento en un puerto privilegiado.
Este riesgo era entendido bien dentro de la comunidad de los sistemas abiertos. Consecuentemente, IEEE Std.1003.1e (aka POSIX.1e o POSIX.6) era un efecto principal comenzado en 1995 para desarrollar un sistema estandardizado de los interfaces de la seguridad para los sistemas de conformación que las listas de control de acceso incluidas (ACL), intervención, separación de privilegio (capacidades), control de acceso obligatorio (MAC) y las etiquetas de la información.
El trabajo fue terminado por RevCon de IEEE en 1998 en el bosquejo 17 del documento debido a la carencia del consenso (sobre todo debido a práctica existente en conflicto.) Mientras que el esfuerzo formal de los estándares falló, mucho del estándar de bosquejo ha hecho desde entonces su manera en el núcleo del linux incluyendo las capacidades que este poste explora.
¿Primero, qué significamos por las capacidades de Linux? Es básicamente un verion extendido del modelo de las capacidades descrito en el estándar del bosquejo POSIX.1e. Los lectores familiares con el VMS o las versiones de Unix que incluyen confiado en que la base de computación (TCB) la reconocerán como siendo algo análogos como a privilegios. Estas capacidades reparten el sistema de privlileges de la raíz en un sistema de los privilegios lógicos distintos que se pueden conceder o asignar a los procesos, usuarios, sistemas de ficheros y más. Como aparte, la capacidad del término originó en un papel 1966 de Gato Dennis y de Earl Van Horn (CACM vol. 9, #3, pp 143-155, marzo de 1966.) Las capacidades pueden ser en gran medida el incluir ejecutado vía etiquetas del hardware, criptografía, dentro de un lenguaje de programación (e.g.Java) o de usar el espacio de dirección protegido. Para una introducción a los mecanismos capacidad-basados vaya aquí. El linux utiliza el espacio de dirección protegido y cualidades de archivo ampliadas a las capacidades del instrumento.
Una bandera de la capacidad es una cualidad de una capacidad. Hay tres banderas de la capacidad, nombradas (p) permitido, (e) eficaz y (i) heredado, asociado a cada uno de las capacidades que, a propósito, se documentan en el jefe de <security/capability.h>.
Un sistema de la capacidad consiste en una BITMAP 64-bit (antes de libcap 2.03 una BITMAP eran 32 pedacitos.) Un proceso tiene un estado de la capacidad el consistir en de tres sistemas de la capacidad, es decir (i) que se puede heredar, (p) permitido y (e) eficaz, con cada bandera de la capacidad ejecutados como pedacito en cada uno de las tres BITMAP.
Siempre que un proceso intente una operación privilegiada, el núcleo comprueba que el pedacito apropiado en el sistema eficaz está fijado. Por ejemplo, cuando un proceso intenta fijar el reloj monoatómico, del núcleo los cheques primero que el pedacito de CAP_SYS_TIME está fijado en el sistema eficaz de proceso.
El sistema permitido indica qué capacidades puede utilizar un proceso. Un proceso puede tener capacidades fijadas en el sistema permitido que no estén en el sistema eficaz. Esto indica que el proceso ha inhabilitado temporalmente esta capacidad. Un proceso se permite fijar su sistema eficaz mordido solamente si está disponible en el sistema permitido. La distinción entre permitido y el eficaz existe de modo que pueda un proceso las operaciones de soporte que necesitan privilegio.
Las capacidades que se puede heredar son las capacidades del proceso actual que se debe heredar por un programa ejecutado por el proceso actual. El sistema permitido de un proceso se enmascara contra el sistema que se puede heredar durante exec, mientras que los procesos hijo y los hilos de rosca se dan una copia exacta de las capacidades del proceso padre.
Algo que entrando un explaination detallado de sistemas y de cálculos forzados de la capacidad, le refiero a la explicación excelente de Chris Friedhoff. Sin embargo, he resumido las reglas en el diagrama siguiente.
Por nuestro primer ejemplo de modificar capacidades considere la utilidad del silbido de bala. Mucha gente no realiza que es un setuid ejecutable en la mayoría de los sistemas de GNU/Linux. Necesita estar tan porque necesita privilegio de escribir el tipo de paquetes que utiliza para sondar la red.
$ ls - al /bin/ping - 02:02 2008-09-26 /bin/ping de la raíz 41784 de la raíz del rwsr-xr-x 1 Si usted copia silbido de bala, pierde su pedacito del setuid y no puede trabajar cp /bin/ping de $. $ ls - silbido de bala del al - silbido de bala del 20:26 2009-05-29 del fpm 41784 del fpm del rwxr-xr-x 1 $ de localhost de ./ping silbido de bala: zócalo abierto del ICMP: Operación no permitida pero trabajos si usted hace raíz # ./ping - localhost c1 PING localhost.localdomain (127.0.0.1) 56 (84) octetos de datos. 64 octetos de localhost.localdomain (127.0.0.1): ms de icmp_seq=1 ttl=64 time=0.026 --- estadísticas del silbido de bala de localhost.localdomain --- 1 los paquetes transmitidos, 1 recibieron, pérdida del paquete del 0%, tiempo 0ms minuto/avg/máximo/mdev del RTT = 0.026/0.026/0.026/0.000 ms como la raíz agrega CAP_NET_RAW a la capacidad permitida y fijó el pedacito eficaz de la herencia # cap_net_raw=ep ./ping de /usr/sbin/setcap compruebe lo que silban como una bala las capacidades ahora tienen # /usr/sbin/getcap ./ping ./ping = cap_net_raw+ep y trabajos de este silbido de bala del vez sin ser setuid $ ls - al ./ping - 20:26 2009-05-29 ./ping del fpm 41784 del fpm del rwxr-xr-x 1 $ ./ping - localhost c1 PING localhost.localdomain (127.0.0.1) 56 (84) octetos de datos. 64 octetos de localhost.localdomain (127.0.0.1): ms de icmp_seq=1 ttl=64 time=0.026 --- estadísticas del silbido de bala de localhost.localdomain --- 1 los paquetes transmitidos, 1 recibieron, pérdida del paquete del 0%, tiempo 0ms minuto/avg/máximo/mdev del RTT = 0.026/0.026/0.026/0.000 ms
Otro panorama pudo ser que queremos quitar el pedacito del setuid de silbido de bala sino permitir a un usuario non-root utilizarlo. Podemos hacer esto usando el módulo del pam_cap del PAM que es cuál es parte del paquete del libcap. El archivo de configuración de defecto para este módulo del PAM es /etc/security/capability.conf pero eso se puede sobreescribir usando una discusión del config=filename. Otra discusión que usted puede pasar al módulo es elimina errores. Cualquier error se escribe al archivo de registro de errores para este módulo que sea pam_cap.
El ejemplo siguiente demuestra cómo configurar el pam_cap para permitir que la prueba de usuario utilice silbido de bala
gato /security/capability.conf # # /etc/security/capability.conf # pasado corrija FPM 05/29/2009 # el usuario prueba del ## puede utilizar silbido de bala vía herencia prueba del cap_net_raw el ## cada uno no consigue ninguna capacidad que se puede heredar ningunos * asegure después que pam_cap.so es requerido por el su gato /etc/pam.d/su #%PAM-1.0 auth suficiente pam_rootok.so # Uncomment la línea siguiente para confiar en implícito a usuarios en el grupo de la rueda . #auth suficiente use_uid de la confianza de pam_wheel.so # Uncomment la línea siguiente para requerir a un usuario estar en el grupo de la rueda . #auth requerido use_uid de pam_wheel.so # pam_cap.so agregado FPM 5/29/2009 auth requerido pam_cap.so eliminan errores auth incluya sistema-auth cuenta suficiente uid de pam_succeed_if.so = 0 tranquilidades del use_uid cuenta incluya sistema-auth contraseña incluya sistema-auth sesión incluya sistema-auth sesión opcional pam_xauth.so ahora fije las capacidades para el silbido de bala que vamos a utilizar ninguÌn pedacito eficaz de la herencia (e), ninguÌn privilegio permitido # /usr/sbin/setcap - r ./ping # cap_net_raw=p ./ping de /usr/sbin/setcap # /usr/sbin/getcap ./ping ./ping = cap_net_raw+p ¿puedo silbar como una bala como fpm? No. identificación de $ - la O.N.U fpm la más ~test cd de $ $ ./ping - q - localhost c1 silbido de bala: zócalo abierto del ICMP: Operación no permitida ¿puedo silbar como una bala como prueba? sí. $ su - prueba Contraseña: identificación de $ - la O.N.U prueba $ ./ping - q - localhost c1 PING localhost.localdomain (127.0.0.1) 56 (84) octetos de datos. --- estadísticas del silbido de bala de localhost.localdomain --- 1 los paquetes transmitidos, 1 recibieron, pérdida del paquete del 0%, tiempo 0ms minuto/avg/máximo/mdev del RTT = 0.024/0.024/0.024/0.000 ms
La utilidad indocumentada de /usr/sbin/capsh se puede utilizar para manejar capacidades y para reducir el potencial para las vulnerabilidades en shell scriptes. Es una envoltura simple alrededor de la cáscara del golpe que se puede utilizar para levantar y para bajar el bset y capacidades del pi antes de /bin/bash de invocación.
usando el ejemplo anterior del silbido de bala que fue dado CAP_NET_RAW identificación de $ - NU raíz $ /usr/sbin/getcap ./ping ./ping = cap_net_raw+ep ahora utilice el capsh para caer CAP_NET_RAW y para cambiar al uid 500 (el fpm) la operación se permite no más $ /usr/sbin/capsh --drop=cap_net_raw --uid=500 -- identificación de $ - NU fpm $ ./ping - q - localhost c1 golpe: ./ping: Operación no permitida permanentemente gota CAP_NET_RAW $ /usr/sbin/setcap - r ./ping e invoque el silbido de bala usando capsh --casquillos $ de capsh --caps= " cap_net_raw-ep " -- - c . /ping - c1 - localhost de q PING localhost.localdomain (127.0.0.1) 56 (84) octetos de datos. --- estadísticas del silbido de bala de localhost.localdomain --- 1 los paquetes transmitidos, 1 recibieron, pérdida del paquete del 0%, tiempo 0ms minuto/avg/máximo/mdev del RTT = 0.056/0.056/0.056/0.000 ms utilice el capsh para imprimir capacidades identificación de $ - la O.N.U fpm $ /usr/sbin/capsh --impresión Corriente: = =cap_chown determinado de limitación, cap_dac_override, cap_dac_read_search, cap_fowner, cap_fsetid, cap_kill, cap_setgid, cap_setuid, cap_setpcap, cap_linux_immutable, cap_net_bind_service, cap_net_broadcast, cap_net_admin, cap_net_raw, cap_ipc_lock, cap_ipc_owner, cap_sys_module, cap_sys_rawio, cap_sys_chroot, cap_sys_ptrace, cap_sys_pacct, cap_sys_admin, cap_sys_boot, cap_sys_nice, cap_sys_resource, cap_sys_time, cap_sys_tty_config, cap_mknod, cap_lease, cap_audit_write, cap_audit_control, cap_setfcap, cap_mac_override, cap_mac_admin Securebits: 00/0x0 seguro-noroot: ninguÌn (abierto) seguro-ninguÌn-suid-fixup: ninguÌn (abierto) seguro-guardar-casquillos: ninguÌn (abierto) uid=500
Hay muchas otras opciones al capsh y usted debe pasar probablemente una cierta hora que experimenta con ellos. Invoque el capsh con - la opción de ayuda para ver la lista completa. Observe que los shell scriptes del setuid tienen capacidades.
Todos los ejemplos demostrados arriba trabajan en Fedora 10 cuál el libcap 2.10 de las aplicaciones. Si usted desea experimentar en otras distribuciones de GNU/Linux, debe tener un >= 2.6.24 del núcleo construido con CONFIG_FILE_CAPABILITIES=y, una versión del libcap >=2.08 y un sistema de ficheros que apoye las cualidades extendidas e.g. ext3 o ext4. Observe que CONFIG_CAPABILITIES=y debe ser requerido no más.
¿Por qué no es más gente enterada de y con capacidades? Creo que la documentación pobre es la razón primaria. Por ejemplo, Fedora 10 está faltando las páginas de hombre para los getpcaps, el capsh y el pam_cap, y la guía de la seguridad de Fedora incluso no menciona capacidades (o para esa materia ACLs!) No puedo solamente ayuda que piensa que las capacidades son tratadas como el primo pobre a SELinux por el proyecto de Fedora.
Mana este poste del blog está consiguiendo un pedacito largo así que voy a parar. He rasguñado apenas la superficie de capacidades. Después de que Fedora 11 envíe, cubriré capacidades de una perspectiva programada. Mientras tanto, si usted quiere guardar la corriente con qué está sucediendo con capacidades del linux, Andrew Morgan completamente capaz es el que está a marcar una dirección de la Internet.
