Especificacion Formal del Modelo RBAC enel Calculo de Construcciones Inductivas

Tesina de grado presentada

por

Cristian Daniel Rosa

R-2371/0

al

Departamento de Ciencias de la Computacion

en cumplimiento parcial de los requerimientos

para la obtencion del grado de

Licenciado en Ciencias de la Computacion

Facultad de Ciencias Exactas, Ingenierıa y Agrimensura

Universidad Nacional de Rosario

Av. Pellegrini 250, Rosario, Republica Argentina

Octubre 2008

Supervisores

Carlos D. Luna Gustavo Betarte

Instituto de Computacion, Facultad de Ingenierıa

Universidad de la Republica

Julio Herrera y Reissig 565, Montevideo, Uruguay

A mis padrespor predicar con el ejemploy a mi futura esposa Erica

por la infinita comprension.

Resumen

Role Based Access Control (RBAC) es un enfoque para implementar polıticas de con-trol de acceso que esta basado en el concepto de rol. RBAC es considerado uno de losmodelos mas generales, debido a su neutralidad respecto a la polıtica de control de accesoy a su flexibilidad, lo que le permite poder simular enfoques alternativos como MAC yDAC.

Si bien los modelos e implementaciones RBAC existentes son relativamente similares enlos conceptos fundamentales, difieren significativamente en los detalles. Muchos modelosutilizan diferente terminologıa para describir los mismos conceptos.

Para dar solucion a estos problemas de alcance y terminologıa, el National Institute ofStandards and Technology (NIST), realizo una propuesta de estandarizacion definiendoun modelo de referencia. Si bien la especificacion esta desarrollada en un lenguaje deespecificacion formal, el estandar no incluye ningun estudio o analisis de la correccion ypropiedades del modelo.

El presente trabajo provee una especificacion formal certificada del modelo RBACdefinido por NIST utilizando el calculo de construcciones inductivas y COQ como asistentede pruebas.

La formalizacion en el CCI permitio realizar un analisis riguroso de la especificacionoriginal Z, posibilitando el estudio en profundidad de las alternativas planteadas comodecisiones de implementacion, y poniendo de manifiesto ambiguedades, imprecisiones yomisiones en los requerimientos funcionales de los comandos.

Contar con un modelo en el CCI permitio razonar de manera abstracta sobre su correc-cion. Utilizando COQ se verifico que la semantica de los comandos conserva invariante lavalidez del estado y se demostraron dos propiedades de seguridad fundamentales de todomodelo RBAC, la intransferibilidad de las sesiones y el correcto comportamiento de lajerarquıa de roles.

Agradecimientos

Es difıcil en tan poco espacio agradecer a todas las personas que han hecho posibleeste inolvidable momento de mi vida.

Primero a mi familia, a mi madre por su incansable dedicacion, a mi padre por indi-carme el camino con el ejemplo y a mi hermano por mostrarme la vida desde otro lado. Ami futura esposa Erica, que estuvo a mi lado alentandome desde el comienzo, y que supocomprender y soportar los sacrificios que conlleva esta ardua tarea.

No quiero dejar de mencionar a mis companeros de estudios por haber hecho de estosultimos anos la etapa mas linda de mi vida, y en especial a Jano, por haber compartidoinfinitas horas de delirios.

Voy a estar eternamente agradecido con los docentes de la carrera, en particular conGuido por la admirable tarea de transmitir la pasion de aprender.

Por ultimo y no menos importante, a mis directores de tesina Carlos y Gustavo, quesupieron comprender mis urgencias, idas y venidas.

Indice General ii

Indice general

1. Introduccion 1

2. El modelo RBAC 3

2.1. Descripcion general del modelo RBAC . . . . . . . . . . . . . . . . . . . . 3

2.2. Core RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3. Hierarchical RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. Especificacion Formal 7

3.1. Notacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2. Formalizacion de componentes . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1. Preludio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2. Jerarquıa de roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.3. Sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.4. El estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.5. Observadores del estado . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.6. Propiedades de validez del estado . . . . . . . . . . . . . . . . . . . 11

3.3. Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1. Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.2. Semantica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.3. Errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.4. Ejecucion de los comandos . . . . . . . . . . . . . . . . . . . . . . . 22

4. Verificacion 25

4.1. Invariancia de la validez del estado . . . . . . . . . . . . . . . . . . . . . . 25

4.2. Algunas propiedades interesantes . . . . . . . . . . . . . . . . . . . . . . . 32

5. Analisis de las decisiones de diseno 37

5.1. Operaciones sobre la jerarquıa de roles . . . . . . . . . . . . . . . . . . . . 37

iii

Indice General iv

5.1.1. Eliminacion de herencias indirectas . . . . . . . . . . . . . . . . . . 37

5.1.2. Conservacion de herencias indirectas . . . . . . . . . . . . . . . . . 38

5.1.3. Integridad entre el conjunto de roles y la jerarquıa . . . . . . . . . . 38

5.2. Manejo de sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1. Activacion explıcita de roles . . . . . . . . . . . . . . . . . . . . . . 39

5.2.2. Terminacion de las sesiones al eliminar un usuario . . . . . . . . . . 39

5.2.3. Terminacion de las sesiones al eliminar o desasignar un rol . . . . . 39

5.3. Algunas consideraciones adicionales . . . . . . . . . . . . . . . . . . . . . . 40

6. Conclusiones y trabajos futuros 43

Capıtulo 1

Introduccion

El concepto de control de acceso basado en roles comenzo con los sistemas multiusua-rios en la decada del 70 [13]. Las raıces del concepto de roles incluyen la utilizacion degrupos de usuarios en UNIX y otros sistemas operativos, y el agrupamiento por privilegiosen los sistemas de administracion de bases de datos [1, 14, 15].

Role Based Access Control (RBAC) es un enfoque para implementar polıticas de con-trol de acceso basado en el concepto de rol, que actualmente es considerado como uno delos modelos mas generales para hacerlo. Este ha demostrado su efectividad en una gran va-riedad de ambitos, desde organizaciones gubernamentales [7] hasta complejas aplicacionesweb. [8]

Previo al desarrollo de RBAC, Mandatory Access Control (MAC) y DiscretionaryAccess Control (DAC) eran considerados como los unicos modelos conocidos para imple-mentar polıticas de control de acceso. RBAC es considerado neutral respecto a la polıticade control de acceso y lo suficientemente poderoso como para poder simular MAC y DAC[11]. Sin embargo, investigaciones llevadas a cabo a finales de la decada pasada han de-mostrado que RBAC no es ni MAC ni DAC.[5]

La nocion central de RBAC es que los permisos son asociados con roles, y los usuariosson asignados a los roles apropiados, esto simplifica en gran medida la administracion delos permisos. Los roles son creados basandose en sus responsabilidades y autoridad en elcontexto de una organizacion. Los usuarios pueden ser facilmente reasignados de un rola otro, los roles pueden ser concedidos con nuevos permisos, y los permisos pueden serrevocados de los roles segun necesidad.

Un rol se considera una construccion semantica sobre la cual se formulan las polıticas decontrol de acceso. La coleccion de usuarios y permisos vinculadas por un rol es transitoria.El rol es mas estable porque las activades o funciones de una organizacion generalmentecambian con menor frecuencia.

Si bien los modelos e implementaciones RBAC existentes son relativamente similaresen los conceptos fundamentales, difieren significativamente en los detalles. Los puntos desimilaridad y diferencia no son obvios, porque muchos modelos utilizan diferente termi-nologıa para describir los mismos conceptos.

1

CAPITULO 1. INTRODUCCION

Para dar solucion a estos problemas de alcance y terminologıa, el National Institute ofStandards and Technology (NIST), realizo una propuesta de estandarizacion que unificalas implementaciones comerciales mas relevantes y los principales modelos de investiga-cion, definiendo un modelo de referencia a los implementadores e investigadores.[12]

La propuesta de estandar esta compuesta por un modelo de referencia, que define laterminologıa y los elementos basicos de RBAC, y una especificacion funcional en Z de losrequerimientos de los comandos, los cuales se utilizan para interactuar con el sistema. Sibien la especificacion funcional esta desarrollada en un lenguaje de especificacion formal,el estandar no incluye ningun estudio o analisis de la correccion y propiedades del modelo.

El presente trabajo tiene como objetivo obtener una especificacion formal certificadadel modelo definido por NIST [6], utilizando el calculo de construcciones inductivas [9][4] y el asistente de pruebas COQ [10] [3]. El mismo incluye una verificacion formal de lasemantica de los comandos, y el estudio de importantes propiedades de seguridad funda-mentales para la correccion del modelo. La eleccion de COQ como asistente de pruebasposibilita ademas la extraccion de una implementacion correcta por construccion de laespecificacion certificada.

Eventuales actualizaciones y material complementario a este trabajo, incluido el desa-rrollo completo en el asistente de pruebas Coq de la teorıa presentada, puede descargarsedesde http://www.fceia.unr.edu.ar/∼crosa.

El documento esta organizado en capıtulos, cada uno desarrolla un aspecto de laformalizacion utilizando lo definido en los anteriores.

El capıtulo 2 presenta el modelo RBAC propuesto por NIST, describiendo su organi-zacion modular y explicando la funcionalidad provista por cada componente.

El capıtulo 3 introduce la formalizacion realizada en el calculo de construcciones in-ductivas.

En el capıtulo 4 se desarrolla la verificacion del modelo. Primero se demuestra lainvariancia de la validez del estado respecto a la ejecucion de los comandos y luego seprueban dos propiedades de seguridad interesantes.

En el capıtulo 5 se analizan y justifican las decisiones de diseno tomadas al realizarla formalizacion del capıtulo 3, y se presentan algunas consideraciones adicionales delestandar.

El capıtulo 6 presenta las conclusiones obtenidas a lo largo del desarrollo de la tesina,y plantea posibles trabajos futuros para profundizar en el tema.

2

Capıtulo 2

El modelo RBAC

El presente capıtulo describe el modelo de referencia RBAC propuesto por NIST [6].Primero se introduce de manera general, presentando la organizacion modular del mismoy explicando la funcionalidad provista por cada componente. Posteriormente se presentanen mayor detalle las componentes formalizadas en el CCI (Capıtulo 3), definiendo unvocabulario comun para utilizar de manera consistente a lo largo del documento.

2.1. Descripcion general del modelo RBAC

El modelo de referencia NIST y su especificacion funcional esta divido en cuatro com-ponentes, donde cada uno de estos extiende o agrega funcionalidad al anterior: CoreRBAC, Hierarchical RBAC, Static Separation of Duty Relations and Dynamic Separationof Duty Relations.

Core RBAC comprende los aspectos esenciales de RBAC. El concepto basico de RBACes que los usuarios son asignados a roles, los permisos son asociados a roles y los usuariosadquieren permisos siendo miembros de roles. Las asignaciones usuario-rol y permiso-rolpueden ser muchos-a-muchos, por lo que un usuario puede pertenecer a muchos roles yun rol puede poseer muchos usuarios y de manera similar un permiso puede ser asociadoa muchos roles y un rol puede tener asociado muchos permisos. Core RBAC tambienincluye el concepto de sesion, que permite la activacion y desactivacion selectiva de roles,posibilitando que un usuario pueda ejercer los permisos de varios roles simultaneamente.

Hierarchical RBAC agrega los requerimientos para el soporte de jerarquıas de roles.Una jerarquıa es un orden parcial en el conjunto de roles que define una relacion de herenciaentre estos, donde los roles ascendentes adquieren los permisos de sus descendentes y losroles descendentes adquieren los usuarios pertenecientes a sus ascendentes.

Las relaciones de Static Separation of Duty (SSD) son utilizadas para hacer cumplirpolıticas de conflicto de intereses. Un conflicto de interes en un sistema basado en rolespuede darse cuando un usuario obtiene autorizacion para permisos asociados con rolesconflictivos, por ejemplo un usuario que tenga asignado un rol que le permita gestionaruna compra y un rol que le permita aprobar dicha gestion. Es deseable poder especificar

3

CAPITULO 2. EL MODELO RBAC

la polıtica de conflicto de intereses de manera centralizada y luego imponerla de manerauniforme en el sistema. Una manera de implementar dicha funcionalidad es haciendocumplir restricciones en las asignaciones usuario-rol.

Las relaciones de Dynamic Separation of Duty (DSD), al igual que las relaciones SSD,son utilizadas para limitar los permisos que un usuario puede ejercer simultaneamente.Sin embargo, estas difieren de las relaciones SSD en el contexto en que son impuestas.DSD limita la disponibilidad de permisos imponiendo restricciones en los roles que puedenser activados en las sesiones de los usuarios, en contraposicion con SSD que impone lasrestricciones en las asignaciones usuario-rol.

2.2. Core RBAC

Core RBAC define cinco conjuntos de elementos de datos basicos: usuarios (USERS),roles (ROLES), objetos (OBS), operaciones (OPS) y permisos (PRMS). Como se men-ciono en la seccion 2.1, RBAC esta fundamentalmente definido en termino de usuariosindividuales asignados a roles y los permisos asignados a roles. Se puede considerar alrol como la manera de describir relaciones muchos-a-muchos entre usuarios individuales ypermisos. La figura 2.1 esquematiza la relacion de los elementos que componen al modelo.

Por razones de simplicidad un usuario esta definido como un ser humano (pero elconcepto puede ser extendido a maquinas, redes, etc). Un rol es un trabajo o funcion enel contexto de una organizacion con alguna semantica asociada respecto a la autoridady responsabilidad conferida al usuario asignado al mismo. Un permiso es una aprobacionpara realizar una operacion sobre un objeto determinado. Una operacion es una accionque al ser invocada ejecuta una tarea para el usuario. Un objeto es una identidad quecontiene o recibe informacion.

El proposito de cualquier mecanismo de control de acceso es proteger los recursos delsistema. Cualquier incremento en la flexibilidad de controlar el acceso a estos recursostambien fortalece la aplicacion del principio del menor privilegio. Para que un usuariopueda ejercer los permisos para los cuales esta autorizado, es necesario que este activelos roles que tienen asociados estos permisos. Core RBAC define un conjunto de sesiones(SESSIONS) donde cada sesion es un mapeo entre el usuario y un subconjunto de rolesactivos, los cuales estan asignados al usuario. La utilizacion de sesiones facilita en granmedida la aplicacion de este principio, ya que aumenta la granularidad del control deacceso.

Las decisiones de acceso son tomadas por usuario y sesion, es decir un usuario esta au-torizado a realizar una determinada operacion sobre un determinado objeto si existe algunrol activo en dicha sesion que tenga asignado el permiso correspondiente.

Core RBAC especifica los requerimientos funcionales de los comandos utilizados parainteractuar con el sistema. Entre ellos se encuentran los comandos para administrar los ele-mentos basicos del modelo (creacion/eliminacion de usuarios, roles y permisos, asignacionde usuarios a roles y asignacion de permisos a roles), comandos para realizar decisiones deacceso, gestion de sesiones y comandos de revision para inspeccionar el estado del sistema.

4

2.3. HIERARCHICAL RBAC

Figura 2.1: Elementos del modelo RBAC

2.3. Hierarchical RBAC

Las jerarquıas de roles son una manera natural de estructurar los roles para reflejar laslıneas de autoridad y responsabilidad de una organizacion. El componente HierarchicalRBAC agrega el soporte para jerarquıas de roles, introduciendo una nueva relacion entrelos mismos. En la figura 2.1 esta relacion es la indicada en lıneas de puntos.

La herencia esta definida en termino de los permisos y usuarios, es decir si r1 ”heredade” r2 implica que todos los privilegios de r2 son tambien privilegios de r1, y a la inversa,todos los usuarios de r1 son tambien usuarios de r2.

El estandar contempla dos tipos de jerarquıas de roles, generales y limitadas. Las jerar-quıas de roles generales permiten que cualquier orden parcial arbitrario sobre el conjuntode roles represente a la jerarquıa. Estas incorporan el concepto de herencia multiple, queprovee importantes propiedades jerarquicas, por ejemplo permiten componer un rol demultiples roles subordinados, lo cual es una situacion caracterıstica de las organizacionesy las estructuras de negocios. Las jerarquıas de roles limitadas imponen restricciones en larelacion de orden, por ejemplo limitando la herencia a un unico descendiente inmediato,resultando en estructuras mas simples con forma de lattice o semi-lattice.

Hierarchical RBAC define los requerimientos funcionales de los comandos de gestione inspeccion de la jerarquıa, y ademas especifica los cambios en los requerimientos dealgunos comandos de Core RBAC que deben contemplar la presencia de la misma.

5

CAPITULO 2. EL MODELO RBAC

6

Capıtulo 3

Especificacion Formal

En el presente capıtulo se desarrolla la formalizacion en el CCI del modelo RBACdescripto en el capıtulo 2. La misma comprende los componentes del modelo Core RBACy Hierarchical RBAC, sin imponer restricciones en la forma de las jerarquıas de roles.

En primer lugar se introduce la notacion formal utilizada a lo largo de la especificacion,luego se presenta la formalizacion de los componentes basicos, organizada en seccionesque comprenden la composicion del estado y sus propiedades de validez, posteriormentese describe la sintaxis y semantica de los comandos, y finalmente el concepto de ejecucionde estos en el sistema.

3.1. Notacion

A lo largo de la presente tesina se utiliza la notacion propuesta en [2] que se describea continuacion. Para los conectivos logicos y de igualdad se utiliza la notacion estandar (∧,∨,→,¬,∃,∀ ).

Los predicados anonimos son introducidos mediante notacion lambda, por ejemplo(λx.x = 0) es un predicado que aplicado a n devuelve true si y solo si n es cero.

Los tipos records son introducidos de la siguiente manera:

Rdef= [[ field0 : A0, . . . , f ieldn : An ]]

lo cual genera un tipo inductivo no recursivo con un unico constructor, llamado BuildR

y n funciones de proyeccion fieldi : R→ Ai.

Se utiliza 〈a0, . . . , an〉 en lugar de BuildR a0 . . . an cuando el tipo R es evidente del con-texto. Las aplicaciones de las funciones de proyeccion estan abreviadas usando la notacionpunto (ej. fieldi r = r.fieldi).

La notacion para los conjuntos de tipo A es set A, donde set es un tipo inductivo quecodifica los conjuntos como listas cuyos constructores son cons :A → set A → set A ynil :set A, aunque puede suceder que se utilice :: en lugar de cons y [] en lugar de nil. Se

7

CAPITULO 3. ESPECIFICACION FORMAL

utiliza {a0, . . . , an}A para denotar el conjunto de elementos a0, . . . , an de tipo A. Para losoperadores de conjuntos se utiliza la notacion clasica (∪,∩,∈,⊆).

Para los constructores de tipos inductivos de la forma

I : t0 . . . tndef= Ci (a0 :k0) . . . (aj :kj) :I (b0 : t0) . . . (bn : tn) ∀ i, j, n ∈ N0

puede utilizarse la notacion

Ci

a0 . . . aj

I b0 . . . bn

donde las variables libres se consideran universalmente cuantificadas y sus tipos definidospor el contexto.

3.2. Formalizacion de componentes

3.2.1. Preludio

Primero se introducen algunos tipos utilizados en el resto de la especificacion.

Se llaman User, Role, Op, Ob y Session a los tipos de los usuarios, roles, operaciones,objetos y sesiones respectivamente, que son los elementos basicos del modelo RBAC.

Conceptualmente, un permiso describe la posibilidad de realizar una operacion sobreun objeto determinado, y se lo describe como el siguiente record

Permdef= [[ op0 :Op, ob0 :Ob ]]

donde el campo op0 es una operacion sobre el objeto del campo ob0.

Los permisos pueden estar asociados con uno o mas roles. Cada asociacion de unpermiso a un rol esta definida como el siguiente record

PAelemdef= [[ r1 :Role, p1 :Perm ]]

De manera analoga, los usuarios pueden estar asignados a uno o mas roles. Cada asignacionde un usuario a un rol se define como el record

UAelemdef= [[ u0 :User, r0 :Role ]]

3.2.2. Jerarquıa de roles

Los roles pueden heredar permisos de otros roles, formando una relacion jerarquicaentre estos. Formalmente la relacion de jerarquıa es un orden parcial sobre el conjunto deroles del sistema. Para simplificar la manipulacion de esta jerarquıa el estado del sistemaesta compuesto por dos relaciones: una de herencia inmediata o directa

(�) : Role→ Role→ Prop

8

3.2. FORMALIZACION DE COMPONENTES

y su respectiva clausura reflexo-transitiva definida inductivamente por los siguientes cons-tructores

(�) : Role→ Role→ Prop

rt reflx � x

rt stepx� y

x � yrt trans

x � y y � z

x � z

La jerarquıa de roles esta vinculada con los usuarios del sistema a traves de la relacionauthorizedUser. Un usuario esta autorizado para un rol si este esta asignado directamentea el o bien si esta asignado a un rol que hereda del mismo. Formalmente

authorizedUser (u :User) (r :Role)def= ∃ r′ :Role, role of user s r′ u ∧ r � r′

donde role of user es un observador del estado definido en la seccion 3.2.5.

3.2.3. Sesiones

Los permisos asignados a un usuario a traves de los roles, solo pueden ser utilizados siestos ultimos son activados. Cada usuario establece una sesion durante la cual activa unalgun subconjunto de los roles para los que esta autorizado.

Cada sesion es un mapeo entre un usuario y sus roles activos, un usuario puede tenermas de una sesion establecida de manera simultanea.

El estado de las sesiones del sistema esta dividido en dos partes. La primera es unconjunto de identificadores validos de sesion llamado Session introducido en la seccion3.2.1. La segunda parte es una funcion del identificador de sesion al usuario dueno de lamisma y sus roles activos, en terminos formales

se : Session→ SEelem

donde SEelem es

SEelemdef= [[ usr :User, rl :set Role ]]

siendo el campo usr el usuario dueno de la sesion y rl el conjunto de roles activos de lamisma.

9

CAPITULO 3. ESPECIFICACION FORMAL

3.2.4. El estado

El estado global del sistema se describe utilizando el siguiente tipo record

Statedef= [[ ob :set Ob,

op :set Op,

p :set Perm,

u :set User,

r :set Role,

ua :set UAelem,

pa :set PAelem,

(�) :Role→ Role→ Prop,

seID :set Session,

se :Session→ SEelem ]]

donde ob es el conjunto de objetos sobre el cual se pueden realizar operaciones, op es elconjunto de estas operaciones, p es el conjunto de permisos, u es el conjunto de los usuariostodos los usuarios validos, r es el conjunto de los roles, ua es el conjunto de asignacionesusuario-rol, pa es el conjunto de asignaciones permiso-rol, � es la relacion de herenciainmediata entre roles definida en 3.2.2, seID es el conjunto de los identificadores de sesionde la sesiones establecidas en el sistema, y se es una funcion entre el identificador de sesiony los roles activos y el dueno de la misma definida en 3.2.3.

3.2.5. Observadores del estado

Los observadores del estado son predicados que abstraen otros mas complejos mejo-rando la legibilidad y comprension de la especificacion.

El cuadro 3.1 enumera todos observadores definidos junto con sus signaturas. Se asumeque el estado s esta implıcito a lo largo de la presente seccion, en caso de tener que utilizarun observador haciendo explıcito el estado, este se indica como primer argumento.

Por razones de brevedad solo se describe la funcion de cada uno, mostrando a modode ejemplo las definiciones de los mas relevantes.

Los predicados isUser, isRole, isObj, isOper, isPerm, isPerm′ e isSession son utili-zados para simplificar las pruebas de pertenencia a los conjuntos que componen el estado,

por ejemplo isUser usrdef= usr ∈ s.u. La diferencia entre isPerm e isPerm′ es en el tipo

de argumento que toman, la primera recibe la operacion y el objeto por separado, y lasegunda el elemento de tipo Perm compuesto por la operacion y el objeto.

Las funciones user roles y role users computan la lista de roles asignados a un usuarioy la lista de usuarios asignados a un rol respectivamente.

Los predicados perm of role y perm of role′ prueban si un permiso esta asignado aun rol. Nuevamente la diferencia entre ambos es en la manera que toman sus argumentos,

10

3.2. FORMALIZACION DE COMPONENTES

isUser : User → PropisRole : Role→ PropisObj : Ob→ PropisOper : Op→ PropisPerm : Op→ Ob→ PropisPerm′ : Perm→ PropisSession :Session→ Propuser roles : User → set Rolerole users : Role→ set Userrole of user : Role→ User → Propperm of role : Op→ Ob→ Role→ Propperm of role′ : Perm→ Propuser sessions : User → set Sessionsession owner : User → Session→ Proprole of session : Role→ Session→ Prop

Cuadro 3.1: Observadores del estado

el primero toma la operacion y el objeto por separado, y el segundo toma un argumentode tipo Perm.

La funcion user sessions computa la lista de identificadores de sesion de las sesionescuyo dueno es el usuario indicado como argumento, session owner es un predicado querelaciona a los usuarios con sus sesiones, role of session es un predicado que relaciona losroles del sistema con las sesiones en las que estan activos y role of user es un predicadoque relaciona a los usuarios y sus roles asignados.

A continuacion se dan las definiciones de session owner, user roles y user sessions.

session owner u siddef= u = usr (s.se sid)

user roles usrdef= foldl (λ rl e . if e.u0 = usr then

e.r0 :: rl

else rl) s.ua [ ]

user sessions usrdef= filter (λ sid . if session owner usr sid then

true

else false) s.se

3.2.6. Propiedades de validez del estado

No todo elemento de tipo State es un estado valido, para ello es necesario que suscomponentes verifiquen ciertas relaciones. Para caracterizarlas formalmente se definen lassiguientes propiedades de validez del estado, para un elemento s : State.

11

CAPITULO 3. ESPECIFICACION FORMAL

“Toda sesion tiene un dueno y ademas es miembro del conjunto de usuarios.”

existsSessionOwner sdef= ∀ sid :Session,

isSession s sid→ ∃ u :User, isUser s u ∧ session owner s u sid

“El usuario dueno de una sesion es unico.”

uniqueSessionOner sdef= ∀ (sid :Session)(u1 u2 :User),

isSession s sid ∧ session owner s u1 sid ∧ session owner s u2 sid→ u1 = u2

“Los roles activos de una sesion son un subconjunto del conjunto de roles para los queel usuario dueno de la misma esta autorizado.”

activeSessionRoles sdef= ∀ (sid :Session)(u :User)(r :Role),

isSession s sid

∧ session owner s u sid∧ role of session s r sid→ authorized user s u r

“La relacion entre roles (�) que modela la jerarquıa de roles es un orden parcial.”

isOrder sdef= order (�)

donde order es un predicado que caracteriza a los ordenes parciales, definido como

order (�)def= ∀ x, x � x

∧ ∀ x y, x � y ∧ y � x→ x = y

∧ ∀ x y z, x � y ∧ y � z → x � z

“Los usuarios y roles relacionados a traves de la asignacion usuario-rol son un sub-conjunto de los conjuntos de usuarios y roles del sistema respectivamente.”

UA integrity sdef= ∀ (u :User)(r :Role),

role of user s r u→ isUser s u ∧ isRole s r

“Los objetos y operaciones relacionados a traves del conjunto de permisos, son unsubconjunto de los conjuntos de objetos y operaciones del sistema respectivamente.”

Perm integrity sdef= ∀ (op :Op)(ob :Ob),

isPerm′ s 〈op, ob〉 → isOper s op ∧ isObj s ob

“Los roles y permisos relacionados a traves de la asignacion rol-permiso son un sub-conjunto de los conjuntos de roles y permisos del sistema respectivamente.”

PA integrity sdef= ∀ (r :Role)(p :Perm),

perm of role s r p→ isRole s r ∧ isPerm s p

12

3.3. COMANDOS

“Los roles pertenecientes a la jerarquıa de roles son un subconjunto del conjunto deroles del sistema.”

H integrity sdef= ∀ r1 r2 :Role,

r1 � r2 → isRole s r1 ∧ isRole s r2

Finalmente se dice que un estado s es valido si cumple la siguiente propiedad

V alid sdef= existsSessionOwner s

∧ uniqueSessionOwner s∧ activeSessionRoles s∧ isOrder (�) s

∧ UA integrity s

∧ Perm integrity s

∧ PA integrity s

∧H integrity s

3.3. Comandos

La interaccion con el sistema se realiza mediante la ejecucion de comandos. Estosespecifican como evoluciona el estado y la respuesta del sistema. En esta seccion se presentasu sintaxis, semantica y ejecucion.

3.3.1. Sintaxis

La sintaxis y signatura de cada comando esta definida por el conjunto inductivo norecursivo Funcs

13

CAPITULO 3. ESPECIFICACION FORMAL

Funcsdef= AddUser : User → Funcs| DeleteUser : User → Funcs| AddRole : Role→ Funcs| DeleteRole : Role→ Funcs| AssignUser : User → Role→ Funcs| DeassignUser : User → Role→ Funcs| GrantPermission : Ob→ Op→ Role→ Funcs| RevokePermission : Op→ Ob→ Role→ Funcs| AddInheritance : Role→ Role→ Funcs| DeleteInheritance : Role→ Role→ Funcs| AddAscendant : Role→ Role→ Funcs| AddDescendant : Role→ Role→ Funcs| CreateSession : User → setRole→ Session→ Funcs| DeleteSession : User → Session→ Funcs| AddActiveRole : User → Session→ Role→ Funcs| DropActiveRole : User → Session→ Role→ Funcs| CheckAccess : Session→ Op→ Ob→ Funcs| AssignedUsers : Role→ Funcs| AssignedRoles : User → Funcs| AuthorizedUsers : Role→ Funcs| AuthorizedRoles : User → Funcs

Las posibles respuestas del sistema estan definidas mediante el tipo inductivo no re-cursivo answer:

answerdef= ok : answer| fail : answer| role list : listRole→ answer| user list : listUser → answer| error : ErrorCode→ answer

Todos los comandos, excepto los de revision, al tener exito en su ejecucion devuelvenok como respuesta.

3.3.2. Semantica

La semantica de los comandos esta especificada mediante pre y pos condiciones. Paracada comando, su precondicion es un predicado sobre el estado y su postcondicion es unpredicado que relaciona el estado anterior y el posterior a la ejecucion del mismo y larespuesta correspondiente.

A continuacion se procede a describir cada comando, detallando y formalizando susrespectivas pre y pos condiciones. Cabe aclarar que en la especificacion de las pos condi-ciones se han omitido todos los campos del estado que permanecen invariantes al ejecutarel comando en cuestion.

14

3.3. COMANDOS

AddUser usr crea un nuevo usuario en el sistema. Para que la operacion tenga exito elusuario no debe existir previamente en el sistema.

Pre s (AddUser usr)def=¬ (isUser s usr)

Pos s s′ answ (AddUser usr)def= s′.u = s.u ∪ {usr}∧ answ = ok

DeleteUser usr elimina un usuario del sistema. Para que el comando se ejecute exitosa-mente el usuario debe existir en el sistema.

Pre s (DeleteUser usr)def= isUser s usr

Al eliminar un usuario tambien son eliminadas todas las asignaciones de roles y lassesiones establecidas que este posee. Formalmente la poscondicion es

Pos s s′ answ (DeleteUser usr)def= s′.u = s.u \ {usr}∧ s′.ua = usr C s.ua

∧ s′.seID = s.seID \ (user sessions s usr)

∧ answ = ok

donde usr C s.(ua) es el conjunto de asignaciones usuario-rol del sistema con todaslas ocurrencias del usuario usr filtradas.

AddRole role crea un nuevo rol en el sistema. Para que el comando tenga exito, el rol nodebe existir previamente en el mismo.

Pre s (AddRole role)def= ¬ (isRole s role)

Pos s s′ answ (AddRole role)def= s′.r = s.r ∪ {role}∧ answ = ok

DeleteRole role elimina un rol del sistema. Es necesario que el rol exista para que elcomando tena exito.

Pre s (DeleteRole role)def= isRole s role

Las sesiones que tienen activo el rol a eliminar son terminadas, y todas las asigna-ciones de usuario, de permisos y las herencias donde interviene son eliminadas para

15

CAPITULO 3. ESPECIFICACION FORMAL

conservar la validez del estado.

Pos s s′ answ (DeleteRole role)def= s′.r = s.r \ {role}∧ s′.ua = s.uaB role

∧ s′.pa = roleC s.pa

∧ �′= λ x y . if x = role ∨ y = role then

false

else x� y

∧ s.seID = del unauth sessions s′ s

∧ answ = ok

donde del unauth sessions : State → State → set Session es una funcion quetermina las sesiones que poseen roles activos para los cuales en el nuevo estado s′

los usuarios duenos de las mismas ya no estan autorizados.

AssignUser usr role asigna el rol role al usuario usr. Para que el comando se ejecuteexitosamente tanto el usuario como el rol tienen que ser validos y no deben estarasignados previamente.

Pre s (AssignUser usr role)def= isUser s usr

∧ isRole s role

∧ ¬ (role of user s role usr)

Pos s s′ answ (AssignUser usr role)def= s′.ua = s.ua ∪ {〈usr, role〉}∧ answ = ok

DeassignUser usr role desasigna el usuario usr al rol role. Para que la operacion tengaexito tanto usr como role deben ser validos y deben estar previamente asignados.Las sesiones del usuario usr que posean activo al rol desasignado son terminadas.

Pre s (DeassignUser usr role)def= isUser s usr

∧ isRole s role

∧ role of user s role usr

Pos s s′ answ (DeassignUser usr role)def= s′.ua = s.ua \ {〈usr, role〉}∧ s′.seID = del unauth sessions s′ s

∧ answ = ok

GrantPermission obj op role asigna el permiso de realizar la operacion op sobre el obje-to obj al rol role. Para que el comando tenga exito 〈obj, op〉 tiene que ser un permisovalido y role debe ser un rol del sistema. Notar que se permite asignar un permiso

16

3.3. COMANDOS

a un rol aun si este ya estaba asignado.

Pre s (GrantPermission obj op role)def= isPerm′ s 〈op, obj〉∧ isRole s role

Pos s s′ answ (GrantPermission obj op role)def= s′.pa = s.pa ∪ {〈〈op, obj〉, role〉}∧ answ = ok

RevokePermision op obj role quita el permiso de realizar la operacion op sobre el objetoobj al rol role. Para que la operacion se ejecute exitosamente 〈obj, op〉 tiene que serun permiso valido, role debe ser un rol del sistema y el permiso debe estar asignadopreviamente.

Pre s (RevokePermision op obj role)def= isPerm′ s 〈op, obj〉∧ isRole s role

∧ perm of role′ s 〈op, obj〉 role

Pos s s′ answ (RevokePermision op obj role)def= s′.pa = s.pa \ {〈〈op, ob〉, role〉}∧ answ = ok

AddInheritance rasc rdesc agrega una nueva herencia inmediata rasc � rdesc, Para que elcomando tenga exito, se debe cumplir que tanto rasc como rdesc sean roles del sistema,que la herencia a agregar no exista con anterioridad y finalmente, es fundamentalque al agregar dicha herencia, la jerarquıa siga siendo un orden parcial. Para estodebe conservar la reflexividad, la transitividad y la antisimetrıa. La jerarquıa de rolesesta definida como la clausura reflexo-transitiva de la relacion de herencia inmediata,las primeras dos propiedades mencionadas anteriormente se cumplen trivialmente.Para conservar la antisimetrıa, basta con verificar que no vamos a generar ciclos alagregar la nueva herencia, formalmente esto es ¬ (rasc � rdesc)

Pre s (AddInheritance rasc rdesc)def= isRole s rasc

∧ isRole s rdesc

∧ ¬ (rdesc � rasc)

∧ ¬ (rasc � rdesc)

Pos s s′ answ (AddInheritance rasc rdesc)def= �′= λ x y . if x = rdesc ∧ y = rasc then

true

else x� y

∧ answ = ok

DeleteInheritance rasc rdesc elimina la relacion de herencia inmediata rasc � rdesc. Esnecesario para que el comando tenga exito que tanto rasc como rdesc sean roles

17

CAPITULO 3. ESPECIFICACION FORMAL

validos del sistema y que estos esten vinculados por la relacion �.

Pre s (DeleteInheritance rasc rdesc)def= isRole s rasc

∧ isRole s rdesc

∧ rdesc � rasc

Pos s s′ answ (DeleteInheritance rasc rdesc)def= �′= λ x y . if x = rdesc ∧ y = rasc then

false

else x� y

∧ answ = ok

AddAscendant rasc rdesc agrega la herencia inmediata rdesc � rasc a la jerarquıa de roles,creando el rol rasc en el sistema. Para que el comando tenga exito el rol rasc nodebe existir en el sistema, pero si el rol rdesc. Notar que como el estado s es valido,se cumple que rdesc � rasc no pertenece al sistema, de otro modo por H integrityvaldrıa isRole s rasc contradiciendo la primer precondicion.

Pre s (AddAscendant rasc rdesc)def=¬ (isRole s rasc)

∧ isRole s rdesc

Pos s s′ answ (AddAscendant rasc rdesc)def= s′.r = s.r ∪ {rasc}∧ �′= λ x y . if x = rdesc ∧ y = rasc then

true

else x� y

∧ answ = ok

AddDescendant rasc rdesc agrega la herencia inmediata rdesc � rasc a la jerarquıa de roles,creando el rol rdesc en el sistema. Para que el comando tenga exito el rol rdesc nodebe existir en el sistema, pero si el rol rasc. Notar que como el estado s es valido,se cumple que rdesc � rasc no pertenece al sistema, de otro modo por H integrityvaldrıa isRole s rasc contradiciendo la primer precondicion.

Pre s (AddDescendant rasc rdesc)def= isRole s rasc

∧ ¬ (isRole s rdesc)

Pos s s′ answ (AddDescendant rasc rdesc)def= s′.r = s.r ∪ {rdesc}∧ �′= λ x y . if x = rdesc ∧ y = rasc then

true

else x� y

∧ answ = ok

CreateSession usr ars sid Este comando establece una nueva sesion sid para el usua-rio usr activando por defecto todos los roles pertenecientes al conjunto ars. Para

18

3.3. COMANDOS

que la operacion tenga exito el usuario tiene que ser valido, la sesion no tiene queexistir previamente y todos los roles pertenecientes al conjunto ars tienen que estarautorizados para el usuario usr.

Pre s (CreateSession usr ars sid)def= isUser s usr

∧ ¬ (isSession s sid)

∧ ∀ r :Role, r ∈ ars→authorizedUser s usr sid

Pos s s′ answ (CreateSession usr ars sid)def= s′.seID = s.seID ∪ {sid}∧ s′.se = λ x . if x = sid then

〈usr, ars〉else s.se

∧ answ = ok

DeleteSession user sid termina la sesion sid del usuario user. Para que la operacion seejecute exitosamente, tanto el usuario como la sesion deben ser validas y ademas,este tiene que ser el dueno de la misma.

Pre s (DeleteSession user sid)def= isUser s user

∧ isSession s sid

∧ session owner s user sid

Pos s s′ answ (DeleteSession user sid)def= s′.seID = s.seID \ {sid}∧ answ = ok

AddActiveRole user sid role agrega el role role a la lista de roles activos de la sesion sidcuyo usuario dueno es user. El comando tiene exito si sus argumentos son elementosvalidos del sistema, si user es dueno de la sesion sid y si role esta autorizado parauser y no esta activo en dicha sesion.

Pre s (AddActiveRole user sid role)def= isUser s user

∧ isRole s role

∧ isSession s sid

∧ authorizedUser s user sid

∧ ¬ (role of session s role sid)

∧ session owner s user sid

Pos s s′ answ (AddActiveRole user sid role)def= s′.se =

λ x . if x = sid then

〈user, rl (s.se sid) ∪ {role}〉else s.se

∧ answ = ok

19

CAPITULO 3. ESPECIFICACION FORMAL

DropActiveRole user sid role elimina el rol role de la lista de roles activos de la sesionsid perteneciente al usuario user. El comando se ejecuta exitosamente si sus argu-mentos son elementos validos del sistema, si user es dueno de la sesion sid y si roleesta activo en dicha sesion.

Pre s (DropActiveRole user sid role)def= isUser s user

∧ isRole s role

∧ isSession s sid

∧ authorizedUser s user sid

∧ role of session s role sid

∧ session owner s user sid

Pos s s′ answ (DropActiveRole user sid role)def= s′.se =

λ x . if x = sid then

〈user, rl (s.se sid) \ {role}else s.se

∧ answ = ok

CheckAccess sid op obj realiza las decisiones de control de acceso a los recursos protegi-dos por el sistema. El comando devuelve la respuesta ok si la sesion sid posee algunrol activo que tenga asignado el permiso 〈op, obj〉, en caso contrario la respuesta esfail denegando la autorizacion.

Pre s (CheckAccess sid op obj)def= isOper s op

∧ isObj s obj

∧ isSession s sid

Pos s s′ answ (CheckAccess sid op obj)def= (∃ role :Role, isRole s role

∧ role of session s role sid

∧ perm of role s op obj role)

∧ answ = ok.

AssignedUsers role es un comando de revision que devuelve la lista de usuarios asignadosal rol role y no modifica el estado. Para que se ejecute correctamente, es necesarioque role sea un rol valido del sistema.

Pre s (AssignedUsers role)def= isRole s role

Pos s s′ answ (AssignedUsers role)def= answ = user list (s.uaB role)

AssignedRoles usr es un comando de revision que devuelve la lista de roles asignados alusuario usr y no modifica el estado. Para que se ejecute correctamente, es necesario

20

3.3. COMANDOS

que usr sea un usuario valido del sistema.

Pre s (AssignedRoles usr)def= isUser s usr

Pos s s′ answ (AssignedRoles usr)def= answ = role list (usr C s.ua)

AuthorizedUsers role es un comando de revision que devuelve la lista de usuarios auto-rizados para el role role. Para que se ejecute correctamente, es necesario que rolesea un rol valido del sistema.

Pre s (AuthorizedUsers role)def= isRole s role

Pos s s′ answ (AuthorizedUsers role)def= user list (filter (

λ x . if authorizedUser s x role then

true

else false) s.u)

AuthorizedRoles usr es un comando de revision que devuelve la lista de roles para loscuales usr esta autorizado. Para que se ejecute correctamente, es necesario que usrsea un usuario valido del sistema.

Pre s (AuthorizedRoles usr)def= isUser s usr

Pos s s′ answ (AuthorizedRoles usr)def= user list (filter (

λ x . if authorizedUser s usr x then

true

else false) s.r)

3.3.3. Errores

Cuando se intenta ejecutar un comando y alguna de las precondiciones del mismo noes valida, el sistema responde con un codigo de error. Los posibles codigos de error quedandefinidos mediante el siguiente tipo enumerado

ErrorCodedef= user not exists | user exists | role not exists | role exists| user role already assigned | user role not assigned| permission not assigned | session exists | session not exists| not user session | role already activated | role not active| not an operation | not an object | not a permission| inh already def | inh not def | desc parent asc

Para cada comando f se especifica el cuadro 3.2 que asocia el codigo de error y la condiciondel comando (la negacion de la precondicion Pf ) definiendo la relacion ErrorMsgf entreestados validos del sistema y mensajes de error.

21

CAPITULO 3. ESPECIFICACION FORMAL

3.3.4. Ejecucion de los comandos

La ejecucion de un comando f en un estado s produce un nuevo estado s′ y una res-puesta r donde la relacion entre el estado previo, el nuevo y la respuesta, esta determinadapor la relacion de postcondicion Posf .

exec : State→ Funcs→ answer → State→ Prop

exec prePre s f Pos s s′ ans f

exec s f ans s′

exec npre¬ (Pre s f) ∃ ec :ErrorCode, s = s′ ∧ ErrorMsg s f ec ∧ ans = error ec

exec s f ans s′

Si la precondicion Pre s f se cumple, entonces el estado resultante s′ y la respuestaans son las descriptas por la relacion exec. En cambio, si Pre s f no se cumple, entoncesel estado s no cambia y la respuesta del sistema es el mensaje de error determinado porla relacion ErrorMsg.

Cuadro 3.2: Cuadro de codigos de error

AddUser usrisUser s usr user exists

DeleteUser usr¬(isUser s usr) user not exists

AddRole roleisRole s role role exists

DeleteRole role¬(isRole s role) role exists

AssignUser usr role¬(isUser s usr) user not exists¬(isRole s role) role not existsrole of user s role usr user role already assigned

DeassignUser usr role¬(isUser s usr) user not exists¬(isRole s role) role not exists¬(role of user s role usr) user role not assigned

GrantPermission obj oper role¬(isPerm′ s 〈oper, obj〉) not a permission¬(isRole s role) role not exists

RevokePermission oper obj role¬(isPerm′ s 〈oper, obj〉) not a permission

22

3.3. COMANDOS

¬(isRole s role) role not exists¬(perm of role′ s 〈oper, obj〉 role) permission not assigned

AddInheritance rasc rdesc

¬(isRole s rasc) ∨ lnot(isRole s rdesc) role not existsrdesc � rasc inh already defrasc � rdesc desc parent asc

DeleteInheritance rasc rdesc

¬(isRole s rasc) ∨ lnot(isRole s rdesc) role not exists¬(rdesc � rasc) inh not def

AddAscendant rasc rdesc

isRolesrasc role exits¬(isRolesrdesc) role not exits

AddDescendant rasc rdesc

isRolesrdesc role exits¬(isRolesrasc) role not exits

CreateSession usr ars sessid¬(isUser s usr) user not exists∃ r ∈ ars,¬(role of user s r usr) user role not assignedisSession s sessid session exists

DeleteSession usr ars sessid¬(isUser s usr) user not exists¬(isSession s sessid) session not exists¬(session owner s usr sessid) not user session

AddActiveRole usr sessid role¬(isUser s usr) user not exists¬(isRole s role) role not exists¬(isSession s sessid) session not exists¬(role of user s role usr) user role not assigned¬(session owner s usr sessid) not user sessionrole of session s role sessid role already activated

DropActiveRole usr sessid role¬(isUser s usr) user not exists¬(isRole s role) role not exists¬(isSession s sessid) session not exists¬(session owner s usr sessid) not user session¬(role of session s role sessid) role not active

CheckAccess sessid oper obj¬(isOper s oper) not an operation¬(isObj s obj) not an object¬(isSession s sessid) session not exists

AssignedUsers role¬(isRole s role) role not exists

23

CAPITULO 3. ESPECIFICACION FORMAL

AssignedRoles usr¬(isUser s usr) user not exists

AuthorizedUsers role¬(isRole s role) role not exists

AuthorizedRoles usr¬(isUser s usr) user not exists

24

Capıtulo 4

Verificacion

En el capıtulo 3 se definio la formalizacion de RBAC en el CCI. En el presente capıtulose desarrolla la verificacion de la misma, organizada en dos secciones. Primero se demuestrala invariancia de la validez del estado respecto a la ejecucion de los comandos (seccion4.1), en otras palabras, se demuestra que la semantica dada a los comandos preservan laspropiedades de validez del estado. Luego, en la seccion 4.2 se prueban dos importantespropiedades de seguridad que debe verificar el modelo, estas son la intransferibilidad delas sesiones y el correcto comportamiento de la jerarquıa de roles.

Por razones de brevedad, en la primer parte solo se desarrollan las pruebas de laspropiedades mas relevantes y de manera informal. Todos los resultados fueron verificadosformalmente en la teorıa desarrollada en COQ.

A lo largo de este capıtulo se consideran definidos s s′ :State y ademas el estado s esconsiderado valido (V alid s).

4.1. Invariancia de la validez del estado

Para demostrar que el estado s′ especificado por la relacion de poscondicion de cada co-mando es valido, es necesario mostrar que valen cada una de las propiedades que componena V alid s′: existsSessionOwner s′, uniqueSessionOwner s′, isOrder s′, UA integrity s′,Perm integrity s′, PA integrity s′ y H integrity s′.

Las pruebas para los comandos que poseen poscondiciones que mantienen invarianteslos campos del estado relacionados con alguna de estas propiedades son omitidas ya quese verifican trivialmente.

Primero es necesario demostrar algunos resultados que simplifican el desarrollo poste-rior de las demostraciones de las invariantes.

El siguiente lema afirma que si los campos seID y se de dos estados s y s′ son equi-valentes, entonces tambien lo son los observadores del estado isSession y session owner.

25

CAPITULO 4. VERIFICACION

Lema 4.1.1 Sean s s′ : State. Si se cumple que s′.seID = s.seID y s′.se = s.se entoncesvale session owner s = session owner s′ y isSession s = isSession s′.

Demostracion. Expandiendo la definicion de session ower s′ e isSession se tiene

λ u x . u = usr (s.se x) y λ u . u ∈ s.seID

utilizando las hipotesis para reescribir s.se y s.seID por s′.se y s′.seID queda probado.�

El siguiente lema prueba que la poscondicion de AddUser especifica un estado s′ dondese cumple existsSessionOwner.

Lema 4.1.2 Sea usr :User. Si se cumplen Pre s (AddUser usr) yPos s s′ answ (AddUser usr) entonces en el estado s′ vale existSessionOwner.

Demostracion. De la poscondicion de AddUser se conoce que

s′.seID = s.seID y s′.se = s.se (4.1)

Expandiendo la definicion de existsSessionOwner s′ se tiene

∀sid :Session, isSession s′ sid→ (∃ u :User, isUser s′ u∧session owner s′ u sid) (4.2)

Por (4.1) se puede aplicar el Lema 4.1.1, y por lo tanto se pueden reescribir isSession s′

y session owner s′.

∀sid :Session, isSession s sid→ (∃ u :User, isUser s′ u∧ session owner s u sid) (4.3)

Como s es un estado valido se sabe que vale existsSessionOwner s. Utilizando lahipotesis de (4.3) isSession s sid, se tienen las siguientes nuevas hipotesis: u : User,isUser s y session owner s u sid.

Dando u como testigo del existencial en (4.3) el lado derecho de la conjuncion quedaprobado. Ahora falta probar

isUser s′ u. (4.4)

Se tiene como hipotesis que isUser s u y de la poscondicion de AddUser usr se conoceque s′.u = s.u∪ {usr}, luego es trivial concluir que u ∈ s′.u, que es igual por definicion aisUser s′u.

�

El siguiente lema prueba que la poscondicion de AddUser especifica un estado s′ dondese cumple uniqueSessionOwner.

Lema 4.1.3 Sea usr :User. Si se cumplen Pre s (AddUser usr) yPos s s′ answ (AddUser usr) entonces en el estado s′ vale uniqueSessionOwner.

26

4.1. INVARIANCIA DE LA VALIDEZ DEL ESTADO

Demostracion. De la poscondicion de AddUser se conoce que

s′.seID = s.seID y s′.se = s.se

por lo tanto se puede utilizar el Lema 4.1.1.

Expandiendo el objetivo de prueba se tiene

∀ (sid :Session)(u1 u2 :User),

isSession s′ sid

∧ session owner s′ u1 sid

∧ session owner s′ u2 sid→ u1 = u2

Reescribiendo isSession s′ y session owner s′ se obtienen las hipotesis isSession s sid,session owner s u1 sid y session owner s u2 sid. Como s es un estado valido entonces sesabe que se cumple uniqueSessionOwner s. Utilizando este hecho con las hipotesis recienintroducidas, se prueba que u1 = u2.

�

El siguiente lema prueba que la poscondicion de DeleteUser especifica un estado s′

donde se cumple existsSessionOwner.

Lema 4.1.4 Sea usr :User. Si se cumplen Pre s (DeleteUser usr) yPos s s′ answ (DeleteUser usr) entonces en el estado s′ vale existsSessionOwner.

Para simplificar la prueba de esta propiedad, primero se demuestran algunos resultadosintermedios importantes, que son validos considerando que se cumplen las hipotesis de lamismo.

El siguiente sub lema demuestra que si en el estado posterior a la ejecucion del comandoDeleteUser usr, sid es una sesion establecida del sistema, entonces esta tambien lo eraen el estado anterior, ya que DeleteUser no crea nuevas sesiones.

Sub Lema 4.1.4.1 Si se cumplen las hipotesis del Lema 4.1.4 y dado sid : Session secumple que isSession s′ sid entonces tambien vale isSession s sid.

Demostracion. De la poscondicion de DeleteUser usr se sabe que

s′.seID = s.seID \ (user sessions s usr)

expandiendo la hipotesis isSession s′ sid y reescribiendo s′.seID con la igualdad anteriorse obtiene

sid ∈ (s.seID \ (user sessions s usr))

Como sid pertenece a una diferencia entre conjuntos, entonces sid ∈ s.seID que es equi-valente por definicion a isSession s sid.

�

El siguiente lema demuestra que si un usuario es dueno de una sesion, entonces elidentificador de esta pertenece al conjunto de identificadores de sesion cuyo dueno es elusuario.

27

CAPITULO 4. VERIFICACION

Sub Lema 4.1.4.2 Si se cumplen las hipotesis del Lema 4.1.4 y dadosu : User y sid : Session se cumplen isSession s sid y session owner s u sid entoncessid ∈ (user sessions s u).

Demostracion. Para probar este resultado utilizaremos la siguiente propiedad de la funcionfilter:

∀ (x :A) (l :set A) (f :A→ Bool), x ∈ (filter f l)↔ x ∈ l ∧ f x = true. (4.5)

Expandiendo la definicion de user sessions s u se tiene el siguiente objetivo de prueba

sid ∈ filter (λ x . if (session owner s u sid) then true else false) s.seID

Aplicando (4.5) en sentido inverso, se reemplaza el objetivo de prueba por

sid ∈ s.seID ∧ (if (session owner s u sid) then true else false) = true

El lado izquierdo de la conjuncion es valido por hipotesis y en el lado derecho, comosession owner s u sid es valido por hipotesis, entonces el if se reduce a true, valiendo laigualdad trivialmente.

�

Ahora se procede a demostrar el lema principal.

Demostracion. Del sub lema 4.1.4.1 y la hipotesis isSession s′ sid , que se obtiene alexpandir el objetivo de prueba existsSessionOwner s′, se sabe que vale isSession s sid.Como s es un estado valido, entonces se cumple existsSessionOwner s. Expandiendo estehecho y utilizando la hipotesis isSession s sid se obtienen las siguientes nuevas hipotesis:u :User, isUser s u y session owner s u sid.

Como el objetivo de prueba es el siguiente existencial

∃ u :User, isUser s′ u ∧ session owner s′ u sid

basta con dar un testigo y probar que verifica las propiedades enunciadas. Se procede aprobar que el usuario u es dicho testigo, realizando un analisis por casos sobre el predicadousr = u.

Si se cumple usr = u, entonces por el sub lema (4.1.4.2) y por las hipotesis isSession s sidy session owner s u sid se concluye que sid ∈ (user sessions s u). Por otro lado se mues-tra como construir una hipotesis que contradice lo anterior, probando este caso.

De la poscondicion de DeleteUser usr se conoce que

s′.seID = s.seID \ (user sessions s usr)

es decir, en el nuevo estado se terminaron todas las sesiones del usuario eliminado. Ex-pandiendo la definicion de isSession s′sid y reescribiendo s′.seID en la misma, se obtienela siguiente hipotesis

sid ∈ (s.seID \ (user sessions s usr))

28

4.1. INVARIANCIA DE LA VALIDEZ DEL ESTADO

y como usr = u entonces reemplazando

sid ∈ (s.seID \ (user sessions s u))

Esta hipotesis dice que sid pertenece a una diferencia de conjuntos, por lo tanto

sid /∈ (user sessions s u)

produciendo la contradiccion en las hipotesis antes mencionada.

Para el caso en que usr 6= u se procede a probar el objetivo

isUser s′ u ∧ session owner s′ u sid

por partes, comenzando por el lado izquierdo.

De la poscondicion de DeleteUser usr se sabe que

s′.u = s.u \ {usr}

y expandiendo la hipotesis isUser s u se tiene

u ∈ s.u

Como usr 6= u entonces vale que u ∈ s′.u que es igual por definicion a isUser s′ uprobando la meta.

Para probar el lado derecho, se sabe de la poscondicion de DeleteUser usr que

s′.se = s.se

Expandiendo el objetivo de prueba y reescribiendo con la igualdad anterior se obtiene unanueva meta

u = usr (s.se sid)def= session owner s u sid

la cual es valida por hipotesis.�

El siguiente lema prueba que la poscondicion de AddRole role especifica un estado s′

donde se cumple activeSessionRoles.

Lema 4.1.5 Sea role :Role. Si se cumplen Pre s (AddRole role) yPos s s′ answ (AddRole role) entonces en el estado s′ vale activeSessionRoles.

Demostracion. Expandiendo el objetivo de prueba se tiene

∀ (sid :Session) (u :User) (r :Role), (4.6)

isSession s′ sid (4.7)

∧ session owner s′ u sid (4.8)

∧ role of session s′ r sid→ authorized user s′ u r (4.9)

29

CAPITULO 4. VERIFICACION

De la poscondicion de AddRolerole se sabe que valen

s′.seID = s.seID y s′.se = s.se

y se puede utilizar el Lema 4.1.1 para reescribir isSession s′ sid y session owner s′ u sid.Ademas notar que como no cambia ningun campo relacionado con las sesiones, entoncesrole of session s′ r sid→ role of session s r sid.

Como el estado s es un estado valido, se cumple activeSessionRoles s, utilizandoesta propiedad junto con las hipotesis obtenidas, se sabe que vale authorized user s u r.Expandiendo esta ultima

∃ r′ :Role, role of user s r′ u ∧ r � r′

se puede observar que como la poscondicion no modifica las asignaciones de usuario-rolni la jerarquıa de roles, entonces tambien vale authorized user s′ u r probando el lema.

�

Para poder simplificar las proximas demostraciones es necesario probar un resultadointermedio. El siguiente lema demuestra que dada una sesion valida en un estado posteriora la ejecucion de un comando, el cual termina todas las sesiones que tienen algun rol activoque ya no esta autorizado para los usuarios duenos de las mismas, entonces todos los rolesactivos en ella estan autorizados para el usuario dueno de la sesion.

Lema 4.1.6 Sean (sid : Session), (u : User) y (r : Role). Si se cumplen s′.se = s.se,s′.seID = delete unauthorized sessions s s′ y ademas isSession s′sid,session owner s′ u sid, role of session s′ r sid entonces vale authorized user s′ u r.

Demostracion. Aplicando el lema 4.1.1 por hipotesis se sabe que valen session owner s u sidy role of session s r sid. Reescribiendo s′.seID dentro de la definicion de isSession s′ sidy expandiendo la hipotesis delete unauthorized sessions s s′ se obtiene

sid ∈ filter (aux s s′) s.seID

y por la propiedad de filter 4.5, se concluye que valen

sid ∈ s.seID y aux s s′ sid = true

El lado izquierdo afirma que sid era una sesion valida en el estado s, es decir isSession s sid.En la hipotesis del lado derecho, se expande la definicion de aux s s′ sid

forallb (λ r . if authorized user s′ (usr (s.se sid)) r then

true

else false) (rl (s.se s sid)) = true

donde forallb es una funcion que toma como argumento una funcion f :A → bool y unconjunto l : set A y evalua a true si ∀a, a ∈ l → f a = true, en caso contrario evalua afalse.

30

4.1. INVARIANCIA DE LA VALIDEZ DEL ESTADO

Notar que por la hipotesis session owner s u sid, podemos reescribir usr (s.se sid)obteniendo

forallb (λr. if authorized user s′ u r then (4.10)

true

else false) (rl (s.se s sid)) = true

Analizando por casos authorized user s′ u r, si se cumple entonces el teorema valetrivialmente, en caso contrario en la hipotesis 4.10, la funcion forallb evalua a falseobteniendo como hipotesis false = true, lo cual es una contradiccion y por lo tantoqueda demostrado el lema.

�

El siguiente lema prueba que la poscondicion de DeleteRole role especifica un estados′ donde se cumple activeSessionRoles.

Lema 4.1.7 Sea role :Role. Si se cumplen Pre s (DeleteRole role) yPos s s′ answ (DeleteRole role) entonces en el estado s′ vale activeSessionRoles.

Demostracion. De la poscondicion de DeleteRole role se conoce que

s′.se = s.se y s′.seID = delete unauthorized sessions s s′ (4.11)

y expandiendo el objetivo de prueba se tiene

∀(sid :Session) (u :User) (r :Role),

isSession s′ sid

∧ session owner s′ u sid∧ role of session s′ r sid→ authorized user s′ u r

utilizando (4.11) y las hipotesis del objetivo de prueba se puede aplicar el lema 4.1.6probando el actual.

�

El siguiente lema prueba que la poscondicion de DeassignUser usr role especifica unestado s′ donde se cumple activeSessionRoles.

Lema 4.1.8 Sean usr :User y role :Role. Si se cumplen Pre s (DeassignUser usr role)y Pos s s′ answ (DeassignUser usr role) entonces en el estado s′ vale activeSessionRoles.

Demostracion. La prueba es analoga a la del lema 4.1.7 y se procede de la siguientemanera, de la poscondicion de DeassignUser usr role se conoce que

s′.se = s.se y s′.seID = delete unauthorized sessions s s′ (4.12)

31

CAPITULO 4. VERIFICACION

y expandiendo el objetivo de prueba se tiene

∀(sid :Session) (u :User) (r :Role),

isSession s′ sid

∧ session owner s′ u sid∧ role of session s′ r sid→ authorized user s′ u r

utilizando (4.12) y las hipotesis del objetivo de prueba se puede aplicar el lema 4.1.6demostrando el lema actual.

�

Finalmente, el siguiente teorema afirma que la semantica dada a los comandos man-tiene la validez del estado. Esto garantiza que los comandos no pueden hacer transicionaral sistema a un estado que no represente un estado de RBAC.

Teorema 4.1.1 Sean s :State y f :Func. Si se cumple que V alid s, Pre s f y Pos s s′ ok fentonces V alid s′.

Demostracion. La prueba procede realizando un analisis por casos de los comandos. Comose menciono al comienzo del capıtulo, se considera valida la invariancia de la validez delestado para aquellos comandos que poseen una poscondicion que hace la prueba relativa-mente simple o trivial. Para el resto de los comandos, la misma queda probada por loslemas demostrados en esta seccion.

�

4.2. Algunas propiedades interesantes

La invariancia de la validez del estado garantiza que al ejecutar cualquier comando enel sistema se obtiene un estado en el cual se cumple que todas las sesiones establecidasposeen un unico usuario valido dueno de las mismas. Es fundamental ademas demostrarque este usuario es el mismo que en el estado previo a la ejecucion del comando, siemprey cuando este no termine la sesion en cuestion.

El siguiente lema demuestra que dado un estado valido s, un usuario u y una sesion sid,si el usuario es dueno de la sesion en dicho estado y se ejecuta exitosamente un comandof , se obtiene un estado s′ en el cual u sigue siendo el dueno de la sesion sid.

Lema 4.2.1 Sean (u :User) (sid :Session) (f :Funcs). Si se cumple que isSession s sid,session owner s u sid, exec s f ok s′ y isSession s′sid, entonces se cumple quesession owner s′ u sid.

Como la ejecucion del comando es exitosa por hipotesis, entonces para cada comandof se sabe que valen Pre s f y Pos s s′ answ f .

La demostracion procede realizando un analisis por casos sobre los comandos f . Paratodos aquellos donde su poscondicion especifica que s′.se = s.se, es decir, la funcion que

32

4.2. ALGUNAS PROPIEDADES INTERESANTES

mapea identificadores de sesion a usuarios y roles activos no cambia, el lema se demuestratrivialmente por el Lema 4.1.1.

Se procede a desarrollar los casos restantes: CreateSession, AddActiveRole yDropActiveRole.

CreateSession u ars sid0 . De la poscondicion se sabe que

s′.seID = s.seID ∪ {sid0}s′.se = λ x . if x = sid0 then 〈u, ars〉 else s.se

por lo tanto si se expande el objetivo de prueba y se reescribe s′.se se tiene

u = usr (if sid = sid0 then 〈u, ars〉 else s.se sid)

Si sid = sid0, como la precondicion es valida, se sabe que ¬ (isSession s sid0), quepor la igualdad anterior es lo mismo que ¬ (isSession s sid), pero esto contradicela hipotesis del Lema isSession s sid y por lo tanto demuestra este caso.

Si sid 6= sid0, entonces el if se reduce a s.se quedando como objetivo de prueba

u = usr (s.se sid)

que es igual por definicion a session owner s sid y es valido por hipotesis.

AddActiveRole u sid0 role . De la poscondicion se sabe que

s′.se = λ x . if x = sid0 then

〈usr (s.se x), rl (s.se sid) ∪ {role}〉else s.se x

por lo tanto si se expande el objetivo de prueba y se reescribe s′.se se obtiene

u = usr (if sid = sid0 then

〈usr (s.se sid), rl (s.se sid) ∪ {role}〉else s.se sid)

Si sid = sid0, el if se reduce a la primer rama y usr proyecta la primer componentede la misma, obteniendo como objetivo de prueba

u = usr (s.se sid)

que es igual por definicion a session owner s u sid que es valido por hipotesis.

En cambio, si sid 6= sid0, el if se reduce a la segunda rama pero se obtiene el mismoobjetivo de prueba que en el caso anterior y procediendo de manera analoga quedademostrado el Lema para este comando.

33

CAPITULO 4. VERIFICACION

DropActiveRole u sid0 role . La poscondicion de este comando es similar a la del ante-rior, la diferencia reside en que este substrae el role role de la lista de roles activosde la sesion sid en lugar de agregarlo

s′.se = λ x . if x = sid0 then

〈usr (s.se x), rl (s.se sid) \ {role}〉else s.se x

Por lo tanto la demostracion del Lema para este comando es la misma que paraAddActiveRole.

Una propiedad fundamental que debe cumplir la formalizacion respecto a la jerarquıade roles, es que esta modele correctamente el concepto de herencia. El siguiente Lemaverifica la correccion del presente modelo, demostrando que no puede suceder que unusuario asignado a roles de mayor jerarquıa que otro, no este autorizado a para un rolcuando el segundo si lo esta.

Lema 4.2.2 Sean u1 u2 : User, r r2 : Role. Si ∀r1, role of user s r1 u1 → r1 � r2 yauthorized user s u2 r2 entonces ¬(authorized user s u1 r∧¬ authorized user s u2 r).

Demostracion. El objetivo de prueba es el siguiente

¬(authorized user s u1 r ∧ ¬ authorized user s u2 r)

Esto es equivalente a demostrar False asumiendo como hipotesis que authorized user s u1 ry authorized user s u2 r → False, por lo tanto si se muestra que vale authorized user s u2 rqueda probado el lema.

Como el usuario u1 esta autorizado para el rol r por la hipotesis authorized user s u1 r,se sabe que

∃ r1 :role, role of user s r1 u1 ∧ r � r1 (4.13)

y como ∀r1, role of user s r1 u1 → r1 � r2, entonces en particular vale para r1, por lotanto se puede concluir que

r1 � r2 (4.14)

Del lado derecho de la conjuncion en la hipotesis (4.13) y de (4.14) por transitividad secumple que

r � r2 (4.15)

Como el usuario u2 esta autorizado para r2 por la hipotesis authorized user s u2 r2entonces se tiene que

∃ r3 :role, role of user s r3 u2 ∧ r2 � r3 (4.16)

nuevamente del lado derecho de la conjuncion y de (4.15) vale por transitividad que

r � r3 (4.17)

34

4.2. ALGUNAS PROPIEDADES INTERESANTES

Expandiendo la definicion de authorized user s u2 r se obtiene

∃ r0 :role, role of user s r0 u2 ∧ r � r0

Si se utiliza r3 como elemento testigo del existencial, entonces role of user s r3 u2∧r � r3es valido por las hipotesis (4.16) y (4.17), el Lema queda demostrado.

�

35

CAPITULO 4. VERIFICACION

36

Capıtulo 5

Analisis de las decisiones de diseno

El modelo RBAC propuesto por NIST introducido en el capıtulo 2 propone en repetidasocasiones a lo largo de su especificacion, decisiones de diseno libradas a la implementacion.

En en el presente capıtulo se desarrollan en detalle las decisiones tomadas durante laformalizacion en el calculo de construcciones inductivas expuesto en el capıtulo 3, anali-zando las alternativas y sus desventajas respecto a las elegidas. Estas se pueden organizaren dos grandes secciones, las relacionadas con la jerarquıa de roles y las relacionadas conel manejo de sesiones.

Al final del capıtulo se presentan algunas consideraciones adicionales sobre el modelopropuesto por NIST, donde se analizan posibles problemas en la especificacion de losrequerimientos funcionales.

5.1. Operaciones sobre la jerarquıa de roles

La jerarquıa de roles esta definida como un orden parcial � en el conjunto de los roles.Resulta natural utilizar dicha construccion ya que la transitividad y antisimetrıa modelande manera precisa lo que uno espera de una relacion de herencia; no es necesario hacerexplıcita cada una de las relaciones.

El estandar propuesto por NIST deja como decision de diseno el comportamiento delas operaciones relacionadas al manejo de esta jerarquıa que se proceden a analizar.

5.1.1. Eliminacion de herencias indirectas

Es decision de la implementacion permitir o no la eliminacion de herencias indirectas(o transitivas). La figura 5.1 define una jerarquıa de roles donde C � B, D � B y B � Aestan directamente relacionados, y C � A y D � A indirectamente. Si se permitieseeliminar por ej. C � A se podrıa proceder de dos formas.

37

CAPITULO 5. ANALISIS DE LAS DECISIONES DE DISENO

Figura 5.1: jerarquıa de ejemplo

1. Si se eliminara C � A se tendrıa que

C � BB � A

}6⇒ C � A

∴ � no es transitiva⇒ no es orden parcial, lo cual destruye las propiedades deseablesde la jerarquıa.

2. Para preservar el orden parcial se podrıa eliminar C � B o B � A lo cual serıa unaeleccion no determinista y podrıa afectar a roles intermedios produciendo resultadosimpredecibles.

Por lo tanto en el modelo solo se permite eliminar relaciones de herencia inmediatas.

5.1.2. Conservacion de herencias indirectas

El estandar deja como decision de implementacion la posibilidad de eliminar una he-rencia inmediata conservando las indirectas. La unica forma de implementar esta funcio-nalidad, sin hacer que la relacion � deje de ser un orden parcial, es haciendo que todas lasrelaciones sean inmediatas. Cada vez que se agrega una herencia, explicitamente se debenagregar todas las transitivas. Esto sub-utiliza el hecho de que � es un orden parcial yaque se no se hace uso de la transitividad.

En el presente modelo las herencias indirectas relacionadas a traves de un rol eliminadono son conservadas.

5.1.3. Integridad entre el conjunto de roles y la jerarquıa

El estandar especifica que al eliminar un rol, la jerarquıa de roles no se modifica.Esto se puede transformar en una potencial falla de seguridad, ya que el sistema puedetransicionar a un estado invalido en el que no se cumple H integrity (ver 3.2.6).

Si bien al intentar activar un rol eliminado r, en un estado invalido s, falla la precon-dicion Pre s (AddActiveRole r), si se pueden activar todos los roles heredados a travesde este que aun pertenecen al conjunto de roles a pesar de que el rol vinculante ya no

38

5.2. MANEJO DE SESIONES

exista. Peor aun, si este rol es nuevamente creado en el sistema, estarıa relacionado con susantiguos herederos, agregando un comportamiento no especificado al comando AddRole.

En el modelo desarrollado se considero como un error de la especificacion del estandary se opto por eliminar todas las relaciones de la jerarquıa donde el rol eliminado estainvolucrado.

5.2. Manejo de sesiones

5.2.1. Activacion explıcita de roles

El estandar deja a decision de la implementacion como proceder al activar un rol o alcrear una sesion cuando se cuenta con una jerarquıa de roles.

El sistema puede activar solo el rol (o los roles) agregados o bien puede ademas activarautomaticamente todos los roles heredados a traves de estos. El presente modelo intentapreservar el principio del menor privilegio, por lo que toda activacion de los roles debe serexplıcita, reduciendo de esta manera el numero de roles activos en todo momento. Otraventaja de esta forma de proceder es que minimiza el numero de sesiones terminadas aldesasignar o al eliminar un rol. (ver 5.2.3).

5.2.2. Terminacion de las sesiones al eliminar un usuario

Es decision de diseno que sucede con las sesiones de los usuarios eliminados. El sistemapuede terminarlas inmediatamente o esperar a que terminen normalmente. Si las sesio-nes no se terminan el sistema evolucionarıa a un estado invalido donde no se cumplirıaexistsSessionOwner (ver 3.2.6).

Posteriormente, si se crea nuevamente el mismo usuario y sus antiguas sesiones nocaducaron, este tendrıa sesiones con roles activos para los cuales tal vez ya no este au-torizado, lo cual es una potencial falla de seguridad. Por lo tanto el modelo desarrolladotermina de manera inmediata todas las sesiones del usuario eliminado.

5.2.3. Terminacion de las sesiones al eliminar o desasignar unrol

Al igual que en 5.2.2 es decision de la implementacion como proceder con las sesionesque tienen activo un rol eliminado/desasignado. Se puede esperar hasta que terminennormalmente, se puede eliminar el rol de la lista de roles activos de la(s) sesion(es) o biense puede terminar inmediatamente la(s) sesion(es). En el primer caso, el estado luego deeliminar/desasignar un rol es invalido ya que no verifica la propiedad activeSessionRoles(ver 3.2.6). Esto debilita el poder del administrador del sistema ya que posee menorcontrol sobre las sesiones. En el segundo caso, si se elimina el rol de la lista de rolesactivos, puede suceder que siendo el unico rol de la sesion esta quede sin roles activos,

39

CAPITULO 5. ANALISIS DE LAS DECISIONES DE DISENO

lo cual no agrega funcionalidad pero si complejidad. Por lo tanto se decidio terminar lassesiones involucradas inmediatamente.

5.3. Algunas consideraciones adicionales

El estandar propuesto por NIST persigue como fin definir un modelo RBAC de refe-rencia que unifique las diferentes implementaciones comerciales y de investigacion. Esteutiliza el lenguaje de especificacion Z para formalizar los requisitos funcionales de lasoperaciones administrativas, de las consultas y del manejo de sesiones a nivel de sistema.

Sin embargo la propuesta de estandar no incluye ningun tipo de verificacion formal dela especificacion. El modelo RBAC desarrollado en el presente trabajo, basado en el calculode construcciones inductivas, ademas de realizar un estudio formal de las propiedades delmodelo, puso de manifiesto ciertos aspectos del mismo a considerar en esta seccion.

Los requerimientos funcionales del modelo describen la semantica de los comandos demanera parcial, es decir solo especifican el comportamiento del sistema cuando se cumplenlas precondiciones de los mismos. En el calculo de construcciones inductivas todas lasfunciones describen computos que terminan, o en otros terminos, son totales. Por lo tantofue necesario completar la especificacion, indicando que sucede cuando las precondicionesno se cumplen. Para ello se definieron codigos de error y una relacion que los vincula conel estado del sistema.

En la seccion “A.2 Requirements for Hierarchical RBAC” de la especificacion funcionalse encontraron algunas imprecisiones en la formalizacion de los comandosAddInheritance,DeleteInheritance, AddAscendant y DeleteInheritance que se proceden a describir.

La descripcion de los requerimientos funcionales de AddInheritance dice lo siguiente:

“...This command establishes a new immediate inheritance relationship rasc � rdesc

between existing roles rasc, rdesc...”

y los requerimientos funcionales estan especificados por el siguiente esquema Z

AddInheritance(r asc, r desc : NAME) C

r asc ∈ ROLES; r desc ∈ ROLES;¬(r asc� r desc);¬(r desc ≥ r asc)

≥′=≥ ∪{r, q : ROLES | r ≥ r asc ∧ r desc ≥ q • r 7→ q}B

donde � es la relacion de herencia inmediata y ≥ el orden parcial que se obtiene comola clausura reflexo-transitiva de �.

Claramente se observa que la poscondicion del esquema no actualiza la relacion�, porlo que la especificacion formal no coincide con la descripcion que acompana al esquema.

Lo mismo sucede en DeleteInheritance, esta es la descripcion de los requerimientos:

“...This command deletes an existing immediate inheritance relationship rasc � rdesc ...the new inheritance relation is computed as the reflexive-transitive closure of the immediateinheritance relation resulting after deleting the relationship rasc � rdesc. In this definition,implied relationships are preserved after deletion...”

40

5.3. ALGUNAS CONSIDERACIONES ADICIONALES

y su especificacion funcional esta dada por el siguiente esquema:

DeleteInheritance(r asc, r desc : NAME) C (5.1)

r asc ∈ ROLES; r desc ∈ ROLES; r asc� r desc

≥′= (� \{r asc 7→ r desc})∗ B

Nuevamente la poscondicion no especifica que sucede con la relacion �.

En la descripcion de este ultimo comando, aclara que las relaciones implıcitas (o tran-sitivas) son preservadas luego de la eliminacion de una relacion inmediata, pero el reque-rimiento especificado en el esquema (5.1) no lo hace. Para ver esto, supongamos que secuenta con las siguientes relaciones

� = {A 7→ r asc, r asc 7→ r desc, r desc 7→ B}≥ = � ∪ {A 7→ r desc, A 7→ B}

si se ejecuta el comando DeleteUser r asc r desc segun lo especificado en (5.1) se tiene

≥′= (� \{r asc 7→ r desc})∗

= ({A 7→ r asc, r desc 7→ B})∗

= {A 7→ r asc, r desc 7→ B}

En la nueva relacion ≥ se perdieron las herencias implıcitas.

Puede considerarse que la relacion� esta definida en terminos de ≥, pero en este casose pierde la capacidad de diferenciar si una herencia es inmediata o indirecta y ademas elesquema de DeleteInheritance deberıa simplificarse a

DeleteInheritance(r asc, r desc : NAME) C

r asc ∈ ROLES; r desc ∈ ROLES; r asc� r desc

≥′=≥ \{r asc 7→ r desc} B

En los esquemas que especifican los requerimientos de los comandos AddAscendant yAddDescendant se encontro una contradiccion en las precondiciones.

AddAscendant(r asc, r desc : NAME) C

AddRole(r asc)

AddInheritance(r asc, r desc) B

AddDescendant(r asc, r desc : NAME) C

AddRole(r desc)

AddInheritance(r asc, r desc) B

41

CAPITULO 5. ANALISIS DE LAS DECISIONES DE DISENO

Si expandimos los esquemas incluıdos se obtienen los siguientes

AddAscendant(r asc, r desc : NAME) C

r asc /∈ ROLES;

r asc ∈ ROLES; . . . B

AddDescendant(r asc, r desc : NAME) C

r desc /∈ ROLES;

r desc ∈ ROLES; . . . B

Estos esquemas contienen una contradiccion en las precondiciones y por lo tanto nuncapueden ser satisfechas. La formalizacion en el calculo de construcciones inductivas asumeque la semantica que se deseo dar a estos comandos es la equivalente a la secuenciacionde los comandos AddRole y AddInheritance.

42

Capıtulo 6

Conclusiones y trabajos futuros

La formalizacion en el CCI permitio realizar un analisis riguroso de la especificacionpropuesta por NIST. En particular, posibilito el estudio en profundidad de las alternati-vas planteadas como decisiones de implementacion. En este sentido se mostro que paraadministrar la jerarquıa de roles, cualquier intento de manipular las herencias indirectas(transitivas) de manera explıcita, implica en algunos casos la perdida de la propiedad deorden parcial de la relacion que modela la jerarquıa y en otros la sub-utilizacion de latransitividad del orden.

Tambien se pusieron de manifiesto ambiguedades, imprecisiones y omisiones en losrequerimientos funcionales de los comandos, por ejemplo en la especificacion del comandoDeleteRole, se omite por completo la presencia de una jerarquıa de roles posibilitandotransicionar a un estado invalido, donde existen relaciones de herencia entre roles que nopertenecen al conjunto de roles del sistema.

Contar con un modelo en el CCI permitio razonar de manera abstracta sobre sucorreccion. Por un lado se verifico que la semantica de los comandos conserva invariantela validez del estado, lo cual garantiza que el sistema no puede transicionar a un estadoque no represente un posible estado RBAC. Por el otro se demostro que gracias a estainvariancia de la validez del estado, valen dos propiedades de seguridad fundamentales detodo modelo RBAC, la intransferibilidad de las sesiones y el correcto comportamiento dela jerarquıa de roles.

La utilizacion del asistente de pruebas COQ permitio ademas obtener una especifica-cion certificada y posibilita, como trabajo futuro, la extraccion de un prototipo correctopor construccion que sirva como implementacion de referencia para desarrolladores e in-vestigadores.

Como trabajo futuro se propone una extension a la formalizacion en el CCI, que permi-ta razonar sobre secuencias de estados, posibilitando el estudio de propiedades temporales.

43

CAPITULO 6. CONCLUSIONES Y TRABAJOS FUTUROS

44

Bibliografıa

[1] R. W. Baldwin. Naming and grouping privileges to simplify security management inlarge databases. In IEEE Symposium on Security and Privacy, pages 116–132, 1990.

[2] S. Z. Beguelin. Especificacion formal del modelo de seguridad de MIDP 2.0 en elCalculo de Construcciones Inductivas. Master’s thesis, Universidad Nacional de Ro-sario, May 2006.

[3] Y. Bertot and P. Casteran. Interactive theorem proving and program development.coqart: The calculus of inductive constructions, 2004.

[4] T. Coquand and G. P. Huet. The calculus of constructions. Inf. Comput., 76(2/3):95–120, 1988.

[5] D. Ferraiolo and R. Kuhn. Role-based access controls. In In Proceedings of 15thNIST-NCSC National Computer Security Conference, pages 554–563, 1992.

[6] D. F. Ferraiolo, R. Sandhu, D. R. Kuhn, and R. Chandramouli. Vdg incorporatedand, 2001.

[7] J. Joshi, A. Ghafoor, W. G. Aref, and E. H. Spafford. Digital government securityinfrastructure design challenges. Computer, 34(2):66–72, 2001.

[8] J. B. D. Joshi, W. G. Aref, A. Ghafoor, and E. H. Spafford. Security models forweb-based applications. Commun. ACM, 44(2):38–44, 2001.

[9] P. Martin-Lof and G. Mints, editors. COLOG-88, International Conference on Com-puter Logic, Tallinn, USSR, December 1988, Proceedings, volume 417 of Lecture Notesin Computer Science. Springer, 1990.

[10] The Coq development team. The Coq proof assistant reference manual. LogiCalProject, 2006. Version 8.1.

[11] S. Osborn, R. Sandhu, N. R. S, Q. Munawer, and Q. Munawer. Con guring role-basedaccess control to enforce mandatory and discretionary access control policies. ACMTransactions on Information and System Security, 3, 2000.

[12] R. Sandhu, D. Ferraiolo, and R. Kuhn. The nist model for role-based access control:Towards a unified standard. In In Proceedings of the fifth ACM workshop on Role-based access control, pages 47–63. ACM Press, 2000.

45

BIBLIOGRAFIA

[13] R. S. Sandhu, E. J. C. K, H. L. F. K, and C. E. Y. K. Role-based access controlmodels yz, 1996.

[14] D. J. Thomsen. Role-based application design and enforcement. Database Security,IV: Status and Prospects, 1990.

[15] T. C. Ting, S. A. Demurjian, and M.-Y. Hu. Requirements, capabilities, and functio-nalities of user-role based security for an object-oriented design model. In Results ofthe IFIP WG 11.3 Workshop on Database Security V, pages 275–296, Amsterdam,The Netherlands, The Netherlands, 1992. North-Holland Publishing Co.

46