Creación de perfiles de derechos, autorizaciones y roles.

Creación de perfiles de derechos y autorizaciones

Puede crear o cambiar un perfil de derechos cuando los perfiles de derechos proporcionados no contienen la recopilación de derechos que necesita. Podría crear un perfil de derechos para los usuarios con derechos limitados para una aplicación nueva o por otros motivos.
Los perfiles de derechos que Oracle Solaris proporciona son de solo lectura. Puede clonar un perfil de derechos proporcionado para modificarlo si su colección de derechos no es suficiente. Por ejemplo, es posible que quiera agregar la autorización solaris.admin.edit/path-to-system-filea un perfil de derechos proporcionado. Para obtener información general, consulte Más información sobre los perfiles de derechos.
Puede crear una autorización cuando las autorizaciones proporcionadas no incluyen las autorizaciones que están codificadas en sus aplicaciones con privilegios. No puede cambiar una autorización existente. Para obtener información general, consulte Más información sobre las autorizaciones del usuario.



Cómo crear un perfil de derechos

Antes de empezar
Para crear un perfil de derechos, debe convertirse en un administrador con el perfil de derechos de seguridad de archivos asignado. Para obtener más información, consulte Uso de sus derechos administrativos asignados.
  1. Cree un perfil de derechos.
    # profiles -p [-S repository] profile-name
    Se le pedirá una descripción.
  2. Agregue contenidos al perfil de derechos.
    Use el subcomando set para las propiedades de perfil que tengan un único valor, como set desc. Use el subcomando add para las propiedades que tengan más de un valor, como add cmd.
    El siguiente comando crea el perfil de derechos del módulo de autenticación conectable en Cómo asignar una política del PAM modificada de Gestión de Kerberos y otros servicios de autenticación en Oracle Solaris 11.2 . El nombre se acorta con fines de visualización.
    # profiles -p -S LDAP "Site PAM LDAP"
    profiles:Site PAM LDAP> set desc="Profile which sets pam_policy=ldap"
    ...LDAP> set pam_policy=ldap
    ...LDAP> commit
    ...LDAP> end
    ...LDAP> exit
Ejemplo 5-6  Creación de un perfil de derechos de usuarios Sun Ray
En este ejemplo, el administrador crea un perfil de derechos para usuarios Sun Ray en el repositorio LDAP. El administrador ya ha creado una versión Sun Ray del perfil de derechos de usuario de Solaris básico y ha eliminado todos los derechos de perfiles del archivo policy.conf en el servidor Sun Ray.
# profiles -p -S LDAP "Sun Ray Users"
profiles:Sun Ray Users> set desc="For all users of Sun Rays"
... Ray Users> add profiles="Sun Ray Basic User"
... Ray Users> set defaultpriv="basic,!proc_info"
... Ray Users> set limitpriv="basic,!proc_info"
... Ray Users> end
... Ray Users> exit
El administrador verifica el contenido.
# profiles -p "Sun Ray Users" info
Found profile in LDAP repository.
        name=Sun Ray Users
        desc=For all users of Sun Rays
        defaultpriv=basic,!proc_info,
        limitpriv=basic,!proc_info,
        profiles=Sun Ray Basic User
Ejemplo 5-7  Creación de un perfil de derechos que incluye comandos con privilegios
En este ejemplo, el administrador de seguridad agrega privilegios a una aplicación en un perfil de derechos que crea el administrador. La aplicación admite privilegios.
# profiles -p SiteApp
profiles:SiteApp> set desc="Site application"
profiles:SiteApp> add cmd="/opt/site-app/bin/site-cmd"
profiles:SiteApp:site-cmd> add privs="proc_fork,proc_taskid"
profiles:SiteApp:site-cmd> end
profiles:SiteApp> exit
Para verificar, el administrador selecciona site-cmd.
# profiles -p SiteApp "select cmd=/opt/site-app/bin/site-cmd; info;end"
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  privs=proc_fork,proc_taskid
Pasos siguientes
Asigne el perfil de derechos a un usuario o rol confiable. Para ver ejemplos, consulte Example 3–10 y Example 3–19.
Véase también
Para solucionar problemas en la asignación de derechos, consulte Cómo resolver problemas de las asignaciones de derechos. Para obtener información general, consulte Orden de búsqueda para derechos asignados.

Cómo clonar y modificar un perfil de derechos del sistema

Antes de empezar
Para crear o cambiar un perfil de derechos, debe convertirse en un administrador con el perfil de derechos de seguridad de archivos asignado. Para obtener más información, consulte Uso de sus derechos administrativos asignados.
  1. Cree un nuevo perfil de derechos a partir de un perfil existente.
    # profiles -p [-S repository] existing-profile-name
    • Para agregar contenido a un perfil de derechos existente, cree un nuevo perfil.
      Agregue el perfil de derechos existente como perfil de derechos suplementario al nuevo perfil; luego, agregue las mejoras. Consulte Example 5–8.
    • Para eliminar contenido de un perfil de derechos existente, clone el perfil y, a continuación, cámbiele el nombre y modifíquelo.
      Consulte Example 5–9.
  2. Modifique el nuevo perfil de derechos mediante la agregación o eliminación de perfiles de derechos suplementarios, autorizaciones y otros derechos.
Ejemplo 5-8  Clonación y mejora del perfil de derechos de gestión de IPsec de red
En este ejemplo, el administrador agrega una autorización solaris.admin.edit a un perfil de derechos de gestión de IPsec de sitio para que el rol root no sea necesario. Este perfil de derechos se asignará sólo a los usuarios que son de confianza para modificar el archivo /etc/hosts.
  1. El administrador verifica que el perfil de derechos de gestión de IPsec de red no se puede modificar.
    # profiles -p "Network IPsec Management"
    profiles:Network IPsec Management> add auths="solaris.admin.edit/etc/hosts"
    Cannot add. Profile cannot be modified
  2. El administrador crea un perfil de derechos que incluye el perfil de gestión de IPsec de red.
    # profiles -p "Total IPsec Mgt"
    ... IPsec Mgt> set desc="Network IPsec Mgt plus /etc/hosts"
    ... IPsec Mgt> add profiles="Network IPsec Management"
    ... IPsec Mgt> add auths="solaris.admin.edit/etc/hosts"
    ... IPsec Mgt> end
    ... IPsec Mgt> exit
  3. El administrador verifica el contenido.
    # profiles -p "Total IPsec Mgt" info
            name=Total IPsec Mgt
            desc=Network IPsec Mgt plus /etc/hosts
            auths=solaris.admin.edit/etc/hosts
            profiles=Network IPsec Management
Ejemplo 5-9  Clonación y eliminación de derechos seleccionados de un perfil de derechos
En este ejemplo, el administrador separa la gestión de las propiedades del servicio VSCAN de la capacidad para activar y desactivar el servicio.
En primer lugar, el administrador muestra el contenido del perfil de derechos que proporciona Oracle Solaris.
# profiles -p "VSCAN Management" info
        name=VSCAN Management
        desc=Manage the VSCAN service
        auths=solaris.smf.manage.vscan,solaris.smf.value.vscan,
              solaris.smf.modify.application
        help=RtVscanMngmnt.html
Luego, el administrador crea un perfil de derechos que puede activar y desactivar el servicio.
# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Control"
profiles:VSCAN Control> set desc="Start and stop the VSCAN service"
... VSCAN Control> remove auths="solaris.smf.value.vscan"
... VSCAN Control> remove auths="solaris.smf.modify.application"
... VSCAN Control> end
... VSCAN Control> exit
Luego, el administrador crea un perfil de derechos que puede cambiar las propiedades del servicio.
# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Properties"
profiles:VSCAN Properties> set desc="Modify VSCAN service properties"
... VSCAN Properties> remove auths="solaris.smf.manage.vscan"
... VSCAN Properties> end
... VSCAN Properties> exit
El administrador verifica el contenido del nuevo perfil de derechos.
# profiles -p "VSCAN Control" info
        name=VSCAN Control
        desc=Start and stop the VSCAN service
        auths=solaris.smf.manage.vscan
# profiles -p "VSCAN Properties" info
        name=VSCAN Properties
        desc=Modify VSCAN service properties
        auths=solaris.smf.value.vscan,solaris.smf.modify.application
Pasos siguientes
Asigne el perfil de derechos a un usuario o rol confiable. Para ver ejemplos, consulte Example 3–10 y Example 3–19.
Véase también
Para solucionar problemas en la asignación de derechos, consulte Cómo resolver problemas de las asignaciones de derechos. Para obtener información general, consulte Orden de búsqueda para derechos asignados.

Cómo crear una autorización

Antes de empezar
Los desarrolladores han definido y utilizado la autorización en las aplicaciones que está instalando. Para obtener instrucciones, consulte Developer’s Guide to Oracle Solaris 11 Security About Authorizations de Developer’s Guide to Oracle Solaris 11 Security .
  1. (Opcional) Cree el archivo de ayuda para su nueva autorización.
    Por ejemplo, cree el archivo de ayuda para que una autorización permita al usuario modificar los datos en una aplicación.
    # pfedit /docs/helps/NewcoSiteAppModData.html
    <HTML>
    -- Copyright 2013 Newco.  All rights reserved.
    -- NewcoSiteAppModData.html 
    -->
    <HEAD>
         <TITLE>NewCo Modify SiteApp Data Authorization</TITLE>
    </HEAD>
    <BODY>
    The com.newco.siteapp.data.modify authorization authorizes you 
    to modify existing data in the application.
    <p>
    Only authorized accounts are permitted to modify data. 
    Use this authorization with care.
    <p>
    </BODY>
    </HTML>
  2. Cree la autorización utilizando el comando auths add.
    Por ejemplo, el siguiente comando crea la autorización com.newco.siteapp.data.modify en el sistema local.
    # auths add -t "SiteApp Data Modify Authorized" \
    -h /docs/helps/NewcoSiteAppModData.html com.newco.siteapp.data.modify
    Ahora, puede probar la autorización; luego, puede agregarla a un perfil de derechos y asignar al perfil un rol o a un usuario.
Ejemplo 5-10  Prueba de una nueva autorización
En este ejemplo, el administrador prueba la autorización com.newco.siteapp.data.modify con el perfil de derechos SiteApp de Example 5–7.
# usermod -A com.newco.siteapp.data.modify -P SiteApp tester1
Cuando la prueba es correcta, el administrador elimina la autorización.
# rolemod -A-=com.newco.siteapp.data.modify siteapptester
Para facilitar el mantenimiento, el administrador agrega la autorización al perfil de derechos de SiteApp en Example 5–11.
Ejemplo 5-11  Agregación de autorizaciones a un perfil de derechos
Después de probar que la autorización funciona correctamente, el administrador de la seguridad agrega la autorización com.newco.siteapp.data.modify a un perfil de derechos existente. Example 5–7 muestra cómo el administrador creó el perfil.
# profiles -p "SiteApp"
profiles:SiteApp> add auths="com.newco.siteapp.data.modify"
profiles:SiteApp> end
profiles:SiteApp> exit
Para realizar una verificación, el administrador muestra el contenido del perfil.
# profiles -p SiteApp
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  auths=com.newco.siteapp.data.modify



Ejemplo 3-10  Creación de un usuario que puede administrar DHCP
El administrador de la seguridad crea un usuario que puede administrar DHCP.
# useradd -P "DHCP Management" -s /usr/bin/pfbash -S ldap  jdoe
Debido a que el usuario tiene asignado pfbash como el shell de inicio de sesión, los derechos en el perfil de derechos de gestión de DHCP siempre se evalúan para que los comandos administrativos de DHCP se realicen correctamente.
Ejemplo 3-11  Requerir que un usuario escriba la contraseña antes de administrar DHCP
En este ejemplo, el administrador de la seguridad requiere que jdoe proporcione una contraseña antes de gestionar DHCP.
# usermod -K auth_profiles="DHCP Management" profiles="Edit Administrative Files" jdoe
Cuando jdoe escribe un comando DHCP, aparece el indicador de contraseña. Después de autenticar jdoe, el comando DHCP termina. En orden de búsqueda, los perfiles de derechos autenticados se procesan antes de los perfiles normales.
jdoe% dhcpconfig -R 120.30.33.7,120.30.42.132
Password: xxxxxxxx  
/** Command completes **/
Ejemplo 3-12  Asignación de autorizaciones directamente a un usuario
En este ejemplo, el administrador de seguridad crea un usuario local que puede controlar el brillo de la pantalla.
# useradd -c "Screened KDoe, local" -s /usr/bin/pfbash \
-A solaris.system.power.brightness  kdoe
Esta autorización se agrega a las asignaciones existentes del usuario.
Ejemplo 3-13  Asignación de autorizaciones a un rol
En este ejemplo, el administrador de la seguridad crea un rol que puede cambiar la información de configuración para el servicio de servidor DNS.
# roleadd -c "DNS administrator role" -m -A solaris.smf.manage.bind" dnsadmin
Ejemplo 3-14  Asignación de privilegios directamente a un usuario
En este ejemplo, el administrador de la seguridad confía al usuario kdoe un privilegio muy específico que afecta la hora del sistema. Para asignar el privilegio a un rol, consulte Example 3–8.
# usermod -K defaultpriv='basic,proc_clock_highres' kdoe
Los valores de la palabra clave defaultpriv reemplazan los valores existentes. Por lo tanto, para que el usuario conserve los privilegios basic, se especifica el valor basic. En la configuración predeterminada, todos los usuarios tienen privilegios básicos. Para ver la lista de privilegios básicos, consulte Enumeración de privilegios.
El usuario puede ver el privilegio agregado y su definición.
kdoe% ppriv -v $$
1800:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,sys_ib_info
        I: file_link_any,…,proc_clock_highres,sys_ib_info
        P: file_link_any,…,proc_clock_highres,sys_ib_info
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,...,win_upgrade_sl
% ppriv -vl proc_clock_highres
        Allows a process to use high resolution timers.
Ejemplo 3-15  Agregación a privilegios básicos de un rol
En el ejemplo siguiente, el rol realtime tiene privilegios asignados directamente para gestionar los programas relacionados con la fecha y la hora. Se asignó proc_clock_highres a realtime en Example 3–8.
# rolemod -K defaultpriv='basic,sys_time' realtime
% su - realtime
Password: xxxxxxxx
# ppriv -v $$
1600:   pfksh
flags = <none>
        E: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time
        I: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time
        P: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,...,sys_time
Ejemplo 3-16  Activación de un usuario para que use su propia contraseña para la contraseña del rol
De manera predeterminada, los usuarios deben escribir la contraseña del rol para asumir un rol. Mediante la solicitud de una contraseña de usuario, el administrador hace que asumir un rol en Oracle Solaris sea similar a asumir un rol en un entorno de Linux.
# rolemod -K roleauth=user auditrev
Para asumir este rol, los usuarios asignados pueden usar ahora sus propias contraseñas, no la contraseña que se creó específicamente para el rol.
Si se le han asignado otros roles al usuario, la contraseña del usuario también permite la autenticación ante esos roles.
Ejemplo 3-17  Modificación de un perfil de derechos para permitir que un usuario use su propia contraseña para la contraseña del rol
# profiles -p "Local System Administrator"
profiles:Local System Administrator> set roleauth="user"
profiles:Local System Administrator> end
profiles:Local System Administrator> exit
Cuando un usuario al que se le asigna el perfil de derechos de administrador del sistema local desea asumir el rol, se le solicita una contraseña. En la secuencia siguiente, el nombre del rol es admin:
% su - admin
Password: xxxxxxxx
# /** You are now in a profile shell with administrative rights**/
Ejemplo 3-18  Cambio del valor de roleauth por un rol en el repositorio LDAP
En este ejemplo, el rol root permite a todos los usuarios que pueden asumir el rol secadmin utilizar su propia contraseña al asumir un rol. Esta habilidad se concede a estos usuarios para todos los sistemas que están gestionados por el servidor LDAP.
# rolemod -S ldap -K roleauth=user secadmin
Ejemplo 3-19  Activación de un usuario de confianza para leer los archivos de contabilidad ampliada
Puede activar un usuario o un grupo de usuarios de confianza para leer un archivo que es propiedad de la cuenta root. Este derecho puede ser útil para los usuarios que pueden ejecutar una aplicación administrativa que incluye un archivo propiedad de root. En este ejemplo, se agregan una o más archivos de comandos Perl para el perfil de derechos de gestión de red de contabilidad ampliada.
Después de asumir el rol root, el administrador crea un perfil de derechos que agrega la capacidad para leer archivos contables cuyos nombres comiencen con network.
El perfil siguiente utiliza la política de privilegio extendido para otorgar el privilegio file_dac_read a una secuencia de comandos que puede acceder a archivos /var/adm/exacct/network* solamente. Este perfil agrega el perfil de derechos de gestión de red de contabilidad ampliada existente como un perfil suplementario.
# profiles -p "Extended Accounting Perl Scripts"
profiles:Extended Accounting Perl Scripts > 
set desc="Perl Scripts for Extended Accounting"
... Scripts> add profiles="Extended Accounting Net Management"
... Scripts> add cmd=/usr/local/bin/exacctdisp.pl
... Scripts:exacctdisp.pl> set privs={file_dac_read}:/var/adm/exacct/network*
... Scripts:exacctdisp.pl> end
... Scripts> commit
... Scripts> exit
Después de revisar las entradas del perfil de derechos entradas en busca de errores tipográficos, omisiones o repeticiones, el administrador asigna el perfil de derechos de secuencias de comandos Perl de contabilidad ampliada a un rol o un usuario.
# profiles -p "Extended Accounting Perl Scripts" info
Found profile in files repository.
name=Extended Accounting Perl Scripts
desc=Perl Scripts for Extended Accounting
profiles=Extended Accounting Net Management
cmd=/usr/local/bin/exacctdisp.pl
privs={file_dac_read}:/var/adm/exacct/network*
# rolemod -K profiles+="Extended Accounting Perl Scripts" rolename
# usermod -K profiles+="Extended Accounting Perl Scripts" username
Ejemplo 3-20  Activación de una cuenta no root para leer un archivo de propiedad de root.
En este ejemplo, el administrador crea un perfil de derechos que utiliza la política de privilegio extendido para permitir que los usuarios y roles autorizados lean el archivo /var/adm/sulog que es propiedad de root. El administrador agrega los comandos que el usuario puede utilizar para leer el archivo. No se pueden utilizar comandos que no aparezcan en la lista, como el comando head.
# profiles -p "Read sulog File"
profiles:Read sulog File 
set desc="Read sulog File"
... File> add profiles="Read Log Files"
... File> add cmd=/usr/bin/cat
... File:cat> set privs={file_dac_read}:/var/adm/sulog
... File:cat> end
... File> add cmd=/usr/bin/less
... File:less> set privs={file_dac_read}:/var/adm/sulog
... File:less> end
... File> add cmd=/usr/bin/more
... File:more> set privs={file_dac_read}:/var/adm/sulog
... File:more> end
... File> add cmd=/usr/bin/page
... File:page> set privs={file_dac_read}:/var/adm/sulog
... File:page> end
... File> add cmd=/usr/bin/tail
... File:tail> set privs={file_dac_read}:/var/adm/sulog
... File:tail> end
... File> add cmd=/usr/bin/view
... File:head> set privs={file_dac_read}:/var/adm/sulog
... File:head> end
... File> commit
... File> exit


Asignación de derechos a usuarios y roles

En esta sección, se describen los comandos que permiten crear y modificar roles y usuarios. Para crear o modificar los perfiles de derechos, consulte Cómo crear un perfil de derechos y Cómo clonar y modificar un perfil de derechos del sistema.
Para obtener información sobre los roles, consulte Aspectos básicos del usuario y derechos de procesos.
    Las principales acciones en la creación y modificación de roles y usuarios son los siguientes:
  • Creación de roles
  • Creación de un usuario de confianza
  • Modificación de los derechos de un rol
  • Modificación de los derechos de un usuario
  • Activación de los usuarios para utilizar su propia contraseña para asumir un rol
  • Cambio de una contraseña de rol
  • Supresión de un rol

Creación de roles

Si va a utilizar roles, tiene varias opciones. Puede instalar los roles predefinidos de ARMOR y utilizarlas de forma exclusiva. Además, puede crear roles y asignarles contraseñas. Puede utilizar roles ARMOR con los roles que usted crea.
Para utilizar roles Armor, consulte Example 3–1.
Para crear sus propios roles, utilice el comando roleadd. Para obtener una descripción detallada de este comando, consulte la página del comando man roleadd(1M).
Por ejemplo, los siguientes comandos crean un rol de administrador de usuario local con un directorio principal y un shell de inicio de sesión pfbash y crean una contraseña para el rol:
# roleadd -c "User Administrator role, local" \
-m -K profiles="User Security,User Management"  useradm
80 blocks
# ls /export/home/useradm
local.bash_profile     local.login     local.profile
# passwd useradm
Password: xxxxxxxx
Confirm Password: xxxxxxxx
donde
–c comment
Describe el rol.
–m
Crea un directorio principal.
–K profiles=
Asigna uno o varios perfiles de derechos al rol. Para la lista de perfiles de derechos, consulte Lista de perfiles de derechos.
rolename
El nombre del rol. Para ver las restricciones en cadenas aceptables, consulte la página del comando man roleadd(1M).

Notas -  Un rol se puede asignar a más de un usuario. Por lo tanto, un administrador, normalmente, crea una contraseña de rol y proporciona a los usuarios la contraseña de rol fuera de banda. Para conocer una alternativa a la contraseña de rol, consulte Activación de los usuarios para que usen su propia contraseña para la contraseña del rolExample 3–16, and Example 3–17.

Ejemplo 3-1  Uso de roles ARMOR
En este ejemplo, el administrador de la seguridad instala los roles que están definidos por el ARMOR estándar. El administrador verifica que los nombres de roles no entren en conflicto con cualquier cuenta existente y, a continuación, instala el depósito de paquetes, ve las definiciones de roles y asigna los roles a usuarios de confianza.
    En primer lugar, el administrador garantiza que el siguiente UID y los nombres no existen en el servicio de nombres:
  • 57 auditadm
  • 55 fsadm
  • 58 pkgadm
  • 53 secadm
  • 56 svcadm
  • 59 sysop
  • 54 useradm
Después de verificar que los UID y los administradores de los nombres no están en uso, el administrador instala el depósito de paquetes.
# pkg install system/security/armor
El depósito de paquetes crea siete roles y directorios principales locales en el directorio /export/home.
Para ver los derechos de cada función, el administrador puede enumerar los perfiles que están asignados a cada rol.
# profiles auditadm
# profiles fsadm
# profiles pkgadm
# profiles secadm
# profiles svcadm
# profiles sysop
# profiles useradm
Estas asignaciones de derechos no se pueden modificar. Para crear una configuración diferente de derechos, debe crear nuevos roles y, a continuación, crear nuevos perfiles de derechos mediante los pasos descritos en Cómo clonar y modificar un perfil de derechos del sistema.
Por último, el administrador asigna los roles a los usuarios de confianza. Las propias de los usuarios se utilizan las contraseñas para autenticar al rol. Algunos usuarios se asignan más de un rol. Los roles cuyas tareas dependen del tiempo se asignan a más de un usuario de confianza.
# usermod -R=auditadm adal
# usermod -R=fsadm,pkgadm bdewey
# usermod -R=secadm,useradm cfoure
# usermod -R=svcadm ghamada
# usermod -R=svcadm yjones
# usermod -R=sysop hmurtha
# usermod -R=sysop twong
Ejemplo 3-2  Creación de un rol de administrador de usuarios en el repositorio LDAP
El administrador crea un rol de administrador de usuarios en LDAP. El usuario proporciona una contraseña al asumir el rol y, a continuación, no necesita proporcionar una contraseña para comandos individuales.
# roleadd -c "User Administrator role, LDAP" -m -S ldap \
-K profiles="User Security,User Management"  useradm
Ejemplo 3-3  Creación de roles para la separación de tareas
El administrador crea dos roles. El rol usermgt puede crear usuarios, darles directorios principales y realizar otras tareas que no son de seguridad. El rol usersec no puede crear usuarios, pero puede asignar contraseñas y cambiar otras asignaciones de derechos. Ningún rol puede definir indicadores para usuarios o roles o cambiar la contraseña de un rol. El rol root, debe realizar esas acciones.
# roleadd -c "User Management role, LDAP" -s /usr/bin/pfksh \
-m -S ldap -K profiles="User Management"  usermgt
# roleadd -c "User Security role, LDAP" -s /usr/bin/pfksh \
-m -S ldap -K profiles="User Security"  usersec
El administrador garantiza que se necesitan dos personas para crear cada usuario común en Example 3–5.
Ejemplo 3-4  Creación y asignación de un rol para administrar los servicios criptográficos
En este ejemplo, el administrador en una red LDAP crea un rol para administrar la estructura criptográfica y asigna el rol al UID 1111.
# roleadd -c "Cryptographic Services manager" \
-g 14 -m -u 104 -S ldap -K profiles="Crypto Management" cryptmgt
# passwd cryptmgt
New Password: xxxxxxxx
Confirm password: xxxxxxxx 
# usermod -u 1111 -R +cryptmgt
El usuario con el UID 1111 inicia sesión, luego asume el rol y muestra los derechos asignados.
% su - cryptmgt
Password: xxxxxxxx
# profiles -l
      Crypto Management
          /usr/bin/kmfcfg            euid=0
          /usr/sbin/cryptoadm        euid=0
          /usr/sfw/bin/CA.pl         euid=0
          /usr/sfw/bin/openssl       euid=0
#

Creación de un inicio de sesión para un usuario de confianza

Se utiliza el useradd para crear un inicio de sesión. Para obtener una lista completa de los argumentos para el comando useradd, consulte la página del comando man useradd(1M). Los argumentos relacionados con los derechos para el comando son similares al comando roleadd, con la agregación de la opción –R rolename.
Si asigna un rol a un usuario, el usuario puede utilizar los derechos del rol el después de asumir el rol. Por ejemplo, el comando siguiente crea un usuario de confianza que puede asumir el rol useradm que creó en Creación de un inicio de sesión para un usuario de confianza.
# useradd -c "Trusted Assistant User Manager user" -m -R useradm jdoe
80 blocks
# ls /export/home/jdoe
local.bash_profile     local.login     local.profile
donde
–s shell
Determina el shell de inicio de sesión para username. Este shell debe ser un shell de perfil, como pfbash. Por motivos para asignar un shell de perfil a un usuario de confianza, consulte Consideraciones de uso al asignar derechos. Para obtener una lista de shells de perfiles, consulte la página del comando man pfexec(1).
–R rolename
Asigna el nombre de un rol local existente.

Modificación de derechos de un usuario

Utilizar el comando usermod para modificar una cuenta de usuario. Para obtener una lista completa de los argumentos para el comando usermod, consulte la consulte la página del comando man usermod(1M). Los argumentos relacionados con los derechos para el comando son similares al comando useradd.
Si asigna un perfil de derechos a un usuario, el usuario puede utilizar los derechos después de que el usuario abre un shell de perfil. Por ejemplo, asigna un perfil de derechos a un usuario:
# usermod -K profiles="User Management" kdoe
Los cambios entran en vigencia a partir del siguiente inicio de sesión del usuario. Para que los usuarios aprendan a utilizar sus derechos asignados, remítalos a Uso de sus derechos administrativos asignados.
Ejemplo 3-5  Agregar un rol a un usuario
En este ejemplo, el administrador garantiza que se necesitan dos usuarios de confianza para crear los usuarios comunes. Los roles fueron creados en Example 3–3.
# usermod -R +useradm jdoe
# usermod -R +usersec mdoe

Modificación de derechos de un rol

Utilizar el comando rolemod para modificar una cuenta de rol. Para obtener una lista completa de los argumentos para el comando rolemod, consulte la página del comando man rolemod(1M). Los argumentos relacionados con los derechos para el comando son similares al comandoroleadd.
Los valores de los pares key=value, y las opciones –A–P y –R pueden ser modificadas por un signo menos () o más (). El signo  indica que se va a restar el valor de los valores asignados actualmente. El signo  indica que se va a agregar el valor a los valores asignados actualmente. Para perfiles de derechos, el valor se antepone a la lista de perfiles actual. Para consultar los efectos de un perfil de derechos anterior, consulte Orden de búsqueda para derechos asignados.
Ejemplo 3-6  Agregación de un perfil de derechos como el perfil de derechos del rol
Por ejemplo, anteponga un perfil de derechos al rol useradm:
# rolemod -K profiles+="Device Management" useradm
# profiles useradm
useradm:
Device Management
User Management
User Security
Ejemplo 3-7  Reemplazar los perfiles asignados del rol local
En este ejemplo, el administrador de la seguridad modifica el rol prtmgt para incluir el perfil de derechos de VSCAN después del perfil de gestión de impresoras.
# rolemod -c "Handles printers and virus scanning" \
-P "Printer Management,VSCAN Management,All" prtmgt
Ejemplo 3-8  Asignación de privilegios directamente a un rol
En este ejemplo, el administrador de la seguridad confía al rol realtime un privilegio muy específico que afecta la hora del sistema. Para asignar el privilegio a un usuario, consulte Example 3–14.
# rolemod -K defaultpriv+='proc_clock_highres' realtime
Los valores de la palabra clave defaultpriv se encuentran en la lista de privilegios de los procesos del rol en todo momento.

Activación de los usuarios para que usen su propia contraseña para la contraseña del rol

Para activar a los usuarios para que usen su propia contraseña en lugar de una contraseña de rol al asumir un rol, modifique el rol.
El siguiente comando activa todos los usuarios que tienen asignado el rol useradm para utilizar su propia contraseña al asumir cualquier rol asignado, incluido el rol useradm.
# rolemod -K roleauth=user useradm

Cambio de una contraseña de rol

Debido a que un rol se puede asignar a varios usuarios, los usuarios a los que se asigna un rol no pueden cambiar la contraseña del rol. Debe tener el rol root para cambiar una contraseña de rol.
# passwd useradm
Enter useradm's password: xxxxxxxx
New: xxxxxxxx
Confirm: xxxxxxxx
Si no especifica un repositorio, se cambia la contraseña en todos los repositorios.
Para conocer más opciones de comandos, consulte la página del comando man passwd(1).
Ejemplo 3-9  Cambiar la contraseña de un rol en un repositorio específico
En el siguiente ejemplo, el rol root cambia la contraseña del rol devadmin.
# passwd -r files  devadmin
New password: xxxxxxxx
Confirm password: xxxxxxxx
En el ejemplo siguiente, el rol root cambia la contraseña del rol devmgt en el servicio de nombres LDAP.
# passwd -r ldap devadmin
New password: xxxxxxxx
Confirm password: xxxxxxxx

Supresión de un rol

Al suprimir un rol, el rol inmediatamente se vuelve no utilizable.
# roledel useradm
A los usuarios que actualmente están realizando tareas administrativas en el rol se le impedirá continuar. El comando profiles muestra la siguiente salida:
useradm # profiles
Unable to get user name

Creación de perfiles de derechos y autorizaciones

Puede crear o cambiar un perfil de derechos cuando los perfiles de derechos proporcionados no contienen la recopilación de derechos que necesita. Podría crear un perfil de derechos para los usuarios con derechos limitados para una aplicación nueva o por otros motivos.
Los perfiles de derechos que Oracle Solaris proporciona son de solo lectura. Puede clonar un perfil de derechos proporcionado para modificarlo si su colección de derechos no es suficiente. Por ejemplo, es posible que quiera agregar la autorización solaris.admin.edit/path-to-system-filea un perfil de derechos proporcionado. Para obtener información general, consulte Más información sobre los perfiles de derechos.
Puede crear una autorización cuando las autorizaciones proporcionadas no incluyen las autorizaciones que están codificadas en sus aplicaciones con privilegios. No puede cambiar una autorización existente. Para obtener información general, consulte Más información sobre las autorizaciones del usuario.

Cómo crear un perfil de derechos

Antes de empezar
Para crear un perfil de derechos, debe convertirse en un administrador con el perfil de derechos de seguridad de archivos asignado. Para obtener más información, consulte Uso de sus derechos administrativos asignados.
  1. Cree un perfil de derechos.
    # profiles -p [-S repository] profile-name
    Se le pedirá una descripción.
  2. Agregue contenidos al perfil de derechos.
    Use el subcomando set para las propiedades de perfil que tengan un único valor, como set desc. Use el subcomando add para las propiedades que tengan más de un valor, como add cmd.
    El siguiente comando crea el perfil de derechos del módulo de autenticación conectable en Cómo asignar una política del PAM modificada de Gestión de Kerberos y otros servicios de autenticación en Oracle Solaris 11.2 . El nombre se acorta con fines de visualización.
    # profiles -p -S LDAP "Site PAM LDAP"
    profiles:Site PAM LDAP> set desc="Profile which sets pam_policy=ldap"
    ...LDAP> set pam_policy=ldap
    ...LDAP> commit
    ...LDAP> end
    ...LDAP> exit
Ejemplo 5-6  Creación de un perfil de derechos de usuarios Sun Ray
En este ejemplo, el administrador crea un perfil de derechos para usuarios Sun Ray en el repositorio LDAP. El administrador ya ha creado una versión Sun Ray del perfil de derechos de usuario de Solaris básico y ha eliminado todos los derechos de perfiles del archivo policy.conf en el servidor Sun Ray.
# profiles -p -S LDAP "Sun Ray Users"
profiles:Sun Ray Users> set desc="For all users of Sun Rays"
... Ray Users> add profiles="Sun Ray Basic User"
... Ray Users> set defaultpriv="basic,!proc_info"
... Ray Users> set limitpriv="basic,!proc_info"
... Ray Users> end
... Ray Users> exit
El administrador verifica el contenido.
# profiles -p "Sun Ray Users" info
Found profile in LDAP repository.
        name=Sun Ray Users
        desc=For all users of Sun Rays
        defaultpriv=basic,!proc_info,
        limitpriv=basic,!proc_info,
        profiles=Sun Ray Basic User
Ejemplo 5-7  Creación de un perfil de derechos que incluye comandos con privilegios
En este ejemplo, el administrador de seguridad agrega privilegios a una aplicación en un perfil de derechos que crea el administrador. La aplicación admite privilegios.
# profiles -p SiteApp
profiles:SiteApp> set desc="Site application"
profiles:SiteApp> add cmd="/opt/site-app/bin/site-cmd"
profiles:SiteApp:site-cmd> add privs="proc_fork,proc_taskid"
profiles:SiteApp:site-cmd> end
profiles:SiteApp> exit
Para verificar, el administrador selecciona site-cmd.
# profiles -p SiteApp "select cmd=/opt/site-app/bin/site-cmd; info;end"
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  privs=proc_fork,proc_taskid
Pasos siguientes
Asigne el perfil de derechos a un usuario o rol confiable. Para ver ejemplos, consulte Example 3–10 y Example 3–19.
Véase también
Para solucionar problemas en la asignación de derechos, consulte Cómo resolver problemas de las asignaciones de derechos. Para obtener información general, consulte Orden de búsqueda para derechos asignados.

Cómo clonar y modificar un perfil de derechos del sistema

Antes de empezar
Para crear o cambiar un perfil de derechos, debe convertirse en un administrador con el perfil de derechos de seguridad de archivos asignado. Para obtener más información, consulte Uso de sus derechos administrativos asignados.
  1. Cree un nuevo perfil de derechos a partir de un perfil existente.
    # profiles -p [-S repository] existing-profile-name
    • Para agregar contenido a un perfil de derechos existente, cree un nuevo perfil.
      Agregue el perfil de derechos existente como perfil de derechos suplementario al nuevo perfil; luego, agregue las mejoras. Consulte Example 5–8.
    • Para eliminar contenido de un perfil de derechos existente, clone el perfil y, a continuación, cámbiele el nombre y modifíquelo.
      Consulte Example 5–9.
  2. Modifique el nuevo perfil de derechos mediante la agregación o eliminación de perfiles de derechos suplementarios, autorizaciones y otros derechos.
Ejemplo 5-8  Clonación y mejora del perfil de derechos de gestión de IPsec de red
En este ejemplo, el administrador agrega una autorización solaris.admin.edit a un perfil de derechos de gestión de IPsec de sitio para que el rol root no sea necesario. Este perfil de derechos se asignará sólo a los usuarios que son de confianza para modificar el archivo /etc/hosts.
  1. El administrador verifica que el perfil de derechos de gestión de IPsec de red no se puede modificar.
    # profiles -p "Network IPsec Management"
    profiles:Network IPsec Management> add auths="solaris.admin.edit/etc/hosts"
    Cannot add. Profile cannot be modified
  2. El administrador crea un perfil de derechos que incluye el perfil de gestión de IPsec de red.
    # profiles -p "Total IPsec Mgt"
    ... IPsec Mgt> set desc="Network IPsec Mgt plus /etc/hosts"
    ... IPsec Mgt> add profiles="Network IPsec Management"
    ... IPsec Mgt> add auths="solaris.admin.edit/etc/hosts"
    ... IPsec Mgt> end
    ... IPsec Mgt> exit
  3. El administrador verifica el contenido.
    # profiles -p "Total IPsec Mgt" info
            name=Total IPsec Mgt
            desc=Network IPsec Mgt plus /etc/hosts
            auths=solaris.admin.edit/etc/hosts
            profiles=Network IPsec Management
Ejemplo 5-9  Clonación y eliminación de derechos seleccionados de un perfil de derechos
En este ejemplo, el administrador separa la gestión de las propiedades del servicio VSCAN de la capacidad para activar y desactivar el servicio.
En primer lugar, el administrador muestra el contenido del perfil de derechos que proporciona Oracle Solaris.
# profiles -p "VSCAN Management" info
        name=VSCAN Management
        desc=Manage the VSCAN service
        auths=solaris.smf.manage.vscan,solaris.smf.value.vscan,
              solaris.smf.modify.application
        help=RtVscanMngmnt.html
Luego, el administrador crea un perfil de derechos que puede activar y desactivar el servicio.
# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Control"
profiles:VSCAN Control> set desc="Start and stop the VSCAN service"
... VSCAN Control> remove auths="solaris.smf.value.vscan"
... VSCAN Control> remove auths="solaris.smf.modify.application"
... VSCAN Control> end
... VSCAN Control> exit
Luego, el administrador crea un perfil de derechos que puede cambiar las propiedades del servicio.
# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Properties"
profiles:VSCAN Properties> set desc="Modify VSCAN service properties"
... VSCAN Properties> remove auths="solaris.smf.manage.vscan"
... VSCAN Properties> end
... VSCAN Properties> exit
El administrador verifica el contenido del nuevo perfil de derechos.
# profiles -p "VSCAN Control" info
        name=VSCAN Control
        desc=Start and stop the VSCAN service
        auths=solaris.smf.manage.vscan
# profiles -p "VSCAN Properties" info
        name=VSCAN Properties
        desc=Modify VSCAN service properties
        auths=solaris.smf.value.vscan,solaris.smf.modify.application
Pasos siguientes
Asigne el perfil de derechos a un usuario o rol confiable. Para ver ejemplos, consulte Example 3–10 y Example 3–19.
Véase también
Para solucionar problemas en la asignación de derechos, consulte Cómo resolver problemas de las asignaciones de derechos. Para obtener información general, consulte Orden de búsqueda para derechos asignados.

Cómo crear una autorización

Antes de empezar
Los desarrolladores han definido y utilizado la autorización en las aplicaciones que está instalando. Para obtener instrucciones, consulte Developer’s Guide to Oracle Solaris 11 Security About Authorizations de Developer’s Guide to Oracle Solaris 11 Security .
  1. (Opcional) Cree el archivo de ayuda para su nueva autorización.
    Por ejemplo, cree el archivo de ayuda para que una autorización permita al usuario modificar los datos en una aplicación.
    # pfedit /docs/helps/NewcoSiteAppModData.html
    <HTML>
    -- Copyright 2013 Newco.  All rights reserved.
    -- NewcoSiteAppModData.html 
    -->
    <HEAD>
         <TITLE>NewCo Modify SiteApp Data Authorization</TITLE>
    </HEAD>
    <BODY>
    The com.newco.siteapp.data.modify authorization authorizes you 
    to modify existing data in the application.
    <p>
    Only authorized accounts are permitted to modify data. 
    Use this authorization with care.
    <p>
    </BODY>
    </HTML>
  2. Cree la autorización utilizando el comando auths add.
    Por ejemplo, el siguiente comando crea la autorización com.newco.siteapp.data.modify en el sistema local.
    # auths add -t "SiteApp Data Modify Authorized" \
    -h /docs/helps/NewcoSiteAppModData.html com.newco.siteapp.data.modify
    Ahora, puede probar la autorización; luego, puede agregarla a un perfil de derechos y asignar al perfil un rol o a un usuario.
Ejemplo 5-10  Prueba de una nueva autorización
En este ejemplo, el administrador prueba la autorización com.newco.siteapp.data.modify con el perfil de derechos SiteApp de Example 5–7.
# usermod -A com.newco.siteapp.data.modify -P SiteApp tester1
Cuando la prueba es correcta, el administrador elimina la autorización.
# rolemod -A-=com.newco.siteapp.data.modify siteapptester
Para facilitar el mantenimiento, el administrador agrega la autorización al perfil de derechos de SiteApp en Example 5–11.
Ejemplo 5-11  Agregación de autorizaciones a un perfil de derechos
Después de probar que la autorización funciona correctamente, el administrador de la seguridad agrega la autorización com.newco.siteapp.data.modify a un perfil de derechos existente. Example 5–7 muestra cómo el administrador creó el perfil.
# profiles -p "SiteApp"
profiles:SiteApp> add auths="com.newco.siteapp.data.modify"
profiles:SiteApp> end
profiles:SiteApp> exit
Para realizar una verificación, el administrador muestra el contenido del perfil.
# profiles -p SiteApp
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  auths=com.newco.siteapp.data.modify
Pasos siguientes
Asigne el perfil de derechos a un usuario o rol confiable. Para ver ejemplos, consulte Example 3–10 y Example 3–19.
Véase también
Para solucionar problemas en la asignación de derechos, consulte Cómo resolver problemas de las asignaciones de derechos. Para obtener información general, consulte Orden de búsqueda para derechos asignados.

Restricción de los derechos de usuario

Los ejemplos de esta sección limitan los derechos de los usuarios comunes o eliminan algunos derechos administrativos de un administrador. Se muestra cómo modificar usuarios, roles y perfiles de derechos. Para obtener información sobre los derechos, consulte Chapter 1, Sobre el uso de los derechos para controlar los usuarios y los procesos.
Ejemplo 3-21  Eliminación de privilegios del conjunto límite de un usuario
En el siguiente ejemplo, a todas las sesiones que se originan a partir del inicio de sesión inicial de jdoe se les impide utilizar el privilegio sys_linkdir. El usuario no puede establecer enlaces físicos a directorios o desvincular directorios incluso después de ejecutar el comando su.
# usermod -K 'limitpriv=all,!sys_linkdir' jdoe
# userattr limitpriv jdoe
all,!sys_linkdir
Ejemplo 3-22  Eliminación de un privilegio básico de un perfil de derechos
En el siguiente ejemplo, tras una exhaustiva prueba, el administrador de seguridad elimina otro privilegio básico del perfil de derechos de usuarios Sun Ray. Cuando el administrador creó el perfil en Example 5–6, el administrador eliminó un privilegio del conjunto límite. Esta vez, el administrador elimina dos privilegios básicos. Los usuarios a los que se asigna este perfil no pueden examinar ningún proceso fuera de su sesión actual y no pueden agregar otra sesión.
# profiles -p "Sun Ray Users"
profiles:Sun Ray Users> set defaultpriv="basic,!proc_session,!proc_info"
profiles:Sun Ray Users> end
profiles:Sun Ray Users> exit
Ejemplo 3-23  Eliminación de un privilegio básico propio
En el siguiente ejemplo, un usuario común modifica .bash_profile para eliminar el privilegio básico proc_info. La salida de programas, como psprstat contienen solamente los procesos propios del usuario, que pueden contener resaltar la información útil.
##  .bash_profile
## Remove proc_info privilege from my shell
##
ppriv -s EI-proc_info $$
La línea pprivelimina el privilegio proc_info del conjunto efectivo y heredable de privilegios del usuario (EI-) en el proceso de shell actual ($$).
En la siguiente salida prstat, los totales se reducen de 74 a tres procesos:
## With all basic privileges
Total: 74 processes, 527 lwps, load averages: 0.01, 0.00, 0.00

## With proc_info removed from the effective and inheritable set
Total: 3 processes, 3 lwps, load averages: 0.00, 0.00, 0.00
Ejemplo 3-24  Modificación de un sistema para limitar los derechos disponibles a sus usuarios
En este ejemplo, el administrador crea un sistema que sólo es útil para administrar la red. El administrador elimina el perfil de derechos de usuario básico de Solaris y cualquier autorización del archivo policy.conf. El perfil de derechos de usuario de consola no se elimina. Las líneas afectadas en el archivo policy.conf resultante son las siguientes:
...
##AUTHS_GRANTED=
##AUTH_PROFS_GRANTED=
##PROFS_GRANTED=Basic Solaris User
CONSOLE_USER=Console User
...
Sólo un usuario que ha sido asignado de forma explícita autorizaciones, comandos o perfiles de derechos puede usar este sistema. Después de iniciar sesión, el usuario autorizado puede realizar tareas administrativas. Si el usuario autorizado se encuentra en la consola del sistema, el usuario tiene los derechos del usuario de consola.
Ejemplo 3-25  Restricción de un administrador a los derechos asignados explícitamente
    Puede restringir un rol o un usuario a un número limitado de acciones administrativas de dos formas.
  • Asigne el perfil de derechos de detención como el último perfil en la lista de perfiles del usuario.
    El perfil de derechos de detención es la forma más sencilla de crear un shell restringido. Las autorizaciones y los perfiles de derechos en el archivo policy.conf no están asignados al usuario o rol.
  • Puede modificar el archivo policy.conf en un sistema y requerir que el rol o el usuario utilicen ese sistema para tareas administrativas. Consulte Example 3–24.
El siguiente comando limita el rol auditrev a realizar sólo revisiones de auditoría.
# rolemod -P "Audit Review,Stop" auditrev
Debido a que el rol auditrev no tiene el perfil de derechos de usuario de consola, el auditor no puede cerrar el sistema. Debido a que este rol no tiene la autorización solaris.device.cdrw, el auditor no puede leer o escribir en la unidad de CD-ROM. Debido a que este rol no tiene el perfil de usuario de Solaris básico, no se pueden ejecutar comandos de ese perfil en este rol. Debido a que el perfil de derechos All (todo) no está asignado, el comando ls no se ejecutará. El rol utiliza el explorador de archivos para seleccionar los archivos de auditoría para revisar.
Ejemplo 3-26  Impedir que las aplicaciones seleccionadas reproduzcan procesos nuevos
En este ejemplo, el administrador crea un perfil de derechos para las aplicaciones que no requieren los subprocesos para el correcto funcionamiento. Para mayor comodidad, el administrador crea un directorio para almacenar estos ejecutables. Cuando se agregan nuevas aplicaciones que no necesitan subprocesos, los ejecutables se pueden agregar a este directorio. O bien, si el ejecutable es necesario para estar en un directorio específico, el administrador puede establecer un enlace a este desde /opt/local/noex/app-executable.
# profiles -p "Prevent App Subprocess"
profiles:Prevent App Subprocess> set desc="Keep apps from execing processes"
profiles:Prevent App Subprocess> add cmd=/opt/local/noex/mkmod
... Subprocess:mkmod> set limitprivs=all,!proc_exec
... Subprocess:mkmod> end
... Subprocess> add cmd=/opt/local/noex/gomap
... Subprocess:gomap> set limitprivs=all,!proc_exec
... Subprocess:gomap> end
... Subprocess> commit
... Subprocess> exit
Ejemplo 3-27  Impedir que los invitados reproduzcan subprocesos del editor
En este ejemplo, el administrador impide que los usuarios creen subshells de uno o más editores al eliminar el privilegio básico proc_exec del comando del editor.
  1.  El administrador crea un perfil de derechos que elimina proc_exec del conjunto límite de privilegios del editor de vim.
    # profiles -p -S ldap "Editor Restrictions"
    profiles:Editor Restrictions> set desc="Site Editor Restrictions"
    ... Restrictions> add cmd=/usr/bin/vim
    ... Restrictions:vim> set limitprivs=all,!proc_exec
    ... Restrictions:vim> end
    ... Restrictions> commit
    ... Restrictions> exit
  2. El administrador agrega otros editores populares para el perfil de derechos.
    # profiles -p "Editor Restrictions"
    profiles:Editor Restrictions> add cmd=/usr/bin/gedit
    ... Restrictions:gedit> set limitprivs=all,!proc_exec
    ... Restrictions:gedit> end
    ... Restrictions> add cmd=/usr/bin/gconf-editor
    ... Restrictions:gconf-editor> set limitprivs=all,!proc_exec
    ... Restrictions:gconf-editor> end
    ... Restrictions> add cmd=/usr/bin/ed
    ... Restrictions:ed> set limitprivs=all,!proc_exec
    ... Restrictions:ed> end
    ... Restrictions> add cmd=/usr/bin/ex
    ... Restrictions:ex> set limitprivs=all,!proc_exec
    ... Restrictions:ex> end
    ... Restrictions> add cmd=/usr/bin/edit
    ... Restrictions:edit> set limitprivs=all,!proc_exec
    ... Restrictions:edit> end
    ... Restrictions> commit
    ... Restrictions> exit
  3. El administrador revisa las entradas del perfil de derechos para comprobar que no tengan errores, como errores tipográficos, omisiones o repeticiones.
    # profiles -p "Editor Restrictions" info
    Found profile in files repository.
    name=Editor Restrictions
    desc=Site Editor Restrictions
    cmd=/usr/bin/vim
    limitprivs=all,!proc_exec
    ...
  4. El administrador asigna el perfil de derechos de restricciones del editor al usuario guest.
    # usermod -K profiles+="Editor Restrictions" guest
    Mediante +, el administrador agrega este perfil de derechos a los perfiles de derechos actuales de la cuenta.
  5. Para verificar que los privilegios del editor sean limitados, el administrador abre el editor en una ventana independiente y examina los privilegios en el proceso del editor.
    # ppriv -S $(pgrep vi)
    2805:   vi .bash_profile
    flags = PRIV_PFEXEC User is running a profile shell
            E: basic,!proc_info proc_info is removed from basic set
            I: basic,!proc_info
            P: basic,!proc_info
            L: all,!proc_exec proc_exec is removed from limit set
Ejemplo 3-28  Asignación del perfil de derechos de restricciones del editor a todos los usuarios
En este ejemplo, el administrador agrega el perfil de derechos de restricciones del editor para el archivo policy.conf. El administrador garantiza que este archivo se distribuye a todos los sistemas públicos en los que los invitados pueden iniciar sesión.
# cd /etc/security; cp policy.conf policy.conf.orig
# pfedit /etc/security/policy.conf
...
AUTHS_GRANTED=
AUTH_PROFS_GRANTED=
#PROFS_GRANTED=Basic Solaris User
PROFS_GRANTED=Editor Restrictions,Basic Solaris User

Cambio entre root como usuario o rol

De manera predeterminada,root es un rol en Oracle Solaris. Tiene la opción para cambiarlo a un usuario, volver a cambiarlo a un rol, o eliminarlo del uso.
Debe cambiar root a un usuario si utiliza Oracle Enterprise Manager o si está siguiendo el modelo de superusuario tradicional de administración en lugar del modelo de derechos. Para obtener información, consulte Cómo decidir qué modelo de derechos utilizar para la administración.
Si sigue el modelo de derechos, se puede cambiar root a un usuario al retirar un sistema que se ha eliminado de la red. En esta situación, iniciar sesión en el sistema como root simplifica la limpieza.

Notas -  Si administra de manera remota con el rol root, consulte Cómo administrar ZFS con shell seguro de forma remota de Gestión de acceso mediante shell seguro en Oracle Solaris 11.2 para obtener instrucciones de inicio de sesión remoto seguro.

En algunos sitios, root no es una cuenta legítima en los sistemas de producción. Para eliminar root de uso, consulte Example 5–13.

Cómo cambiar el rol root a un usuario

Este procedimiento es necesario en sistemas donderootdebe poder iniciar sesión directamente en el sistema.
Antes de empezar
Debe asumir el rol root.
  1. Elimine la asignación del rol root de los usuarios locales.
    Por ejemplo, elimine la asignación de rol de dos usuarios.
    % su -
    Password: xxxxxxxx
    # roles jdoe
    root
    # roles kdoe
    root
    # roles ldoe
    secadmin
    # usermod -R "" jdoe
    # usermod -R "" kdoe
    #
  2. Cambie el rol root a un usuario.
    # rolemod -K type=normal root
    Los usuarios que están actualmente en el rol root lo siguen estando. Otros usuarios que tienen acceso de usuario root pueden cambiar su a root o pueden iniciar sesión en el sistema como el usuario root.
  3. Verifique el cambio.
    Puede utilizar uno de los siguientes comandos.
    • Examine la entrada user_attr para root.
      # getent user_attr root
      root::::auths=solaris.*;profiles=All;audit_flags=lo\:no;lock_after_retries=no;
      min_label=admin_low;clearance=admin_high
      Si falta la palabra clave type en la salida o es igual a normal, la cuenta no es un rol.
    • Ver la salida del comando userattr.
      # userattr type root
      Si la salida está vacía o muestra normal, la cuenta no es un rol.
Ejemplo 5-12  Cambio de usuario root a rol root
En este ejemplo, el usuario root devuelve al usuario root a un rol.
Primero, el usuario root cambia la cuenta root a un rol y verifica el cambio.
# usermod -K type=role root
# getent user_attr root
root::::type=role...
A continuación, root asigna el rol root a un usuario local.
# usermod -R root jdoe
Ejemplo 5-13  Impedir que el rol root se utilice para mantener un sistema
En este ejemplo, la política de seguridad del sitio requiere que se evite que la cuenta root mantenga el sistema. El administrador ha creado y probado los roles que mantienen el sistema. Estos roles incluyen cada perfil de seguridad y el perfil de derechos de administrador del sistema. Se ha asignado a un usuario de confianza un rol que puede restaurar una copia de seguridad. Ningún rol puede cambiar los indicadores de auditoría para un usuario, un rol o un perfil de derechos o cambiar la contraseña de un rol.
Para evitar que la cuenta root se utilice para mantener el sistema, el administrador de seguridad elimina la asignación del rol root. Debido a que la cuenta root debe poder iniciar sesión en el sistema en modo de un solo usuario, la cuenta retiene una contraseña.
# usermod -K roles= jdoe
# userattr roles jdoe
Errores más frecuentes
En un entorno de escritorio, no puede iniciar sesión directamente como root cuando root es un rol. Un mensaje de diagnóstico indica que root es un rol en el sistema.
    Si no tiene una cuenta local que pueda asumir el rol root realizando los pasos siguientes:
  • Como root, inicie sesión en el sistema en modo de un solo usuario, cree una cuenta de usuario local y la contraseña.
  • Asigne el rol root a la cuenta nueva.
  • Inicie sesión como el usuario nuevo y asuma el rol root.

Comentarios