Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Administración de Oracle Solaris: servicios de seguridad Oracle Solaris 11 Information Library (Español) |
Parte I Descripción general de la seguridad
1. Servicios de seguridad (descripción general)
Parte II Seguridad de sistemas, archivos y dispositivos
2. Gestión de seguridad de equipos (descripción general)
3. Control de acceso a sistemas (tareas)
4. Servicio de análisis de virus (tareas)
5. Control de acceso a dispositivos (tareas)
6. Uso de la herramienta básica de creación de informes de auditoría (tareas)
7. Control de acceso a archivos (tareas)
Parte III Roles, perfiles de derechos y privilegios
8. Uso de roles y privilegios (descripción general)
9. Uso del control de acceso basado en roles (tareas)
10. Atributos de seguridad en Oracle Solaris (referencia)
Visualización del contenido de los perfiles de derechos
Orden de búsqueda para atributos de seguridad asignados
Convenciones de denominación de autorizaciones
Ejemplo de granularidad de autorizaciones
Autoridad de delegación en autorizaciones
Bases de datos de RBAC y servicios de nombres
Comandos seleccionados que requieren autorizaciones
Comandos administrativos para la gestión de privilegios
Archivos con información de privilegios
Parte IV Servicios criptográficos
11. Estructura criptográfica (descripción general)
12. Estructura criptográfica (tareas)
13. Estructura de gestión de claves
Parte V Servicios de autenticación y comunicación segura
14. Autenticación de servicios de red (tareas)
17. Uso de Secure Shell (tareas)
19. Introducción al servicio Kerberos
20. Planificación del servicio Kerberos
21. Configuración del servicio Kerberos (tareas)
22. Mensajes de error y resolución de problemas de Kerberos
23. Administración de las políticas y los principales de Kerberos (tareas)
24. Uso de aplicaciones Kerberos (tareas)
25. El servicio Kerberos (referencia)
Parte VII Auditoría en Oracle Solaris
26. Auditoría (descripción general)
27. Planificación de la auditoría
Los procesos que restringen privilegios se implementan en el núcleo y pueden restringir los procesos a nivel de comando, de usuario, de rol o de sistema.
La siguiente tabla muestra los comandos que están disponibles para gestionar privilegios.
Tabla 10-3 Comandos para la gestión de privilegios
|
Los siguientes archivos contienen información sobre privilegios.
Tabla 10-4 Archivos que contienen información de privilegios
|
El uso de privilegios se puede auditar. Cada vez que un proceso utiliza un privilegio, el uso del privilegio se registra en la pista de auditoría, en el token de auditoría upriv. Cuando los nombres de privilegios forman parte del registro, se utiliza su representación textual. Los siguientes eventos de auditoría registran el uso del privilegio:
Evento de auditoría AUE_SETPPRIV: el evento genera un registro de auditoría cuando se modifica un conjunto de privilegios. El evento de auditoría AUE_SETPPRIV está en la clase pm.
Evento de auditoría AUE_MODALLOCPRIV: el evento de auditoría genera un registro de auditoría cuando se agrega un privilegio desde afuera del núcleo. El evento de auditoría AUE_MODALLOCPRIV está en la clase ad.
Evento de auditoría AUE_MODDEVPLCY: el evento de auditoría genera un registro de auditoría cuando se modifica la política de dispositivos. El evento de auditoría AUE_MODDEVPLCY está en la clase ad.
Evento de auditoría AUE_PFEXEC: el evento de auditoría genera un registro de auditoría cuando se realiza una llamada a execve() con pfexec() habilitada. El evento de auditoría AUE_PFEXEC está en las clases de auditoría as, ex, ps y ua. Los nombres de los privilegios se incluyen en el registro de auditoría.
El uso correcto de privilegios que se encuentran en el conjunto básico no se audita. El intento de utilizar un privilegio básico que se eliminó del conjunto básico de un usuario se audita.
El núcleo impide la escalada de privilegios. La escalada de privilegios se produce cuando un privilegio permite a un proceso realizar más tareas de las que debe hacer. Para evitar que un proceso obtenga más privilegios de los que debe tener, las modificaciones vulnerables del sistema requieren el conjunto completo de privilegios. Por ejemplo, un archivo o un proceso que es propiedad de root (UID=0) sólo puede ser modificado por un proceso con el conjunto completo de privilegios. La cuenta root no requiere privilegios para modificar un archivo que es propiedad de root. Sin embargo, un usuario que no es root debe tener todos los privilegios para modificar un archivo que es propiedad de root.
De modo similar, las operaciones que proporcionan acceso a dispositivos requieren todos los privilegios del conjunto vigente.
Los privilegios file_chown_self y proc_owner están sujetos a la escalada de privilegios. El privilegio file_chown_self permite a un proceso delegar sus archivos. El privilegio proc_owner permite a un proceso inspeccionar los procesos que no son de su propiedad.
El privilegio file_chown_self está limitado por la variable del sistema rstchown. Cuando la variable rstchown se define en cero, el privilegio file_chown_self se elimina del conjunto heredable inicial del sistema y de todos los usuarios. Para obtener más información sobre la variable del sistema rstchown, consulte la página del comando man chown(1).
El privilegio file_chown_self se asigna de forma más segura a un comando concreto, se coloca en un perfil y se asigna a un rol para su uso en un shell de perfil.
El privilegio proc_owner no es suficiente para cambiar un UID de proceso a 0. Para cambiar un proceso de cualquier UID a UID=0, se requieren todos los privilegios. Como el privilegio proc_owner otorga acceso de lectura sin restricciones a todos los archivos del sistema, el privilegio se asigna de forma más segura a un comando concreto, se coloca en un perfil y se asigna a un rol para su uso en un shell de perfil.
Precaución - La cuenta de un usuario se puede modificar para incluir el privilegio file_chown_self o el privilegio proc_owner en el conjunto heredable inicial del usuario. Debe tener un motivo de seguridad importante para colocar esos privilegios tan poderosos en el conjunto heredable de privilegios para cualquier usuario, rol o sistema. |
Para obtener detalles sobre cómo se evita la escalada de privilegios para los dispositivos, consulte Privilegios y dispositivos.
Para adaptarse a las aplicaciones antiguas, la implementación de privilegios funciona con el modelo de superusuario y el modelo de privilegios. El núcleo realiza automáticamente un seguimiento del indicador PRIV_AWARE, que señala que un programa se ha diseñado para trabajar con privilegios. Piense en un proceso secundario que no reconoce privilegios. Los privilegios que se heredaron del proceso principal están disponibles en el conjunto permitido y el conjunto vigente del proceso secundario. Si el proceso secundario define un UID en 0, es posible que el proceso secundario no tenga capacidades completas de superusuario. El conjunto vigente y el conjunto permitido del proceso están restringidos a los privilegios del conjunto límite del proceso secundario. Por lo tanto, el conjunto límite de un proceso que reconoce privilegios restringe los privilegios raíz de los procesos secundarios que no reconocen privilegios.