Control de acceso basado en roles (descripción general)

El control de acceso basado en roles (RBAC) es una función de seguridad para controlar el acceso de usuarios a tareas que normalmente están restringidas al rol root. Mediante la aplicación de atributos de seguridad a procesos y usuarios, RBAC puede dividir las capacidades de superusuario entre varios administradores. La gestión de derechos de procesos se implementa a través de privilegios. La gestión de derechos de usuarios se implementa a través de RBAC.

• Para ver una explicación de la gestión de derechos de procesos, consulte Privilegios (descripción general).

• Para obtener información sobre las tareas de RBAC, consulte el Capítulo 9, Uso del control de acceso basado en roles (tareas).

• Para obtener información de referencia, consulte el Capítulo 10, Atributos de seguridad en Oracle Solaris (referencia).

RBAC: una alternativa al modelo de superusuario

En los sistemas UNIX convencionales, el usuario root, también conocido como superusuario, es omnipotente. Los programas que se ejecutan como root, o los programas setuid, son omnipotentes. El usuario root puede leer y escribir en cualquier archivo, ejecutar todos los programas y enviar señales de terminación a cualquier proceso. De hecho, cualquier persona que puede convertirse en superusuario puede modificar el cortafuegos de un sitio, modificar la pista de auditoría, leer registros confidenciales y apagar toda la red. Un programa setuid usurpado puede realizar cualquier tarea en el sistema.

El control de acceso basado en roles (RBAC) ofrece una alternativa más segura al modelo de superusuario del tipo "todo o nada". Con RBAC, puede aplicar una política de seguridad en un nivel más específico. RBAC utiliza el principio de seguridad del privilegio mínimo. Privilegio mínimo significa que un usuario dispone exactamente de la cantidad de privilegios necesaria para realizar un trabajo. Los usuarios comunes tienen privilegios suficientes para utilizar sus aplicaciones, comprobar el estado de sus trabajos, imprimir archivos, crear archivos nuevos, etc. Las capacidades que van más allá de las capacidades de los usuarios comunes se agrupan en perfiles de derechos. Los usuarios que realizarán trabajos que requieren algunas de las capacidades de superusuario asumen un rol que incluye el perfil de derechos adecuado.

RBAC recopila las capacidades de superusuario en perfiles de derechos. Estos perfiles de derechos se asignan a cuentas de usuario especiales denominadas roles. Luego, un usuario puede asumir un rol para realizar un trabajo que requiere algunas de las capacidades de superusuario. Se incluyen perfiles de derechos predefinidos con el software Oracle Solaris. Usted crea los roles y asigna los perfiles.

Los perfiles de derechos pueden proporcionar capacidades amplias. Por ejemplo, el perfil de derechos de administrador del sistema permite a una cuenta realizar tareas que no están relacionadas con la seguridad, como la gestión de impresoras y trabajos cron. Los perfiles de derechos también se pueden definir de manera limitada. Por ejemplo, el perfil de derechos de gestión de cron se encarga de los trabajos at y cron. Al crear roles, se pueden asignar a los roles capacidades amplias, capacidades restringidas o ambas.

La siguiente figura ilustra cómo RBAC puede distribuir derechos a partes de confianza.

Figura 8-1 Distribución de derechos de RBAC

En el modelo RBAC, el superusuario crea uno o más roles. Los roles se basan en perfiles de derechos. El superusuario luego asigna los roles a los usuarios en los que confía para realizar las tareas del rol. Los usuarios inician sesión con su nombre de usuario. Después del inicio de sesión, los usuarios asumen roles que pueden ejecutar comandos administrativos restringidos y herramientas de la interfaz gráfica de usuario (GUI).

La flexibilidad en la configuración de los roles posibilita una variedad de políticas de seguridad. Aunque se incluyen pocos roles con Oracle Solaris, es posible configurar fácilmente diferentes roles. Puede basar la mayoría de los roles en perfiles de derechos del mismo nombre:

• Root: un rol potente equivalente al usuario root. Sin embargo, este usuario root no puede iniciar sesión. Un usuario común debe iniciar sesión y, a continuación, asumir el rol root asignado. Este rol está configurado de manera predeterminada.

• Administrador del sistema: un rol menos poderoso para la administración que no está relacionado con la seguridad. Este rol puede gestionar sistemas de archivos, correo e instalación de software. Sin embargo, este rol no puede definir contraseñas.

• Operador: rol de administrador junior para operaciones, como copias de seguridad y gestión de impresoras.

  ---

  Nota - El perfil de derechos de copia de seguridad de medios proporciona acceso a todo el sistema de archivos raíz. Por lo tanto, si bien los perfiles de derechos de copia de seguridad de medios y operador están diseñados para un administrador junior, debe asegurarse de que el usuario es de confianza.

  ---

Es posible que también desee configurar uno o más roles de seguridad. Tres perfiles de derechos y sus perfiles suplementarios gestionan la seguridad: seguridad de información, seguridad de usuarios y seguridad de zonas. La seguridad de red es un perfil suplementario en el perfil de derechos de seguridad de información.

No es necesario implementar estos roles. Los roles representan una función de las necesidades de seguridad de una organización. Una posible estrategia consiste en configurar roles para administradores con fines especiales en áreas como seguridad, redes o administración de cortafuegos. Otra estrategia es crear un rol de administrador poderoso único junto con un rol de usuario avanzado. El rol de usuario avanzado sería para los usuarios que tienen permiso para corregir partes de sus propios sistemas.

El modelo de superusuario y el modelo RBAC pueden coexistir. La siguiente tabla resume las gradaciones de superusuario a usuario común restringido que son posibles en el modelo RBAC. La tabla incluye las acciones administrativas que se pueden supervisar en ambos modelos. Para obtener un resumen del efecto de los privilegios solamente en un sistema, consulte la Tabla 8-2.

Tabla 8-1 Modelo de superusuario en contraste con el modelo RBAC con privilegios

Elementos y conceptos básicos de RBAC

El modelo RBAC en Oracle Solaris introduce los siguientes elementos:

• Autorización: un permiso para que un usuario o un rol realice una clase de acciones que requieren derechos adicionales. Por ejemplo, la política de seguridad en la instalación otorga a los usuarios comunes la autorización solaris.device.cdrw. Esta autorización permite a los usuarios leer y escribir en un dispositivo de CD-ROM. Para obtener una lista de autorizaciones, consulte el archivo /etc/security/auth_attr.

• Privilegio: un derecho perfectamente definido que se puede otorgar a un comando, un usuario, un rol o un sistema. Los privilegios permiten que un proceso se realice correctamente. Por ejemplo, el privilegio proc_exec permite a un proceso llamar execve(). Los usuarios comunes tienen privilegios básicos. Para ver sus privilegios básicos, ejecute el comando ppriv -vl basic. Para obtener más opciones de comandos, consulte Comandos administrativos para la gestión de privilegios.

• Atributos de seguridad: un atributo que permite a un proceso efectuar una operación. En un entorno UNIX típico, un atributo de seguridad permite a un proceso efectuar una operación que, de lo contrario, está prohibida para los usuarios comunes. Por ejemplo, los programas setuid y setgid tienen atributos de seguridad. En el modelo RBAC, las autorizaciones y privilegios son atributos de seguridad además de los programas setuid y setgid. Estos atributos se pueden asignar a un usuario. Por ejemplo, un usuario con la autorización solaris.device.allocate puede asignar un dispositivo para uso exclusivo. Los privilegios se pueden colocar en un proceso. Por ejemplo, un proceso con el privilegio file_flag_set puede establecer atributos de archivos: inmutables, sin desvinculación o sólo anexo.

• Aplicación con privilegios: una aplicación o un comando que puede anular los controles del sistema mediante la comprobación de atributos de seguridad. En un entorno UNIX típico y en el modelo RBAC, los programas que usan setuid y setgid son aplicaciones con privilegios. En el modelo RBAC, los programas que necesitan privilegios o autorizaciones para ejecutarse correctamente también son aplicaciones con privilegios. Para obtener más información, consulte Aplicaciones con privilegios y RBAC.

• Perfil de derechos: una recopilación de atributos de seguridad que se pueden asignar a un rol o a un usuario. Un perfil de derechos puede incluir autorizaciones, privilegios asignados directamente, comandos con atributos de seguridad y otros perfiles de derechos. Los perfiles que están dentro de otros perfiles se denominan perfiles de derechos suplementarios. Los perfiles de derechos ofrecen una forma práctica de agrupar los atributos de seguridad.

• Rol: una identidad especial para ejecutar aplicaciones con privilegios. Sólo los usuarios asignados pueden asumir la identidad especial. En un sistema ejecutado por roles, incluido el rol root, el superusuario es innecesario. Las capacidades de superusuario se distribuyen en roles diferentes. Por ejemplo, en un sistema de dos roles, las tareas de seguridad serían gestionadas por un rol de seguridad. El segundo rol se ocuparía de las tareas de administración del sistema que no están relacionadas con la seguridad. Los roles pueden ser más específicos. Por ejemplo, un sistema podría incluir roles administrativos independientes para gestionar la estructura criptográfica, las impresoras, la hora del sistema, los sistemas de archivos y la auditoría.

La siguiente figura muestra cómo trabajan juntos los elementos de RBAC.

Figura 8-2 Relaciones entre elementos de RBAC

La siguiente figura utiliza el rol de seguridad de la red y el perfil de derechos de seguridad de la red para demostrar las relaciones de RBAC.

Figura 8-3 Ejemplo de relaciones entre elementos de RBAC

El rol de seguridad de red se utiliza para gestionar IPsec, Wi-Fi y enlaces de red. El rol se asigna al usuario jdoe. jdoe puede asumir el rol si cambia a dicho rol y, a continuación, suministra la contraseña del rol. El administrador puede personalizar el rol para aceptar la contraseña de usuario en lugar de la contraseña del rol.

En la Figura 8-3, el perfil de derechos de seguridad de la red se asigna al rol de seguridad de red. El perfil de derechos de seguridad de la red contiene perfiles complementarios que se evalúan en orden: seguridad de wifi de red, seguridad de enlaces de red y gestión de IPsec de red. Estos perfiles complementarios desempeñan las principales tareas del rol.

El perfil de derechos de seguridad de la red tiene tres autorizaciones asignadas directamente, ningún privilegio asignado directamente y dos comandos con atributos de seguridad. Los perfiles de derechos complementarios tienen autorizaciones asignadas directamente y dos de ellas tienen comandos con atributos de seguridad. En el rol de seguridad de la red, jdoe tiene todas las autorizaciones asignadas en estos perfiles y puede ejecutar todos los comandos con atributos de seguridad en estos perfiles. jdoe puede administrar la seguridad de la red.

Escalada de privilegios

Oracle Solaris proporciona a los administradores mucha flexibilidad al configurar la seguridad. Tal como está instalado, el software no permite la escalada de privilegios. La escalada de privilegios se produce cuando un usuario o un proceso obtienen más derechos administrativos de los que inicialmente se les iban a otorgar. En este sentido, un privilegio comprende cualquier atributo de seguridad, no sólo privilegios.

El software Oracle Solaris incluye atributos de seguridad que están asignados al rol root únicamente. Con otras protecciones de seguridad implementadas, es posible que un administrador asigne atributos que están diseñados para el rol root a otras cuentas, pero dicha asignación se debe realizar con cuidado.

El siguiente perfil de derechos y conjunto de autorizaciones pueden ampliar los privilegios de una cuenta no raíz.

• Perfil de derechos de restauración de medios: este perfil existe pero no es parte de ningún otro perfil de derechos. Debido a que la restauración de medios proporciona acceso a todo el sistema de archivos raíz, su uso constituye una posible escalada de privilegios. Se podrían restaurar medios alternativos o archivos modificados deliberadamente. De manera predeterminada, el rol root incluye este perfil de derechos.

• Autorizaciones solaris.*.assign: estas autorizaciones existen pero no están asignadas a ninguna cuenta o perfil de derechos. Una cuenta con una autorización solaris.*.assign puede asignar atributos de seguridad a otros que la cuenta en sí misma no tiene asignados. Por ejemplo, un rol con la autorización solaris.profile.assign puede asignar perfiles de derechos a otras cuentas que el rol en sí mismo no tiene asignados. De manera predeterminada, sólo el rol root tiene autorizaciones solaris.*.assign.

  Es recomendable asignar autorizaciones solaris.*.delegate, no autorizaciones solaris.*.assign. Una autorización solaris.*.delegate permite al delegador asignar a otras cuentas sólo los atributos de seguridad que el delegador posee. Por ejemplo, un rol al que se le asigna la autorización solaris.profile.delegate puede asignar perfiles de derechos que el rol en sí mismo tiene asignado para otros usuarios y roles.

Para conocer las escaladas que afectan el atributo de seguridad del privilegio, consulte Cómo evitar la escalada de privilegios.

Autorizaciones RBAC

Una autorización es un derecho perfectamente definido que se puede otorgar a un rol o a un usuario. Las autorizaciones aplican políticas en el nivel de aplicación del usuario.

Aunque las autorizaciones pueden asignarse directamente a un rol o a un usuario, se recomienda incluirlas en un perfil de derechos. El perfil de derechos luego se agrega a un rol, y el rol se asigna a un usuario. Para ver un ejemplo, consulte la Figura 8-3.

Las autorizaciones que incluyen las palabras delegate o assign permiten al usuario o rol asignar atributos de seguridad a otros.

Para evitar la escalada de privilegios, no asigne a una cuenta una autorización assign.

• Una autorización delegate permite al delegador asignar a otros sólo los atributos de seguridad que el delegador posee. Por ejemplo, un rol al que se le asigna la autorización solaris.profile.delegate puede asignar a otros perfiles de derechos que el rol en sí mismo tiene asignado.

• Una autorización assign permite al asignador otorgar a otros atributos de seguridad que la cuenta no posee. Por ejemplo, un rol con la autorización solaris.profile.assign pueden asignar a otros cualquier perfil de derechos.

Las autorizaciones solaris.*.assign se entregan, pero no se incluyen en ningún perfil. De manera predeterminada, sólo el rol root tiene autorizaciones solaris.*.assign.

Las aplicaciones compatibles con RBAC pueden comprobar las autorizaciones de un usuario antes de otorgar acceso a la aplicación o a operaciones específicas dentro de la aplicación. Esta comprobación reemplaza la verificación en las aplicaciones UNIX convencionales para UID=0. Para obtener más información sobre las autorizaciones, consulte las siguientes secciones:

• Autorizaciones

• Base de datos auth_attr

• Comandos seleccionados que requieren autorizaciones

Autorizaciones y privilegios

Los privilegios aplican la política de seguridad en el núcleo. La diferencia entre las autorizaciones y los privilegios reside en el nivel en el que se aplica la política de seguridad. Sin el privilegio adecuado, el núcleo puede evitar que un proceso realice operaciones con privilegios. Sin las autorizaciones adecuadas, es posible que se le impida a un usuario utilizar una aplicación con privilegios o realizar operaciones que conllevan riesgos de seguridad dentro de una aplicación con privilegios. Para ver una explicación más detallada de los privilegios, consulte Privilegios (descripción general).

Aplicaciones con privilegios y RBAC

Las aplicaciones y los comandos que pueden anular los controles del sistema se consideran aplicaciones con privilegios. Los atributos de seguridad, como UID=0, los privilegios y las autorizaciones hacen que una aplicación sea una aplicación con privilegios.

Aplicaciones que comprueban UID y GID

Las aplicaciones con privilegios que comprueban la existencia de root (UID=0) o algún otro UID o GID especial han estado presentes en el entorno UNIX desde hace tiempo. El mecanismo de perfiles de derechos permite aislar comandos que requieren un ID específico. En lugar de cambiar el ID de un comando al que cualquiera puede acceder, puede colocar el comando con atributos de seguridad asignados a un perfil de derechos. Un usuario o un rol con ese perfil de derechos luego pueden ejecutar el programa sin tener que convertirse en superusuario.

Los ID se pueden especificar como reales o efectivos. Se prefiere la asignación de ID efectivos en lugar de la asignación de ID reales. Los ID efectivos son equivalentes a la función setuid en los bits de permisos de archivo. Los ID efectivos también identifican el UID para auditoría. Sin embargo, dado que algunos programas y secuencias de comandos de shell requieren un UID real de root, también es posible definir UID reales. Por ejemplo, el comando reboot requiere un UID real en lugar de uno efectivo. Si un ID efectivo no es suficiente para ejecutar un comando, debe asignar el ID real al comando.

Aplicaciones que comprueban privilegios

Las aplicaciones con privilegios pueden comprobar el uso de privilegios. El mecanismo de perfiles de derechos de RBAC permite especificar los privilegios para comandos específicos que requieren atributos de seguridad. A continuación, puede aislar el comando con los atributos de seguridad asignados a un perfil de derechos. Un usuario o un rol con ese perfil de derechos luego pueden ejecutar el comando sólo con los privilegios que el comando necesita para una ejecución correcta.

Entre los comandos que comprueban la existencia de privilegios, se incluyen los siguientes:

• Comandos de Kerberos, como kadmin, kprop y kdb5_util.

• Comandos de redes, como ipadm, routeadm y snoop.

• Comandos de archivos y sistemas de archivos, como chmod, chgrp y mount.

• Comandos que controlan procesos, como kill, pcred y rcapadm.

Para agregar comandos con privilegios a un perfil de derechos, consulte Cómo crear un perfil de derechos y la página del comando man profiles(1). Para determinar los comandos que comprueban privilegios en un perfil específico, consulte Cómo visualizar todos los atributos de seguridad definidos.

Aplicaciones que comprueban autorizaciones

Oracle Solaris proporciona además comandos que comprueban autorizaciones. Por definición, el usuario root tiene todas las autorizaciones. Por lo tanto, el usuario root puede ejecutar cualquier aplicación. Entre las aplicaciones que comprueban la existencia de autorizaciones, se incluyen las siguientes:

• Comandos de administración de auditoría, como auditconfig y auditreduce.

• Comandos de administración de impresoras, como lpadmin y lpfilter.

• Comandos relacionados con trabajos por lotes, como at, atq, batch y crontab.

• Comandos orientados a dispositivos, como allocate, deallocate, list_devices y cdrw.

Para probar las autorizaciones de una secuencia de comandos o un programa, consulte el Ejemplo 9-23. Para escribir un programa que requiere autorizaciones, consulte About Authorizations de Developer’s Guide to Oracle Solaris 11 Security.

Perfiles de derechos de RBAC

Un perfil de derechos es una recopilación de atributos de seguridad que se pueden asignar a un rol o a un usuario para realizar tareas que requieren derechos administrativos. Un perfil de derechos puede incluir autorizaciones, privilegios, comandos con atributos de seguridad asignados y otros perfiles de derechos. Los privilegios que se asignan en un perfil de derechos están vigentes para todos los comandos. Los perfiles de derechos también contienen entradas para reducir o extender el conjunto heredable inicial, y para reducir el conjunto de privilegios límite.

Para obtener más información sobre los perfiles de derechos, consulte las siguientes secciones:

• Perfiles de derechos

• Base de datos prof_attr

• Base de datos exec_attr

Roles de RBAC

Un rol es un tipo especial de cuenta de usuario desde la que puede ejecutar aplicaciones con privilegios. Los roles se crean del mismo modo general que las cuentas de usuario. Los roles tiene un directorio principal, una asignación de grupo, una contraseña, etc. Los perfiles de derechos y las autorizaciones otorgan al rol capacidades administrativas. Los roles no pueden heredar capacidades de otros roles u otros usuarios. Los roles discretos dividen las capacidades de superusuario y, por lo tanto, permiten prácticas administrativas más seguras.

Cuando un usuario asume un rol, los atributos del rol reemplazan todos los atributos de usuario. La información del rol se almacena en las bases de datos passwd, shadow y user_attr. Las acciones de los roles se pueden auditar. Para obtener información detallada acerca de cómo configurar roles, consulte las siguientes secciones:

• Cómo planificar la implementación de RBAC

• Cómo crear un rol

• Cómo cambiar los atributos de seguridad de un rol

Un rol se puede asignar a más de un usuario. Todos los usuarios que pueden asumir el mismo rol tienen el mismo directorio principal, trabajan en el mismo entorno y tienen acceso a los mismos archivos. Los usuarios pueden asumir roles de la línea de comandos. Para ello, deben ejecutar el comando su y proporcionar el nombre del rol y una contraseña. De manera predeterminada, los usuarios autentican un rol proporcionando la contraseña del rol. El administrador puede configurar el sistema para activar a un usuario para que realice la autenticación proporcionando la contraseña del usuario. Para conocer el procedimiento, consulte Cómo permitir que un usuario use su propia contraseña para asumir un rol.

Un rol no puede iniciar sesión directamente. Un usuario inicia sesión y, a continuación, asume un rol. Tras asumir un rol, el usuario no puede asumir otro rol sin salir primero de su rol actual. Tras salir del rol, el usuario puede asumir otro rol.

El hecho de que root es un rol en Oracle Solaris evita inicios de sesión root anónimos. Si se audita el comando de shell de perfil, pfexec, la pista de auditoría contiene el UID real del usuario que inició sesión, los roles que el usuario asumió y las acciones que el rol realizó. Para auditar operaciones de roles en el sistema o un usuario concreto, consulte Cómo auditar roles.

Los perfiles de derechos que se envían con el software están diseñados para asignarlos a roles. Por ejemplo, el perfil de derechos de administrador del sistema se puede utilizar para crear el rol de administrador del sistema. Para configurar un rol, consulte Cómo crear un rol.

Shells de perfil y RBAC

Los usuarios y roles pueden ejecutar aplicaciones con privilegios de un shell de perfil. Un shell de perfil es un shell especial que reconoce los atributos de seguridad que se incluyen en un perfil de derechos. Los administradores pueden asignar un shell de perfil a un usuario específico como un shell de inicio, o el shell de perfil se inicia cuando ese usuario ejecuta el comando su para asumir un rol. En Oracle Solaris cada shell tiene un equivalente de shell de perfil. Por ejemplo, los equivalentes de shell de perfil para el shell Bourne (sh), el shell Bash (bash) y el shell Kornl (ksh) son los shells pfsh, pfbash y pfksh respectivamente. Para obtener una lista de shells de perfil, consulte la página del comando man pfexec(1).

Los usuarios a los que se les ha asignado directamente un perfil de derechos y cuyo shell de inicio de sesión no es un shell de perfil deben invocar un shell de perfil para ejecutar los comandos con atributos de seguridad. Para conocer las consideraciones de seguridad y facilidad de uso, consulte Consideraciones de seguridad al asignar directamente atributos de seguridad.

Todos los comandos que se ejecutan en un shell de perfil pueden auditarse. Para obtener más información, consulte Cómo auditar roles.

Ámbito de servicio de nombres y RBAC

El ámbito de servicio de nombres es un concepto importante para comprender RBAC. El ámbito de un rol puede estar limitado a un host individual. El ámbito también puede incluir todos los hosts gestionados por un servicio de nombres, como LDAP. El ámbito de servicio de nombres para un sistema se especifica en el servicio de cambio de nombres, svc:/system/name-service/switch. Las consultas se detienen en la primera coincidencia. Por ejemplo, si un perfil de derechos existe en dos ámbitos de servicio de nombres, sólo se utilizan las entradas del primer ámbito de servicio de nombres. Si files es la primera coincidencia, el ámbito del rol se limita al host local.

Consideraciones de seguridad al asignar directamente atributos de seguridad

Por lo general, un usuario obtiene capacidades administrativas a través de un rol. Las autorizaciones, privilegios y los comandos con privilegios se agrupan en un perfil de derechos. El perfil de derechos se incluye en un rol, y el rol se asigna a un usuario.

La asignación directa de perfiles de derechos y atributos de seguridad también es posible:

• Se pueden asignar directamente perfiles de derechos, privilegios y autorizaciones a usuarios.

• Se pueden asignar directamente privilegios y autorizaciones a usuarios y roles.

Sin embargo, la asignación directa de privilegios no es una práctica segura. Los usuarios y los roles con un privilegio asignado directamente pueden anular la política de seguridad cada vez que el núcleo necesite este privilegio. Una práctica más segura es asignar el privilegio como atributo de seguridad de un comando en un perfil de derechos. Luego, ese privilegio sólo estará disponible para ese comando y un usuario que tenga ese perfil de derechos.

Dado que las autorizaciones funcionan en el nivel de usuario, la asignación directa de autorizaciones puede resultar menos riesgosa que la asignación directa de privilegios. Sin embargo, las autorizaciones pueden permitir a un usuario realizar tareas de seguridad elevada, por ejemplo, asignar indicadores de auditoría.

Consideraciones de uso al asignar directamente atributos de seguridad

La asignación directa de perfiles de derechos y atributos de seguridad puede afectar el uso:

• Los privilegios y las autorizaciones asignados directamente, y los comandos y las autorizaciones en un perfil de derechos asignados directamente deben ser interpretados por un shell de perfil para ser efectivos. De manera predeterminada, no se asigna a los usuarios un shell de perfil.

  El usuario no se debe olvidar de abrir un shell de perfil y de ejecutar los comandos de ese shell.

• La asignación individual de autorizaciones no es ampliable. Y las autorizaciones asignadas directamente podrían no ser suficientes para realizar una tarea. Es posible que la tarea pueda requerir comandos con privilegios.

  Los perfiles de derechos están diseñados para agrupar autorizaciones y comandos con privilegios. También son ampliables.