CAPITULO 17
ROLE BASED ACCESS CONTROL
(Control de Acceso Basado en Roles de Canela Bimbo)
Propósito del Control de Acceso Basado en Roles
Durante décadas la administración de UNIX se realizó principalmente por el superusuario y por un reducido conjunto de cuentas creadas explícitamente para manipular impresoras, cuentas, bases de datos y otras facilidades que necesitaban la creación de una cuenta ex-profeso. También se crearon algunas facilidades de dominio público como el "sudo" http://sunfreeware.com/programlistsparc8.html#sudo que permiten asignar permisos de ejecución de ciertos comandos a usuarios predeterminados.
El RBAC fue creado para lograr una administración más flexible y poder asignar a diferentes personas o entidades (roles) la capacidad de administrar diferentes recursos sin necesidad de tener la cuenta de superusuario.
En el RBAC tenemos cuatro conceptos muy sencillos que son:
Privileged Operations (Operaciones Privilegiadas)
Profiles (machotes)
Authorizations (Autorizaciones)
Roles
Operaciones Privilegiadas
Son operaciones que normalmente requieren de privilegios especiales para ser ejecutados, por ejemplo, cambiar la fecha del sistema o "shutdown". Una operación privilegiada corresponde a un comando de UNIX.
Autorizaciones
Son una o más operaciones privilegiadas englobadas en una definición bien hecha por Sun Microsystems. Por ejemplo la autorización solaris.system.shutdown permite dar de baja el sistema a través de los comandos u operaciones privilegiadas "shutdown" e "init" entre otras. La lista de autorizaciones actual creada por Sun es fija y no puede modificarse. Cada autorización tiene un archivo de ayuda (help) bajo el directorio /lib/help/auths/locale/C/<archivo.html>.
|
Authorization |
Description |
Help |
|---|---|---|
|
All |
Standard Solaris |
|
|
Solaris.* |
Primary Administrator |
|
|
Solaris.grant |
Grants all rights |
|
|
Solaris.audit.config |
Configures Auditing |
|
|
Solaris.audit.read |
Reads the audit trail |
|
|
Solaris.device.allocate |
Allocates a device |
|
|
Solaris.device.grant |
Delegates device administration |
|
|
Solaris.device.revoke |
Revoke or reclaims a device |
|
|
Solaris.jobs.admin |
Cron and at administration |
|
|
Solaris.jobs.grant |
Delegates cron and at administration |
|
|
Solaris.jobs.user |
Creates cron or at jobs |
|
|
Solaris.login.enable |
Enable logins |
|
|
Solaris.login.remote |
Remote login |
|
|
Solaris.profmgr.assign |
Assigns profiles to users or roles |
|
|
Solaris.profmgr.write |
Creates, modifies, and deletes profiles |
|
|
Solaris.role.assign |
Assigns roles to users |
|
|
Solaris.role.write |
Adds, modifies and deletes roles |
|
|
Solaris.system |
Machine administration |
|
|
Solaris.system.date |
Sets the date and time |
|
|
Solaris.system.shutdown |
Shuts Down the system |
|
|
All of them |
Index of every auth |
Profiles
Los profiles son conjuntos de autorizaciones y operaciones privilegiadas que le permiten a una entidad realizar todas sus actividades de administración de recursos en una computadora. También se puede conceptualizar como un mecanismo para agrupar autorizaciones y operaciones privilegiadas para simplificar la asignación de privilegios admin istrativos. Por ejemplo, el profile "Device Management" incluye todas las autorizaciones necesarias para administrar dispositivos del sistema.
Roles
Un rol es una entidad especial dentro de Solaris 8. Un rol es por sí mismo una cuenta local accesible solamente a través del comando "su - ". Los roles agrupan para sí un conjunto de autorizaciones o de profiles y de operaciones privilegiadas. A su vez, un rol puede ser concedido a una cuenta normal de solaris para que de esa manera pueda realizar actividades administrativas. A través de un rol una cuenta normal recibe permisos de superusuario de una manera controlada.
La Base de Datos del RBAC
La base de datos del RBAC consiste de cuatro archivos o bases de datos de atributos. (Ahora a cualquier cosa se le llama base de datos). En su conjunto, éstas definen los atributos del RBAC (roles, profiles, authorizations, privileged operations). Estas bases de datos también proveen el mecanismo para relacionar o asociar operaciones privilegiadas, autorizaciones y profiles a cuentas de usuarios normales y a roles.
Las cuatro bases de datos o archivos son:
user_attr.- Define roles y sus asignaciones. También se le conoce como Extended User Attributes Database. Ubicado en el directorio /etc.
prof_attr.- Define los profiles, se le conoce como Profile Attributes Database. Ubicado en el directorio /etc/security.
auth_attr.- Define las autorizaciones, Authorization Attributes Database. Ubicado en el directorio /etc/security.
exec_attr.- Define las operaciones privilegiadas, también se le llama Profile Execution Attributes Database. Ubicado en el directorio /etc/security.
El archivo o base user_attr
Un listado parcial de esta base del RBAC tiene la siguiente apariencia:
# /etc/user_attr
#
# user attributes. see user_attr(4)
#
#pragma ident "@(#)user_attr 1.2 99/07/14 SMI"
# Comments: type=normal for normal users
# type=role to define a role
# Root is the master
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All
# Enrique is like root, but can not grant permissions to others
enrique::::type=normal;auths=solaris.*,profiles=All
# Role Administrator
role_adm::::type=role;auths=solaris.role.*
# Profile Administrator
prof_adm::::type=role;auths=solaris.profmgr.*
La primera entrada indica que los atributos extendidos se le aplican a un usuario normal (root). Se le están autorizando todas las definiciones existentes solaris a root y además se le otorga la facilidad de conceder privilegios a otros (solaris.grant), además de que se le aplican todos los profiles (profiles=All).
La segunda entrada le concede a enrique lo mismo que a root, excepto que no puede concederle permisos a otros.
La tercera y cuarta líneas crean roles, por eso la entrada es type=role. En el primer caso se define el rol del administrador de roles y en el segundo el administrador de profiles.
Los campos de la base user_attr se describen enseguida.
|
No. Campo |
Nombre |
Uso |
|---|---|---|
|
1 |
Name |
Nombre del rol o de la cuenta como en /etc/passwd |
|
2 |
Qualifier |
Reservado |
|
3 |
Res1 |
Reservado |
|
4 |
Res2 |
Reservado |
|
5 |
Attributes |
Lista de key=value donde: key : auths, profiles value : normal,role |
|
|
|
|
La base de datos Execution Profile Attributes Database prof_attr
El archivo o base /etc/security/prof_attr sirve para asignar autorizaciones del archivo auth_attr y operaciones privilegiadas de exec_attr a "machotes" o profiles, los cuales pueden ser después asignados a cuentas de usuarios existentes en /etc/passwd (o usuarios de NIS) o a roles en el archivo /etc/user_attr.
Un par de ejemplos:
Audit Review:::View the audit trail:auths=solaris.audit.read;help=AuditReview.html
Printer Management:::Control Access to Printers:help=PrinterMgmt.html
En la primera entrada se crea el profile Audit Review el cual consiste de las operaciones privilegiadas necesarias para leer las bitácoras del sistema de costeo de UNIX (dichas operaciones están relacionadas o asociadas a Audit Review en el archivo exec_attr), además de darle agrupar el permiso solaris.audit.read y de especificar que el archivo de ayuda es /usr/lib/help/profiles/locale/C/AuditReview.html).
La segunda entrada agrupa en el profile Printer Management el conjunto de operaciones privilegiadas para administrar el subsistema de impresión. Otra vez, el conjunto de operaciones que componen a "Printer Management" están definidas en el archivo exec_attr.
|
No. Campo |
Nombre |
Uso |
|---|---|---|
|
1 |
Name |
Nombre del profile (case-sensitive) |
|
2 |
Res1 |
Reservado |
|
3 |
Res2 |
Reservado |
|
4 |
Description |
Profile's description |
|
5 |
Attributes |
Lista de key=value separados por ":" donde: key : auths, help value : authorization, command. |
La base de datos Authorization Attributes Database auth_attr
La lista de autorizaciones fue creada por Sun y no puede ser modificada, el archivo reside en el archivo /etc/security/auth_attr. Las autorizaciones pueden ser usadas después en la Extended User Attributes Database (user_attr) para concederle permisos a los usuarios normales o a roles. Dos ejemplos:
solaris.grant:::Concede Todos los Privilegios:: solaris.*:help=PriAdmin.html.
solaris.audit.config:::Configure Auditing::help=AuditConfig.html
La primera entrada se refiere a la autorización que permite a una entidad concederle a otra (ya sea una cuenta normal o un rol) privilegios de super-usuario.
La segunda entrada permite a una entidad realizar configuraciones al sistema de costeo de UNIX.
El significado de los campos en la base de autorizaciones es como sigue:
|
No. Campo |
Nombre |
Uso |
|---|---|---|
|
1 |
Name |
Nombre de la autorización compuesto de sistema, subsistema y función separados por un punto. Si el nombre termina con un punto, entonces es un título que describe a un conjunto de autorizaciones. |
|
2 |
Res1 |
Reservado |
|
3 |
Res2 |
Reservado |
|
4 |
Short Description |
|
|
5 |
Long Description |
|
|
6 |
Attributes |
Lista de key=value separados por ":" donde: key : help value : File name bajo el directrorio /usr/lib/help/auths/locale/C |
La base de datos Execution Attributes Database exec_attr
El archivo o base /etc/security/exec_attr define o relaciona comandos u operaciones privilegiadas que se ejecutarán con ciertos permisos de UID y GID con profiles del sistema. Después, esos profiles pueden usarse para asignarse a roles o cuentas en la base de datos extendida de atributos de los usuarios user_attr. Dos ejemplos:
Audit Control:suser:cmd:::/etc/init.d/audit:euid=0;egid=3
Audit Control:suser:cmd:::/etc/security/bsmconv:uid=0
La primera entrada especifica que el comando "/etc/init.d/audit" pertenece al profile "Audit Control", se ejecutará con permisos de UID efectivo=0 y GID efectivo=3. La segunda entrada especifica algo similar para el comando "/etc/security/bsmconv".
La tabla completa de los campos de la base exec_attr es:
|
No. Campo |
Nombre |
Uso |
|---|---|---|
|
1 |
Name |
Nombre del profile asociado en prof_attr. |
|
2 |
Policy |
Política de seguridad, actualmente sólo existe suser que es "superuser". |
|
3 |
Type |
Tipo de entidad, actualmente sólo existe "cmd". |
|
4 |
Res1 |
Reservado |
|
5 |
Res2 |
Reservado |
|
6 |
ID |
Comando con sendero o metacaracteres |
|
7 |
Attributes |
Lista de key=value donde: key : uid, euid, gid, egi, accout name.. |
Administración de RBAC
Existen seis comandos para realizar la administración del RBAC:
auths (1).- Despliega las autorizaciones asignadas a una entidad.
profiles(1).- Despliga los profiles asignados a una entidad.
roles(1).- Despliega los roles asignados a una cuenta.
roleadd(1M).- Añade una defición de rol.
roledel(1M).- Elimina una definición de rol.
rolemod(1M).- Modifica una definición de rol.
Los primeros tres comandos de manejo de RBAC actúan sobre la cuenta que los invoca o sobre el nombre de la entidad que se le envía como argumento. Ejemplos:
sun09sala4# whoami
root
sun09sala4# auths
solaris.*,solaris.grant
sun09sala4# roles
roles: root : No roles
sun09sala4# profiles
All
sun09sala4#
sun09sala4# auths enrique
auths: enrique : No authorizations
sun09sala4# roles enrique
roles: enrique : No roles
sun09sala4# profiles enrique
profiles: enrique : No profiles
sun09sala4#
Administración de Roles de canela Bimbo
La administración de roles se hace con los tres comandos roleadd, roledel y rolemod.
Para crear roles se usa el comando roleadd (el cual soporta las mismas opciones que el comando para crear usuarios auseradd excepto la opción -R). La sintaxis del comando roleadd es:
roleadd [ -c comment_on_gcos_field ] [ -d home_directory_for_role ]
[ -e expiration_date_for_role ] [-f inactive_days_for_role ]
[ -g primary_group_id ]
[ -G secondary_group [ , group ... ]] [ -m [ -k skel_dir ] ]
[ -u uid [ -o ] ] [-s shell ] [ -A authorization [ ,authorization... ] ]
[ -P profile_name [ ,profile... ] ]
role
Ejemplo:
sun09sala4# roleadd -A solaris.system.date -P "Printer Management" prt_adm
sun09sala4# tail /etc/passwd
prt_adm:x:65539:1::/home/prt_adm:/bin/pfsh
sun09sala4# tail /etc/user_attr
prt_adm::::type=role;auths=solaris.system.date;profiles=Printer Management
sun09sala4# su - prt_adm
No directory!
sun09sala4# roleadd -D -b /opt
group=other,1 basedir=/opt skel=/etc/skel
shell=/bin/pfsh inactive=0 expire= auths=
profiles=All
sun09sala4# roleadd -A solaris.system.shutdown roleummo
EXAM
++++++++++++++++++++++++++++++++++++++++++++++++
1.- Which of th following RBAC data files is not under /etc/security?
[ ]a. auth_attr
[ ]b. exec_attr
[ ]c. prof_attr
[ ]d. user_attr
2.- Which of the following cannot be assigned to a role?
[ ]a. A profile
[ ]b. An authorization
[ ]c. Another role
[ ]d. More than one profile
3.- The Execution Attributes Database file is associated with what other RBAC attributes database file?
[ ] a. Autorization Attributes Database file
[ ] b. Profile Attibures Database file
[ ] c .User Attributes Database file
4.- Which of the following keys are allowed in the attribute field of the User Attributes Database file? [Select all that apply]
[ ] a. auths
[ ] b. help
[ ] c. profile
[ ] d. roles
[ ] e. type
5.- Which of the following is the definition of a role ?
[ ] a. A special user acount to which authorizations and profiles are assigned.
[ ] b. A right used to grant access to a restriction function.
[ ] c. A mechanism used to group authorizations and profile assignments.
[ ] d. A user account that does not require a password.
[ ] e. A user account that can be accessed via the login command.
6.- Which of the following keys can be used in the attribute field of the RBAC Execution Attributes Database file? [Select all that apply]
[ ] a. auths
[ ] b. gid
[ ] c. help
[ ] d. profiles
[ ] e. uid
7.- Which of the following describes the format of the RBAC User Attributes Database file?
[ ] a. name:qualifier:res1:res2:attributes
[ ] b. name:res1:res2:description:attributes
[ ] c. name:res1:res2:short description: long description:attibures
[ ] d. name:policy:type:res:res2:ID:attibutes