Introduccin

En este trabajo se muestra una descripcin del modelo de seguridad informtico

propuesto por Michael Harrison, Walter Ruzzo y Jeffrey Ullman en 1976, conocido
como el Modelo HRU. Se analiza el problema de filtracin de acceso en la matriz de
control de acceso ACM y garanta de confidencialidad, adems de comentar las ventajas
y desventajas del modelo. Se hace un anlisis de los estados no predecibles.
En gran medida, el xito o fracaso de la seguridad informtica en una organizacin
depende del esfuerzo realizado en implementar los controles de seguridad que
diseamos. Antes de poder implementar dichos controles, necesitamos comprender los
requerimientos de seguridad especficos de nuestro sistema, este es el objetivo de un
modelo de seguridad, especificar con precisin dichos requerimientos. El modelo que
escojamos para expresar los requerimientos debe ser fcil de comprender,
implementable, carente de ambigedad y capaz de incorporar las polticas de la
organizacin.
Los controles de acceso discrecionales dejan al sujeto la posibilidad de conceder el
acceso a los objetos de su propiedad. Cada sujeto fija las restricciones sobre sus objetos.
En este tipo de modelo el sistema no puede fijar restricciones especiales sobre el flujo
de la informacin. Dado que cada sujeto determina quin y cmo accede a los objetos
que le pertenecen, es imposible regular como se transfieren los objetos entre los
usuarios. Los controles de acceso discrecionales se expresan mediante modelos de
matriz de accesos, en los que se distinguen sujetos, objetos y tipos de acceso (lectura,
escritura, ejecucin, etc.). Un ejemplo de este tipo de controles es el mecanismo de
permisos de UNIX: cuando un usuario crea un objeto, puede o no definir un conjunto de
permisos de manipulacin para l, su grupo y los restantes usuarios.

MODELO DE SEGURIDAD HARRISON, RUZZO Y ULLMAN

El Modelo HRU.
Harrison, Ruzzo y Ullman propusieron un modelo en 1976 que es popularmente
referenciado como el modelo HRU. La definicin formal del modelo1 es la siguiente:
Nota: Este modelo slo se preocupa por la proteccin, esto es, quien tiene que acceso a
que objetos.
Definicin: un sistema de proteccin consiste de las siguientes partes:
1. un grupo finito de derechos genricos R.
2. un grupo finito de comandos C, de la forma:
command (X1, X2, . . . . , Xk)
if r1 in (XS1, XO1) and
r2 in (XS2, XO2) and
...
rm in (XSm, XOm)
then
op1
op2
...
opn
end
O si m es cero, simplemente
command (X1, X2, . . . . , Xk)
op1
op2
...
opn
end
Donde, es el nombre del comando, y X1, . . ., Xk son parmetros formales. Cada opi
es una de las operaciones primitivas siguientes:
- enter into (XS, XO)
- delete r from (XS, XO)
- create subject Xs
- create object Xo
- destroy subject Xs
- destroy object Xo

Tambin, r, r1, .. . , rm son derechos genricos y s, s1, . . . , sm y o, o1, . . . , om son

enteros entre 1 y k. Nosotros podemos llamar el predicado siguiente a la sentencia If
como la condicin de y a la secuencia de operaciones op1, . . . , opn, cuerpo de .

Definicin: una configuracin de un sistema de proteccin es una tripleta (S,O,P)

donde:
- S es el conjunto de sujetos actuales.
- O es el conjunto de objetos actuales, S O,
- P es una matriz de acceso, con una fila para cada sujeto en S y una columna para cada
objeto en O.
Un ejemplo de matriz de acceso es la que se muestra en a figura 0.

Se nota en la figura 0 que la fila s de la matriz es como una lista de capacidad para el
sujeto s, mientras la columna o es similar a una lista de acceso para el objeto o.
Cada comando debera verificar la presencia de ciertos derechos en ciertas posiciones de
la matriz de acceso actual. Esas condiciones pueden ser usadas para verificar que la
accin a ejecutarse por el comando est autorizada.

El modelo est basado en comandos, donde cada comando contiene condiciones y

operaciones primitivas. Las operaciones primitivas se definen como sigue:
Create subject s: Este comando permite al sujeto introducir un nuevo sujeto s dentro
del sistema.
- Create object o: Este comando permite al sujeto introducir un nuevo sujeto o dentro
del sistema.
- Destroy subject s: Le permite al controlador de un sujeto s, eliminarlo del sistema.
- Destroy object o: Le permite al propietario de un objeto o, eliminarlo del sistema.
- Grant right r into A[s,o]: Este le permite al propietario de un objeto o, conceder
cualquier derecho r al sujeto s.
- Delete right r from A[s,o]: Este le permite al propietario o controlador de un objeto o,
remover cualquier derecho r sobre este objeto al sujeto s.

Sistema de proteccin.
A continuacin se muestran las operaciones primitivas propuestas por el modelo HRU,
describiendo su precondicin y el estado final despus de haber sido ejecutado el
comando [Blyth00]:
Comando
Create object o

Precondicin
-

Create subject s

Delete object o
Delete subject s

Propietario en A[x,o]
Controlador en A[x,s]

Delete row s and delete

Controlador en A[x,s] o
column s
Propietario en A[x,o]
Grant access right r of s Propietario en A[x,o]
on o

Efecto
Se adiciona una columna
para o en A y se coloca
como propietario en A[x,o]
Se adiciona una fila para s
A y se adiciona una
columna para s en A y se
asigna el control a A[s,s]
Se elimina la columna de o
Se elimina la fila s y la
columna s
Se revoca el derecho r de
A[s,o]
Se adiciona el derecho r a
A[s,o]

Ejemplo del Modelo HRU

El siguiente ejemplo muestra una pequea implementacin del modelo HRU, en un
sistema de proteccin para un sistema contable. Usualmente para la implementacin de
un completo modelo de seguridad informtica, se hace uso de ms funcionalidades del
sistema operativo y de la arquitectura del hardware definida, pero para simplificar el
ejemplo esto no se tendr en cuenta.
De acuerdo a lo anterior, definiremos algunas polticas de seguridad que debern ser la
base para obtener una configuracin inicial ptima de una Matriz de acceso, que
garantice la seguridad del sistema para mono operaciones. Las polticas son las
siguientes:
El programa CONTAB solo podr ser utilizado por las personas autorizadas por el
departamento contable de la empresa.
Ninguna persona diferente al DBA3 podr escribir directamente en ninguna de las
tablas de la base de datos contable.
Ninguna persona ni siquiera el auditor puede escribir en el archivo de LOG de
auditora.
Para los 4 usuarios que hacen uso del servidor (en donde se aloja el programa contable,
la base de datos y el archivo de LOG de auditora) una configuracin de matriz de
acceso es la siguiente:
Las entradas para esta Matriz de Acceso se expresan as: Propietario (O), leer (R),
escribir (W), ejecutar (X), y Control (C)
3 DBA Administrador de la Base de Datos
En la matriz, CONTAB es un programa de contabilidad que utiliza a DATOS para leer y
guardar informacin contable, DATOS es un archivo (tablas de la base de datos) que
contiene la informacin contable, AUDITBD es un archivo que lleva el LOG de las
transacciones contables realizadas. JGAMARRA es el administrador del servidor en
donde se aloja la aplicacin, la base de datos y el LOG, FCARDENAS es el director del
departamento contable, STORRES es el auditor y RGARCIA es el administrador de la
base de datos.
Para la configuracin de la Figura 1, JGAMARRA puede cambiar todo menos el
archivo de LOG de auditoria (AUDITBD), STORRES puede leer ms no hacer cambios
en la base de datos, RGARCIA tiene acceso total sobre las tablas de la base de datos
pero cualquier modificacin quedar registrada en el archivo ADITBD al cual no tiene
acceso de ningn tipo.

La matriz de acceso no garantiza el control esperado para las polticas de seguridad

definidas, porque JGAMARRA y FCARDENAS pueden alterar la base de datos
directamente. STORRES tiene todos los permisos sobre el archivo de auditora, lo mejor
sera que CONTAB siendo la aplicacin, sea la encargada de crear y manejar el archivo
de auditora registrando directamente las transacciones contables, porque ahora mismo
nadie puede escribir en AUDITBD. Veamos ahora esta configuracin:
Ahora para esta configuracin CONTAB es un objeto y un sujeto que es propietario del
archivo AUDITB, FCARDENAS solo podr escribir en la base de datos a travs de la
ejecucin y uso de la aplicacin CONTAB. Sin embargo esta configuracin aun no es
segura ya que JGAMARRA podra sobre escribir a CONTAB con su propio programa,
pero dado que es el administrador del sistema se supone que no debera presentarse un
problema de este tipo teniendo en cuenta sus responsabilidades como administrador.

Ahora definiremos algunos de los comandos que podran ser utilizados en el manejo del
sistema contable.
- Por ejemplo, para la creacin del Archivo AUDITBD el comando sera el siguiente:
command CREAR_ARCHIVO(CONTAB, AUDITBD)
create Object AUDITBD
enter own into (CONTAB, AUDITBD)
end

- Para poder escribir un registro de LOG en el archivo AUDITBD el comando sera

como sigue:
command ESCRIBIR_LOG(CONTAB, AUDITBD, Registro)
if
write in (CONTAB, AUDITBD)
then
escribirRegistro (AUDITBD, Registro)
end

- Para leer y escribir en la base de datos los comandos seran:

command LEER_BD(STORRES, DATOS)
if
read in (STORRES, DATOS)
then
leerBD (STORRES)
end
command ESCRIBIR_BD(CONTAB, DATOS, Registro)
if
write in (CONTAB, DATOS)
then
escribirBD (CONTAB, Registro)
end

Ahora miraremos la ejecucin de algunas secuencias de comandos que utilizan la

configuracin inicial de la matriz [Figura 3], los comando son:
SK1: Esta secuencia de comandos crear un nuevo usuario que pueda utilizar la
aplicacin CONTAB, le dar los privilegios necesarios para utilizarla, el nico sujeto
que puede crear el usuario es el administrador JGAMARRA y este puede cometer el
error de asignarle permisos de W al nuevo usuario PPACHA. Esto demuestra que las
polticas de seguridad no se cumplen por si solas con la implementacin del modelo,
sino que las personas tienen que acatarlas y ponerlas siempre en prctica.
SK1 = C1 + C2 + C3 Donde,

C1= command CREAR_USUARIO(JGAMARRA, PPACHA)

create Subjetc PPACHA
enter control in (JGAMARRA, PPACHA)
end

C2=command CONFERIR_EJECUCIN(JGAMARRA, PPACHA, CONTAB)

if
own in (JGAMARRA, CONTAB)
then
enter X into (PPACHA, CONTAB)
end

C3= command CONFERIR_ESCRITURA(JGAMARRA, PPACHA, CONTAB)

if
own in (JGAMARRA, CONTAB)
then
enter W into (PPACHA, CONTAB)
end

El usuario PPACHA ahora tendra la posibilidad de borrar o sobre escribir la aplicacin

CONTAB con su propio programa y hacer variaciones que le permitan leer los datos de
la base de datos o variar el registro de LOG para alguna de sus operaciones.

Son los problemas de filtracin del modelo HRU necesariamente

negativos?
Un sistema de control de acceso tiene un grupo de usuarios, objetos y derechos de
acceso para ese grupo de usuarios y de objetos. La filtracin es una propiedad
interesante de los sistemas de control de acceso. Uno de los muchos significados de
analizar un modelo es tratar de clasificar los problemas de filtracin para cada modelo.
Podemos mostrar a manera de ejemplo dos acciones o necesidades que conllevan a la
filtracin en un sistema de proteccin:
- Muchos sujetos podran intencionalmente transferir sus derechos a otro sujeto (acto de
buena fe).
- Permitir en un sistema compartir recursos, podra fcilmente llevar a problemas de
filtracin.
La pregunta interesante es, si la transferencia del derecho r viola o no las polticas de
seguridad del sistema. Para solucionar el problema de seguridad por filtraciones se
puede considerar la revocacin o borrado de r en todos los sujetos que por acto de buena
fe lo recibieron.
Para tratar de asegurar que no se presenten estados a los cuales no se les pueda decir
cul ser el estado final de la matriz de acceso se puede incrementar la restriccin del
uso de mono-operaciones. Por ejemplo restringir que cada comando pueda slo ejecutar
un comando primitivo. El problema es que muchos comandos no pueden satisfacer sus
requerimientos slo con la ejecucin de comandos mono-operacionales [Mani2002].

Conclusin
Se present un modelo de seguridad formal enfocado en la proteccin del sistema. Se
mostr que con este modelo no hay un algoritmo que pueda decidir la seguridad de una
configuracin arbitraria de un sistema de proteccin arbitrario.
Este modelo permite identificar algunos estados, en los cuales el sistema de seguridad
no converge a un estado decidible, adems de definir de forma sencilla polticas de
seguridad para una compaa basndose en la proteccin de los datos.
El modelo presentado por Harrison, Ruzzo y Ullman, presenta las siguientes ventajas:
- El modelo HRU es sencillo de implementar en una organizacin, en cuanto a controles
de acceso y confidencialidad se refiere, ya que se pueden representar muchos tipos de
sistemas de proteccin.
- El modelo HRU es una base simple para la formulacin y desarrollo de modelos de
proteccin ms robustos.
- HRU es un modelo formal, esto indica que cuenta con una rigurosa demostracin para
sus definiciones y teoremas, gracias a esto, este modelo adquiere mayor credibilidad y
produce mayor confianza frente a un modelo informal.
Por otro lado, algunas de sus desventajas son las siguientes:
- El modelo propuesto por Harrison, Ruzzo y Ullman [HARR76] no presenta una
metodologa para su implementacin.
- Este modelo slo se preocupa la inseguridad del sistema de proteccin, basndose slo
en los estados en los de no decisin de estado final del sistema de proteccin.
El modelo slo se preocupa por la proteccin o confidencialidad de los objetos,
basndose en la matriz de control de acceso. Sin tener en cuenta aspectos como la
integridad y la disponibilidad de los datos.
- La restriccin establecida de manejar comandos mono-operacionales no satisface en
algunos casos los requerimientos de las organizaciones.

Bibliografa
Grah72 GRAHAM, G S., AND DENNING, P. J. "Protection--Principles and
practice," in Proc 1972 AFIPS Spring Jt Computer Conf, vol. 40, AFIPS Press,
Montvale, N.J. pp. 417-429.
Denn71 DENNING, P. J. "Third generation computer systems," Computing
Surveys 3, 4 (Dec. 1971), 171-216.
Lamp71 LAMPSON, B W. "Protection," Proc.5th Princeton Symp on Information
Sciences and Systems (March 1971), pp 437-443, reprinted in Operating Systems
Rev 8, 1 (Jan 1974), 18-24.
Land81 LANDWEHR, Carl E.. Formal Models for Computer Security. Computing
Surveys, Vol 13, No. 3, September 1981.
Harr76 HARRISON, Michael A., Ruzzo, Walter L., and Ullman, Jeffrey D.,
Protection in Operating Systems, Communications of the ACM, vol. 19, no. 8, pp.
461 471, 1976.
Blyth00 BLYTH, Andrew. School of Computing Harrison-Ruzzo-Ullman Model.
2000.
Mani2002 MANIAN, Vijay. Access leak problem in Access Control Matrices. June
of 2002.
http://www.criptored.upm.es/guiateoria/gt_m248e.htm