Un Vistazo A Los Sistemas Distribuidos

SISTEMAS DISTRIBUIDOS
Teoría Fundamental para Sistemas Distribuidos
Un Vistazo a los
Sistemas Distribuidos
_____________________
Gabriel Gerónimo C.
BORRADOR VERSIÓN 0.6 MAYO 2022.
Licencia
Atribución-CompartirIgual 4.0
Internacional
Universidad Tecnológica de la Mixteca

Instituto de Computación
gcgero@mixteco.utm.mx
Prólogo
Las presentes notas son una recopilaciones de diferentes libros básicos que se
recomiendan a los estudiantes de nivel licenciatura para la materia de Sistemas
Distribuidos, así como artículos fundamentales en los temas de teoría de
sincronización de relojes de Lamport, Gusella y Zatti; exclusión mutua de Ricart-
Agrawala; elección de líder de García-Molina, Le Lann; interbloqueos de Chady-
Misra-Hass; tolerancia a fallos de Lamport-Shostak-Pease; teoría de control de
acceso de Lampson, y formalismo de Harrison-Ruzzo-Ullman; y modelos de
seguridas propuesto por Bell-LaPadula, Clark-Wilson, Brewer-Nash, y Goguen-
Meseguer.
Las notas pueden ser compartida bajo la licencia CC, como indique, es una
antología de libros básicos como Sistemas Distribuidos de G. Coulouris,
Sistemas Distribuidos de A. Tanenbaum, Sistemas Distribuidos de Mullender,
Unix de C. Brown, Unix de F. M. Marquez, Unix de Robbins, y diferentes
artículos sobre temas relacionados con sistemas distribuidos, los cuales son
utilizados y mencionados en el desarrollo de los capítulos. Los artículos tratan de
enriquecer los temas, y cubrir los huecos que se dejan cuando solamente se
explora la bibliografía básica recomendada en los cursos de Sistemas
Distribuidos.
Estas notas con licencia cc, es la 0.6, faltan demasiados detalles que cubrir,
figuras que colocar y tablas que actualizar, sólo para justificar su liberación, diré
a mi favor: necesito colocar estas notas para que las lean mis estudiantes, y no
tengan excusa de no encontrar los libros, y artículos, pero si motivo de indicar
que algo anda mal en las páginas. ¡Espero sea de utilidad!
...después del café.

No hay momento
en que no piense en ti...
Con las mismas manos. Roberto Fernández Retamar.
Universidad Tecnológica de la Mixteca

Instituto de Computación
M.C. Gabriel Gerónimo C.
gcgero@mixteco.utm.mx
x
Contenido
I. Comunicación: procesos e hilos..........................................................5
1. Procesos.........................................................................................5
2. Hilos..............................................................................................12
II. Sincronización..................................................................................16
1. Sincronización de relojes..............................................................16
2. Sincronización lógica de Lamport.................................................17
3. Sincronización de tiempos propuesto por Gusella y Zatti.............19
4. Probabilidad de sincronización propuesta de Flaviu Cristian........23
III. Exclusión mutua..............................................................................27
1. Introducción..................................................................................27
2. Algoritmo basado en permiso propuesto por Lamport.................28
3. Algoritmo basado en permiso propuesto Ricart y Agrawala.........29
4. Algoritmos basados en tokens – clasificación de Michel Raynal...31
5. Coordinador central......................................................................32
IV. Elección...........................................................................................34
1. Introducción..................................................................................34
2. Elección en un sistema distribuido propuesta de García-Molina...34
3. Algoritmos de elección en un anillo – Le Lann, Chang&Roberts, y

Frederickson&Lynch.........................................................................40
V. Deadlock..........................................................................................45
1. Introducción..................................................................................45
2. Modelo del sistema.......................................................................45
3. Wait-For-Graph (WFG)..................................................................46
4. Estrategias de tratamiento de un deadlock..................................46

5. Modelos de deadlock....................................................................49
6. Algoritmo centralizado para la detección de bloqueos.................49
7. Propuesta de Chandy-Misra-Haas.................................................50
VI. Tolerancia a fallos...........................................................................56
1. Introducción al problema de tolerancia de fallos..........................56
2. Problema de los Generales Bizantinos..........................................57
VII. Control de acceso...........................................................................65
1. Introducción..................................................................................65
2. Matriz de acceso...........................................................................65
VIII. Modelos de seguridad...................................................................72
1. Introducción..................................................................................72
2. Modelo de Bell-LaPadula...............................................................72
3. Modelo de Biba.............................................................................75
4. Modelo de Clark-Wilson................................................................90
5. Modelo de Muralla China..............................................................92
6. Modelo de Goguen-Meseguer.......................................................96
x
Capítulo I
Comunicación:
procesos e hilos
Un proceso es una entidad en ejecución que tiene asociada un número para poder ser
identificado por el sistema. En el sistema se cuenta con procesos llamados hijos, y
procesos llamados hilos.
1. Procesos
Todos los sistemas de multiprogramación están construidos en torno al concepto de
procesos. El modelo más sencillo considera que un proceso puede estar en ejecución o
en espera del turno de ejecución (Figura 1.1).
Figura 1.1. Diagrama de transición de estados.
Aunque este modelo es simple se puede apreciar algunos de los elementos del diseño
del sistema operativo, cada proceso debe representarse de forma que el sistema
operativo pueda seguirle la pista. Aquellos procesos que no están ejecutándose tiene
que guardarse en algún tipo de cola, para que esperen su turno de ejecución (Figura
1.2), por lo que, la vida de un proceso está limitada de su creación a su terminación.
Figura 1.2. Diagrama de colas.

Si todos los procesos estuvieran siempre listos para ejecutar, entonces la disciplina de
cola propuesta anteriormente sería eficaz, sin embargo, aún en el simple ejemplo que
se ha descrito, esta implementación no es adecuada: algunos procesos en el estado de
No Ejecución están listos para ejecutar, mientras que otros están bloqueados,
esperando a que termine una operación de E/S. Así pues, utilizando una cola sencilla, el
distribuidor de procesos podría no seleccionar exactamente el proceso que está en el
extremo más antiguo de la cola. Más bien, el distribuidor tendría que recorrer la lista
buscando el proceso que no esté “no bloqueado” y que lleve más tiempo en la cola.
Una forma más eficaz de afrontar esta situación es dividir el estado de No Ejecución en
dos estados: Listo y Bloqueado. De esta forma se cuenta ahora con cinco estados
(Figura 1.3):
• Ejecución. Proceso que está actualmente en ejecución.
• Listo. Proceso que está preparado para ejecutar, en cuanto se le dé la
oportunidad.
• Bloqueado. Proceso que no puede ejecutarse hasta que se produzca cierto
suceso, como la terminación de una operación de E/S.
• Nuevo. Proceso que se acaba de crear, pero que aún no ha sido admitido
por el sistema operativo en el grupo de procesos ejecutables.
• Terminado. Proceso que ha sido excluido del grupo de procesos
ejecutables, bien porque se detuvo o porque fue abandonado por alguna
razón.
Figura 1.3. Diagrama de estado para un sistema operativo sencillo.
Cuando se añade un proceso a la lista administrada por el sistema operativo, se deben

construir las estructuras de datos que se utilizan para administrar el proceso y asignar el
espacio de direcciones que se va a utilizar.
Existen cuatro sucesos comunes que llevan a la creación de un proceso:

• como respuesta a la remisión de un trabajo.
• cuando un nuevo usuario intenta conectarse.
• cuando un proceso existente genera otro proceso.
x
• cuando el SO lo crea para brindar un servicio.
Cuando un proceso genera otro, el proceso generador se conoce como proceso padre
y el proceso generado es el proceso hijo. Normalmente, estos procesos
“emparentados” necesitarán comunicarse y cooperar entre sí.
1.1. Sistema de llamada fork

En los sistemas Linux se pueden crear los procesos a través de una llamada fork, y el
sistema se encargará de copiar la imagen del proceso padre en la memoria y el nuevo
proceso, creado, recibe una copia del espacio de direcciones del padre. Los dos
procesos (padre e hijo) continúan su ejecución en la instrucción que se encuentra
después del fork. La sintaxis de fork es la siguiente:
PROTOTIPO DE LA FUNCIÓN
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
La creación de dos procesos totalmente idénticos que ejecuten el mismo código no es

algo muy útil, por lo que, el valor devuelto por fork es la característica distintiva,
importante, que permite que el padre y el hijo ejecuten código distinto. El fork devuelve
0 al hijo y un número mayor que 0 (que identifica al hijo) al padre, a ese número se le
conoce como PID.
Entonces el llamado a fork crea procesos nuevos haciendo una copia de la imagen del
padre en la memoria. El hijo hereda la mayor parte de los atributos del padre,
incluyendo el ambiente y los privilegios. El hijo también hereda algunos de los recursos
del padre, tales como los archivos y dispositivos abiertos. Pero, no todos los atributos o
recursos del padre son heredados por el hijo. Este último tiene un ID de proceso nuevo
y, claro que es diferente del ID del padre. Los tiempos del hijo para el uso del CPU son
iniciados a 0. El hijo no obtiene los bloqueos que el padre mantiene. Si el padre ha
colocado una alarma, el hijo no recibe notificación alguna del momento en que ésta
expira. El hijo comienza sin señales pendientes, aunque el padre las tenga en el
momento en que se ejecuta el fork. Aunque el hijo hereda la prioridad del padre y los
atributos de la administración de procesos, tiene que competir con otros procesos, como
cualquier otra entidad, por el tiempo del procesador.
1.2. Identificadores de procesos
El identificador del proceso se recupera por medio de la instrucción getpid(), y el

identificador del proceso que es su padre por medio de la instrucción getppid(). Los
prototipos de estas instrucciones son las siguientes.
#include <unistd.h>
pid_t getpid(void);
#include <unistd.h>
pid_t getppid(void);
El tipo de dato pid_t representa el ID del proceso, y es un número de tipo entero. De

esta manera se puede obtener el ID del proceso invocando getpid; y la función getppid
retorna el ID del padre del proceso actual.
Los procesos pueden estar agrupados en conjuntos que tienen alguna característica en
común, por ejemplo el mismo padre. Para determinar a que grupo pertenece un
proceso, se utiliza getpgrp, y para cambiar a un proceso como líder del grupo se hace
uso del llamado setpgrp.
#include <unistd.h>
pid_t getpgrp(void);
pid_t setpgrp(void);
Se debe tener en consideración que cuando el proceso padre llega a morir antes que
los hijos, el PPID del proceso hijo toma el valor de 1, el cual corresponde al proceso
init/systemd.
1.3. Sistema de llamada wait ()

¿Qué sucede con el proceso padre después de que éste crea un hijo? Tanto el padre
como el hijo continúan la ejecución desde el punto donde se hace la llamada a fork. Por
lo que el proceso padre puede terminar su ejecución antes que el hijo, o viceversa. Si el
padre desea esperar hasta que el hijo termine, entonces debe ejecutar una llamada a
wait o a waitpid. La sintaxis es la siguiente:
x
#include <sys/wait.h>
pid_t wait (int *stat_loc);

pid_t waitpid (pid_t pid, int *status, int options);
La llamada al sistema wait detiene al proceso que la invoca hasta que un hijo de éste
termine o se detenga, o hasta que el proceso que la invocó reciba una señal. wait
regresa de inmediato si el proceso no tiene hijos o si el hijo termina o se detiene y aún
no se ha solicitado la espera. Si wait regresa debido a la terminación de un hijo, el
valor devuelto es positivo e igual al ID de proceso de dicho hijo. De lo contrario, wait
devuelve –1 y pone un valor en errno. Si errno es igual a ECHILD, indica que no
existen procesos hijos a los cuales hay que esperar. Si errno es igual a EINTR, la
llamada fue interrumpida por una señal.
stat_loc es un apuntador a una variable entera.
Después del llamado a wait, el estado de la información almacenada en la localidad

apuntada por stat_loc puede ser analizada aplicando los siguiente macros:
WIFEXITED (*stat_loc). Si en la evaluación el valor no es cero (true) indica que el

proceso hijo terminó normal.
WEXITSTATUS (*stat_loc). Si el proceso hijo termina normalmente, este macro evalúa
los 8 bits mas bajos del valor pasado por la función exit , _exit o return desde la función
main.
WIFSIGNALED (*stat_loc). Si en la evaluación el valor no es cero (true) indica que el
proceso hijo terminó porque recibió una señal no controlada.
WTERMSIG (*stat_loc). Si el proceso hijo finaliza por una señal que no fue capturada,
este macro evalúa el número de la señal.
El hijo regresa su estado llamando a exit, _exit o return.
Por otra parte, cuando se necesite esperar que un proceso especifico termine, se debe
utilizar la función waitpid la cual suspende la ejecución del proceso en curso hasta
que el hijo especificado por el argumento pid ha terminado, o hasta que se produzca
una señal cuya acción sea finalizar el proceso actual o llamar a la función manejadora
de la señal.
*status es la localidad en la cual se devuelve la información del estado de terminación
del hijo, pid contiene un valor que puede ser, -1 para indicar que espera a cualquier hijo,
un número>0 (positivo) indica que debe esperar al proceso cuyo PID sea ese número, 0
para indicar que espere a cualquier hijo cuyo Process Group ID sea igual al del proceso
que invoco el llamado, un número<0 (negativo) indica que espere a cualquier proceso
cuyo Process Group ID sea igual al valor absoluto de PID.
En options se coloca una combinación de las siguientes banderas: WEXITED que

espera por hijos que hayan terminado, WSTOPPED que espera por hijos que hayan
sido parados por recibir una señal, WNOHANG que no espera por un hijo que esta en
ejecución, WNOWAIT deja al hijo sin modificar ni marcar en la tabla de procesos, tal
que una posterior llamada se comportaría como si no hubiésemos hecho wait por dicho
hijo, WUNTRACED que no esperar si el hijo está parado a no ser que este siendo
trazado, WCONTINUED volver si un hijo ha continuado ejecutándose tras mandarle la
señal SIGCONT. Las banderas WUNTRACED y WCONTINUED solo son efectivas si
SA_NOCLDSTOP no ha sido establecida para la señal SIGCHLD.
1.4. Sistema de llamada exit

En cualquier sistema operativo, existe alguna forma para que un proceso pueda indicar
que ha terminado (vea Tabla 1.1).
Tabla 1.1. Terminación de proceso.

Razones para terminación de un proceso
Terminación normal El proceso ejecuta una llamada a un servicio del SO

para indicar que ha terminado su ejecución.
Tiempo límite excedido El proceso se ha ejecutado sobre pasando el límite

especificado.
No hay memoria disponible El proceso necesita más memoria de la que el

sistema le puede proporcionar.
Violación de límites El proceso trata de acceder a una posición de

memoria a la que no le está permitido.
Error de protección El proceso intenta utilizar un recurso o un archivo que

no le está permitido utilizar, o trata de utilizarlo de
forma incorrecta, como escribir en un archivo que es
sólo de lectura.
Error aritmético El proceso intenta hacer un cálculo prohibido, o trata

de almacenar un número mayor del que el hardware
acepta.
Tiempo máximo de espera El proceso ha esperado más allá del tiempo máximo
rebasado especificado para que se produzca cierto suceso.
Fallo de E/S Se produce un error en la entrada o la salida, tal

como no encontrar un archivo, un fallo de lectura o
escritura después de un número máximo de intentos.
Instrucción privilegiada El proceso intenta usar una instrucción reservada

para el SO.
Intervención del operador o Por alguna razón el operador o el sistema operativo

del SO terminan con el proceso.
Terminación del padre Cuando un proceso padre finaliza. El SO puede

diseñarse para terminar automáticamente con todos
sus descendientes.
Solicitud del padre Un proceso padre tiene normalmente la autorización

de terminar con cualquiera de sus descendientes.
x
Como se ha visto el proceso debe terminar de alguna manera, es decir, de forma

normal o anormal. Lo que se desea es una terminación normal, en el mejor de los
casos, para esto el proceso debe hacer un llamado a la función exit. Esta función se
encarga de retirar los recursos que está utilizando el proceso, así como dejarlo
preparado para su eliminación, quitarlo del planificador e indicar su terminación a su
padre por medio de la señal SIGCHLD. Para pasar de un estado a otro se define un
estado transitorio que en el sistema se le llama zombie. En linux si el proceso que
termina no tuviera padre, ya que este acabó antes que él, se eliminaría directamente del
planificador en la llamada exit, y es adoptado por el proceso 1 (init).
#include <stdlib.h>
void exit (int status)
El llamado a exit termina la ejecución del proceso y devuelve el valor de estatus al

proceso padre. Desde el sistema Linux se puede consultar lo que devuelve el último
proceso que finaliza por medio de la variable de entorno “?”.
Los sistemas que administran procesos deben ser capaces de realizar ciertas
operaciones sobre los procesos y con ellos. Tales operaciones incluyen: crear, destruir,
suspender, reanudar, cambiar la prioridad, bloquear, despertar, despachar y comunicar
procesos.
1.5. Sistema de llamada exec

La llamada fork crea una copia del proceso que la llama y se la herada al proceso
creado. Muchas aplicaciones requieren que el proceso hijo ejecute un código diferente
del de su padre. La familia exec de llamadas al sistema proporciona una característica
que permite traslapar al proceso que llama con un módulo ejecutable nuevo. La manera
tradicional de utilizar la combinación fork-exec es dejar que el hijo ejecute el exec para
el nuevo programa mientras el padre continúa con la ejecución del código original.
Existen seis variaciones de la llamada exec al sistema, las cuales se distinguen por la
forma en que son pasados los argumentos de la línea de comando y el ambiente, y por
si es necesario proporcionar la ruta de acceso y el nombre del archivo ejecutable. Los
dos grupos que albergan esas variaciones son execl y execv:
1. execl (execl, execlp y execle). Estos llamados pasan los argumentos de la
línea de comando como una lista y son útiles si se conoce el número de
argumentos de la línea de comando en el momento de la compilación.
2. execv (execv, execvp y execve). Estos llamados pasan los argumentos de la
línea de comando en un arreglo de argumentos.
Las sintaxis de ellos se muestra a continuación:

#include <unistd.h>
int execl (const char *path, const char *arg0, … , const char *argn,
char * / *NULL*/);
int execle (const char *path, const char *arg0, … , const char *argn,
char * /*NULL*/, const char *envp[]);
int execlp (const char *file, const char *arg0, … ,const char *argn,
char */*NULL*/);
#include <unistd.h>
int execv (const char *path, const char *argv[]);

int execvp (const char *file, const char *argv[]);
int execve (const char *’path, const char *argv[], const char *envp[]);
2. Hilos
Los hilos representan una manera de trabajar con diferentes procesos no
emparentados. Para utilizarlos se necesita contar con la librería pthreads que es un
estándar de POSIX (Portable Operating System Interface). En los sistemas UNIX, un
estándar de programación C para interface de programación de hilos se encuentra
especificada por el estándar IEEE POSIX 1003.1c. Las implementaciones que se basan
en este estándar son referenciados como POSIX threads o pthreads. En la tabla 1.2 se
pueden observar algunas funciones usadas para el manejo de hilos, estas se verán con
mayor detalle en secciones posteriores.
La diferencia entre un hilo y un proceso es que los procesos no comparten la misma
memoria, mientras que los hilos sí comparten totalmente la memoria entre ellos. Para la
creación de los hilos se usan las funciones de la librería pthread o de cualquier otra que
soporte threads mientras que para crear procesos se usa la llamada al sistema fork.
Para compilar programas que hagan uso de la librería pthread, usando GNU cc o GNU
Compiler Collection gcc se ejecuta la orden:
cc hilos.c -o hilos -lpthread
o
gcc hilos.c -o hilos -lpthread
Tabla 1.2. Lista de llamados en POSIX 1.c.
Descripción POSIX
Gestión de hilos pthread_create

pthread_exit
pthread_kill
pthread_join
pthread_self
x
Exclusión mutua pthread_mutex_init

pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_trylock
pthread_mutex_unlock
variables de condición pthread_cond_init

pthread_cond_destroy
pthread_cond_wait
pthread_cond_timedwait
pthread_cond_signal
pthread_cond_broadcast
2.1. Creación de hilos

La función pthread_create es usada para crear un hilo, con ciertos atributos, y esté
ejecutará una determinada función o subrutina con los argumentos que se le indique.
#include <pthread.h>
int pthread_create (pthread_t *thread, const pthread_attr_t *attr,

void* (*start_routine) (void *), void *arg);
Los atributos para un proceso son especificados en attr, si attr es NULL, el atributo
por omisión es usado. Si la función se realiza con éxito, se almacena el ID del hilo en la
localidad referenciada por thread.
El hilo que está creado ejecuta la función o rutina start_routine con arg como su
argumento. Si necesitamos pasar o devolver más de un parámetro a la vez, se puede
crear una estructura y colocar ahí los campos necesarios. Luego se pasa o se devuelve
la dirección de esta estructura como único parámetro.
Cuando finaliza start_routine se llama implícitamente a pthread_exit() o su

equivalente.
El estado de las señales del nuevo hilo será:
• Se heredará la máscara de señales del hilo creador
• El conjunto de señales pendientes del nuevo hilo estará vacío.
Un hilo termina si:

• Se llama a pthread_exit(), especificando un valor de estado final que es
disponible para otros hilos en el mismo proceso llamando a pthread_join().
• Realiza un return desde start_routine que es equivalente a pthread_exit().
• Es cancelado pthread_cancel().
• El hilo principal ejecuta un return desde main. Causando la terminación de

todos los hilos.
pthread_create retorna 0 en caso de éxito, o un número de error en otro caso, y el

contenido de *thread se indefine. Los errores que pueden retornados en errno son:
• EAGAIN. Insuficiente recursos para crear un hilo, o el límite de los hilos del
sistema fueron alcanzados (en Linux vea /proc/sys/kernel/threads-max)
• EINVAL. Inválido el atributo.
• EPERM. Política de planificación no permitida y los parámetros de attr.
2.2. Terminación de un hilo

La función pthread_exit() terminará la ejecución del hilo que haga su invocación y
hará disponible el valor value_ptr para cualquier join con éxito con el hilo que hace la
llamada.
int pthread_exit (void *value_ptr)
2.3. Atributos de un hilo

La función pthread_attr_init () se encarga de inicializar el objeto de atributos attr del hilo
con los valores por defecto utilizado en una implementación.
int pthread_attr_init ( pthread_attr_t *attr);
2.4. Destrucción de los atributos de un hilo

La función pthread_attr_destroy () se encarga de destruir el objeto de atributos attr del
hilo con valores no definidos en una implementación. Un objeto de atributos destruido
con función podrá ser inicializado posteriormente con la función pthread_attr_init().
int pthread_attr_destroy (pthread_attr_t *attr);
x
2.5. Esperar la terminación de un hilo creado
La función pthread_join() suspenderá la ejecución del hilo que hace la llamada, hasta
que el hilo destino termine. Esta función es un mecanismo que permite la sincronización
de hilos (vea figura 1.4).
int pthread_join ( pthread_t thread, void **value_ptr);
El valor que pase el thread destino con la función pthread_exit() estará disponible en
la localidad de memoria a la que hace referencia value_ptr.
La función espera hasta que termine el hilo especificado en thread. La función retorna
0 en caso de éxito o el número de error en otro caso. Los errores pueden ser:
• EDEADLK. Un deadlock fue detectado, es decir, dos hilos esperan uno del otro.
• EINVAL. thread no está unido a otro hilo.
• ESRCH. El hilo con ID thread no fue encontrado.
Figura 1.4. Sincronización de hilos.

Capítulo II
Sincronización
En el caso de una computadora no importa si el reloj se desfasa, puesto que todos los
procesos de la máquina utilizan el mismo reloj, tendrán consistencia interna, pero
cuando se comienza a trabajar con varias máquinas la situación es distinta. Al tener n
computadoras, los n relojes, correspondientes, trabajan en forma distinta, lo que
provoca una pérdida de sincronización llamada distorsión del reloj. Como consecuencia
de esta distorsión, podrían fallar los programas que esperan que el tiempo asociado a
un archivo, objeto, proceso o mensaje sea el correcto, independientemente del sitio
donde se haya generado.
1. Sincronización de relojes
La sincronización en los sistemas distribuidos es más compleja que en los sistemas
centralizados, ya que se deben utilizar algoritmos distribuidos, que cumplan con las
siguientes propiedades: la información relevante se debe distribuir entre varias
máquinas, los procesos deben tomar las decisiones sólo con base en la información
disponible en forma local, se debe evitar un punto de fallo en el sistema, no existe un
reloj común o alguna otra fuente precisa de tiempo global.
En el capítulo anterior se mostraron características de los procesos, los cuales son el
punto esencial de todos los sistemas operativos. Algo fundamental es la comunicación
entre ellos, pero, no es todo lo que hay que considerar, íntimamente relacionado con
esto, está la forma en que los procesos cooperan y se sincronizan entre sí, por ejemplo,
la forma de accesar a las secciones críticas o las asignaciones de recursos en el
sistema. En los sistemas con un procesador, los problemas relativos a las secciones
críticas, la exclusión mutua y la sincronización se resuelven, en general, mediante
métodos tales como semáforos, memoria compartida o paso de mensajes. Estos
métodos no son adecuados para su uso en los sistemas distribuidos, puesto que se
basan en la existencia de memoria compartida. Por ejemplo, dos procesos que
interactúan mediante un semáforo deben tener acceso a éste, si se ejecutan en la
misma máquina, pueden compartir el semáforo guardándolo en el núcleo y realizando
llamadas al sistema para tener acceso a él. Sin embargo, si se ejecutan en máquinas
distintas, este método ya no funciona, por lo que se necesitan otras técnicas, incluso el
hecho de determinar si el evento A ocurrió antes o después del evento B requiere una
reflexión cuidadosa.
x
2. Sincronización lógica de Lamport

Leslie Lamport en su artículo “Time, Clocks, and the Ordering of Events in a
Distributed System”, muestra que la sincronización de relojes es posible y presentó
un algoritmo para lograrlo. Señala que la sincronización de relojes no tiene que ser
absoluta. Si dos procesos no interactúan, no es necesario que sus relojes están
sincronizados, puesto que la carencia de sincronización no sería observable y por lo
tanto no podría provocar problema, además señala que lo que importa por lo general no
es que todos los procesos concuerden de manera exacta en la hora, sino que coincidan
en el orden en que ocurren los eventos. Lamport se encarga de sincronizar los relojes
lógicamente, en este artículo no le importa el reloj real. A continuación se muestra la
información plasmada en su artículo.
2.1. Tiempo, relojes y Orden de eventos en un sistema distribuido

En un sistema distribuido es algunas veces imposible saber si uno de dos eventos
sucedió primero. La relación “ocurrió antes” es por lo tanto un orden parcial de los
eventos en el sistema.
2.1.1. Orden Parcial

Se asume que los eventos de un proceso forma una secuencia, donde a ocurre antes
que b en la secuencia si a sucede antes que b. Un sólo proceso se define como un
conjunto de eventos con un orden total a priori. Se asume que enviar o recibir un
mensaje es un evento en un proceso. Se puede definir entonces la relación “paso
antes”, denotada “→ “, como:
Definición
La relación “→“ sobre el conjunto de eventos de un sistema es una relación
menor que satisface las siguientes condiciones:
1. Si a y b son eventos en el mismo proceso y a llega antes que b entonces
a→b
2. Si a es el envío de un mensaje por un proceso y b es la recepción del mismo
mensaje por otro proceso entonces a→b
3. Si a→b y b→c entonces a→ c
Dos distintos eventos a y b se dicen que son concurrentes si a b y b a. Se

asume además que a a para cualquier evento a. Esto implica que → es una
ordenación parcial irreflexiva en el conjunto de todos los eventos en el sistema. Otra
forma de ver la definición a→b significa que es posible para un evento a afectar
causalmente a un evento b. Dos eventos son concurrentes si ni causalmente se
afectan entre ellos.
Introduciendo un reloj en el sistema, se define un reloj C i para cada proceso Pi como

una función que asigna un número Ci(a) a cualquier evento a en ese proceso. De esta
manera, todo el sistema de relojes está representado por una función C la cual asigna a
cualquier evento b un número C(b) donde C(b)=Cj(b) si b es un evento en el proceso Pj.
Condición de Reloj:
Para cualesquiera eventos a, b: Si a→b entonces C(a) < C(b)
La condición de reloj se satisface si se cumplen las siguientes dos condiciones:

C1: Si a y b son eventos en el proceso Pi, y a está antes que b, entonces

Ci(a) < Ci(b)
C2: Si a es el envío de un mensaje por el proceso Pi y b es la recepción de ese
mensaje por el proceso Pj entonces Ci(a) < Cj(b)
Para garantizar que el sistema de relojes satisface a la “condición de reloj”, se debe

garantizar que satisfagan las condiciones C1 y C2. La condición C1 es simple, los
procesos necesitan obedecer la siguiente regla:
IR1: Cada proceso Pi incrementa Ci entre cualquiera de dos

eventos sucesivos.
Para satisfacer la condición C2, es necesario que cada mensaje m contenga una marca
de tiempo Tm que debe ser igual a el tiempo en la cual se envío el mensaje. Al recibir un
mensaje de la marca de tiempo Tm, el proceso debe avanzar su reloj uno más que Tm.
Con mayor precisión se tiene la siguiente regla:
IR2:
a) Si el evento a es el que envía un mensaje m por parte del proceso Pi,
entonces el mensaje m contiene una etiqueta de tiempo Tm = Ci(a);
b) Al recibir un mensaje m, el proceso Pj fija Cj mayor que o igual a su valor
actual pero mayor que Tm.
En IR2(b) se considera que el evento que representa la recepción del mensaje m a

ocurrido después de fijar Cj.
2.1.2. Orden total de Eventos

Se puede utilizar un sistema de relojes que satisfacen la condición de reloj para colocar
un orden total en el conjunto de todos los eventos del sistema. Aquí simplemente se
ordenarán por el tiempo en el cuál ellos ocurren. Se usará un orden total < de los
procesos como sigue:
Definición
Si a es un evento en un proceso Pi y b es un evento en un proceso Pj
entonces a ⇒ b si y sólo si
i) Ci(a) < Cj(b), o
(ii) Ci(a) = Cj(b) y Pi < Pj
Estas condiciones implican que si a→b entonces a⇒ b, de esta forma se pasa de un

orden parcial a un orden total.
Por el momento se deja hasta aquí la exploración del artículo de Lamport, pero se
retomará en el capítulo II, donde se muestra el algoritmo propuesto sobre exclusión
mutua que también se trata en el artículo.
2.2. Sincronización con tiempo global

Si una máquina tiene un receptor WWV (WWV es una estación de radio de onda corta
que opera desde Fort Collins, Colorado, para proporcionar el tiempo preciso a las
personas, a este tiempo se le conoce como UTC – Tiempo Coordenado Universal),
entonces el objetivo es hacer que todas las máquinas se sincronicen con ella. Si
ninguna máquina tiene receptores WWV, entonces cada máquina lleva el registro de su
x
propio tiempo y el objetivo es mantener el tiempo de todas las máquinas tan cercano
como sea posible. Existen muchas propuestas para limitar el retardo de trasmisión de
los mensajes y basado en ello tratar de sincronizar los relojes, dentro de estas
propuestas se encuentran las aportaciones de Kopetz y Ochsereiter, 1987, artículo
“Clock Synchronization in Distributed Real-Time”; Riccardo Gusella y Stefano Zatti,
1987, artículo, “The Accuracy of the Clock Synchronization Achieved by TEMPO in
Berkeley UNIX 4.3 BSD”; Flaviu Cristian en 1989 dentro del artículo “Probabilistic clock
synchronication”; Drummond y Babaoglu, 1993, artículo “Low-cost syncronization”.
A continuación se muestra el planteamiento de Gusella y Zatti (1987) para llevar a cabo
la sincronización de los relojes de un conjunto de máquinas que forman una red.
3. Sincronización de tiempos propuesto por Gusella y Zatti

En esta sección se mostrá la aportación de Riccardo Gusella y Stefano Zatti en su
artículo de 1987, The Accuracy of the Clock Synchronization Achieved by
TEMPO in Berkeley UNIX 4.3BSD. En este artículo se indica que se tendrá un
servidor de tiempo activo que realizará un muestreo periódico de todas las máquinas
para preguntarles su tiempo (Figura 2.1). Con base en las respuestas, calculará un
tiempo promedio y le indica a todas las demás máquinas que avancen su reloj a la
nueva hora o que disminuyan la velocidad del mismo hasta lograr cierta reducción
específica (Figura 2.2). También el artículo discute los límites superior e inferior de la
exactitud de la sincronización del tiempo logrado por los algoritmos implementados en
un servidor de tiempo llamado TEMPO. TEMPO es un conjunto de demonios de tiempo,
que se ejecutan en cada máquina, basados en una estructura de red maestro esclavo,
donde un sincronizador de reloj distribuido se ejecuta en un sistema UNIX Berkeley
4.3BSD.
3.1. Funcionamiento
En las figuras 2.1 y 2.2 se muestra el funcionamiento de TEMPO. Un demonio maestro

de tiempo mide la diferencia de tiempo entre su reloj y los demás relojes de las otras
máquinas. El maestro calcula el tiempo de la red como promedio del tiempo de los
relojes que no falla, y este es enviado a los demonios de tiempo esclavos para corregir
los relojes de sus máquinas. Dado que las correcciones pueden ser negativas, para
preservar la monotonicidad de las funciones de los relojes, el sistema implementa
ralentización (o aceleración) de las velocidades de los relojes. El maestro selecciona el
conjunto de relojes que no difieran entre si más que un pequeño ɤ y promedia la
diferencia (en la figura 2.1, ɤ=10). Para el ejemplo promedia el rejoj del maestro, y de
los esclavos 1 y 2, después el maestro envía este promedio a cada esclavo para que
avance o retroceda su reloj, y todos estén sincronizados.
Figura 2.1. El servidor de tiempo pregunta el valor de los demás relojes.
Los pasos que se realizan en la figura 2.1 son:

1. Se miden las diferencias de los relojes con respecto a el reloj del maestro
• Tiempo del reloj del maestro con sigo mismo
◦ R0=C(master)-C(master)=3:05-3:05=0:00
• Tiempo de los relojes de los esclavos
◦ R1=C(Slave1)-C(master)=2:55-3:05=-0:10
◦ R2=C(Slave2)-C(master)=3:00-3:05=-0:5
◦ R3=C(Slave3)-C(master)=3:25-3:05=0:20
2. Se seleccionan los participantes a considerar para el promedio. Lo cual depende
al valor del ɤ
◦ |ɤ|≥R0 master participa(siempre se cumple)
◦ |ɤ|≥R1 slave1 participa
◦ |ɤ|≥R2 slave2 participa
◦ |ɤ|<R3 slave3 no participa
3. Calcular el promedio
R0 + R 1+ R 2
◦ Av = =−5
3
Los pasos que se realizan en la figura 2.2 son:

4. Se realizan los cálculos para el ajuste de los relojes
• Maestro
◦ Master. Como su diferencia fue 0, entonces
C( master)=3 :05+(0 :00+(−0 :05))=3: 00
• Esclavos
◦ Slave1. Como su diferencia fue -10 (está atrasado debe adelantarse) se
tomará 10
C( slave1 )=2 :55+( 0: 10+(−0 :05))=3 :00
◦ Slave2. Como su diferencia fue -5 (está atrasado debe adelantarse) se
tomará 5
C( slave2 )=3 : 00+(0 :05+(−0 :05))=3 :00
x
◦ Slave3. Como su diferencia fue 20 (está adelantado debe atrasarse) se

tomará -20
C( slave2 )=3 :25+(−0 :20+(−0 :05))=3: 00
5. Teniendo los cálculos para cada máquina, se procede a ajustar relojes
C( master)=3 :00, C( slave1 )=3 :00 , C(slave2 )=3 :00,C (slave3 )=3 :00
Figura 2.2. El servidor indica el ajuste.
Se definen primero algunos términos y se hacen algunas suposiciones generales, t

representa el tiempo de Galileo universal; C(t) una función real derivable y ⍴ el valor
absoluto de la tasa de desviación máxima del reloj actual y del tiempo universal. Se
tiene entonces que:
dC (t)
1−≤ ≤1+ (1)
dt
Dos relojes se dice que están sincronizados en el tiempo t0 si sus funciones asociadas
tienen el mismo valor, es decir, si CA(t0)=CB(t0).
Si se define a R como una constante entonces se puede decir que dos o más relojes
están dentro del alcance de R en el tiempo t0 si la diferencia entre los dos, cualesquiera
de ellos, está delimitada por R:
|C A (t 0 )−C B (t 0)|≤R
Lema 1
Para t1 ≥ t0 :
(1−)(t 1−t 0)≤C (t 1)−C(t 0 )≤(1+)(t 1−t 0)
Lema 2
El valor absoluto de la tasa de desviación relativa de dos relojes cualquiera
satisfaciendo (1), es a lo más 2⍴.
|d⋅(C (t)−C
A
dt
(t))
|≤2
B
Demostración del Lema 2, primero se asume que el rejoj CA es rápido y el reloj CB es

lento.
d⋅C A (t ) d⋅C B (t)

≤1+ , ≥1−
dt dt
En este caso

- ≤ 2⍴
dt dt
En caso contrario, donde el reloj de CA es lento y el reloj de CB es rápido, de (1) se

obtiene:

- ≥ -2⍴ QD.
dt dt
Una consecuencia del lema 2 es:

Si dos relojes están sincronizados en un tiempo t 0, en cualquier tiempo
después t1, su valor puede diferenciar a lo más por ±2⍴(t1-t0).
3.2. Medición de diferencias de relojes

En un tiempo CA(t1) una máquina A envía un mensaje de etiqueta de tiempo a una
máquina B, y esta la recibe en un tiempo CB(t2), después B envía su acuse de recibo y A
lo lee en el tiempo CA(t3). La diferencia ∆AB(t) entre el reloj de la máquina A y el reloj de
la máquina B es:
C A ( t 1 )+C A (t 3 )
- C B (t 2)
2
Como ∆AB es una función del tiempo, su variación en el intervalo t3 - t1 es muy pequeña,
se puede escribir :
∆AB (t3) = ∆AB (t1) = ∆AB
Además, observe que ∆AB = - ∆AB.
Teorema 1
Sea TmAB y TmBA los tiempos mínimos posibles de transmisión de A a B y de
B a A respectivamente. Si se fija un límite TM ≥ 2max (TmAB, TmBA), en el tiempo
de ida y vuelta, es decir, CA(t3) - CA(t1) ≤ TM . Entonces, el máximo error en la
estimación de ∆AB es:
T M −2 min(T mAB , T mBA )

= ≥0 (2)
2
Corolario 1
El límite inferior para el error ɛ es:
ɛ ≥ |T mAB −T mBA|
x
Lo anterior de demuestra sustituyendo en la ecuación (2) la expresión de TM.
Corolario 2
El algoritmo de medición permite que una máquina pueda calcular la diferencia
de tiempo entre otras dos máquinas con un error máximo de 2ɛ.
Demostración
 AB=C A (t)−C B (t ) , EAB = AB± ,
 AC =C A (t )−C C (t) , EAC = AC ± ,
 BC= AC − AB , EBC =EAC −E AB .
Se deduce
EBC = AC − AB±2 = BC±2  QD.
3.3. Algoritmo de Sincronización

El maestro, usando el algoritmo de diferencia de relojes, calcula la diferencia de tiempo
entre el reloj y los relojes de los equipos esclavos. Una función de promedio de
tolerancia a fallos se aplica entonces a estas diferencias. Se seleccionan los conjuntos
más grandes de relojes que no difieren entre sí más que una pequeña cantidad ɤ y se
promedia las diferencias de estos relojes.
Para que el servidor de tiempo (maestro) sea confiable, es necesario que todos los
relojes que funcionen adecuadamente dentro de un rango de ɤ segundos cuando el
maestro inicia la ronda de sincronización. Por tanto, la constante ɤ es elegida en función
de la velocidad derivada del reloj.
Teorema 2
Si el maestro, usando el algoritmo anterior de sincronización se encarga de
sincronizar un número de máquinas, entonces cualquiera de los dos relojes no
defectuosos están, una vez que la sincronización es ejecutada, en un rango de
4ɛ.
Teorema 3
Si una máquina mide los tiempos ∆´s para un conjunto de máquinas y los
sincroniza cada T segundos, entonces, en cualquier momento, todos los relojes
no defectuosos están dentro del rango 4ɛ + 2⍴T.
4. Probabilidad de sincronización propuesta de Flaviu Cristian
Flaviu Cristian en su artículo “Probabilistic clock synchronization”, de 1989, supone que

cada máquina tiene un temporizador, el cual provoca una interrupción H veces por cada
segundo. Cuando este temporizador se detiene, el controlador de interrupciones suma 1
al reloj C. Entonces, si UTC=t, el valor del reloj en la máquina A será C A(t). En forma
ideal se tendría que CA(t)= t, es decir, dC/dt=1. Pero, como en la práctica no se realizan
exactamente las instrupciones H veces por cada segundo, y se puede estar alejado en
un intervalo [t, t’] con un error de a lo más ρ(t - t’), donde ρ es una constante llamada
tasa máxima de alejamiento especificada por el fabricante, entonces se tiene que:
1 - ρ (t – t’) ≤ H(t) - H(t’) ≤ 1 + ρ (t – t’)
Por lo que se dice que el temporizador trabaja dentro de un determinado rango.
4.1. Lectura del reloj remoto
Para leer el reloj de un proceso Q, un proceso P envía un mensaje de solicitud de

tiempo a Q. Cuando Q recibe el mensaje, responde con un mensaje de respuesta
colocando el tiempo T. Si P no recibe una respuesta entonces fallo en la lectura del reloj
de Q. Suponga que P recibe una respuesta y sea D la mitad del retardo de ida y vuelta
medido en el reloj P' entre el envío del mensaje de solicitud y la recepción del mensaje
de respuesta.
Teorema
Si los relojes de los procesos P y Q son correctos, el valor del reloj de Q, cuando
P recibe el mensaje de respuesta con el tiempo T, se encuentra en el
intervalo
[T +min(1−), T +2 D(1+2 )−min(1+)]
El teorema indica que P puede determinar el intervalo que contiene el valor del reloj Q
(CQ(t)) si 2D es el retardo de ida y vuelta. Como P no conoce exactamente dónde se
encuentra Q en el intervalo, lo mejor que puede hacer es una estimación de CQ(t), por
medio de T y D que sí son conocidos, C P (T , D) , por lo que el error de P se
Q
encuentra en |C QP ( T , D)=C (t)|
Q . Minimizando el error estimado de C Q(t) eligiendo
C P (T , D) como el punto medio del intervalo, se tiene que, ”P lee el reloj Q” en:
Q
C P (T , D)≡T + D(1+2 )−min()

Q
Lo anterior, con un error minimizado de ”precisión de la lectura P”:
e=D(1+2 )−min
Así, cualquier otra elección de estimación conduce a un error máximo mayor. Lo cual se
interpreta como, mientras más corto sea el retardo de ida y vuelta, menor es el error de
P al leer el reloj de Q. Por lo que, si se presenta un retardo de ida y vuelta mayor que
2U, donde:
U=(1−2 )(∈+min)
Se debe descartar cualquier intento de lectura del reloj, y con un retardo inferior a 2U se
puede lograr un precisión exitosa. Cuando más cerca esté U de min, mejor será la
precisión de lectura de P. Sin embargo, como en el peor de los casos, el temporizador
x
de P puede funcionar a una velocidad tan rápida como 1+ρ, P debe elegir un retraso de
tiempo de espera mayor que:
U min ≈min( 1+)
Para asegurar que entre el envío y la recepción de un mensaje exista un retardo en

tiempo real de al menos min. Por lo que, para lograr una mejor precisión con una
relación de probilidad positiva, P debe elegir un retardo de tiempo de espera lo más
cercano a U min como sea posible. Por lo que, para tal retardo de tiempo de espera, la
“precisión de lectura P” es:
e=3  min
Las dos primeras ρ corresponden a la desviación relativa entre los relojes Q y P

mientras el mensaje con el tiempo T viaja entre Q y P, y la tercera ρ corresponde al
error de P al establecer su retardo de tiempo de espera para que mida al menos min
unidades de tiempo real.
Sea p la probabilidad de que P observe un retraso de ida y vuelta mayor que 2U.
Cuanto mayor sea U, menor será p. Por el contrario, cuanto menor sea U, mayor será
p. Por lo tanto, existe una compensación fundamental entre la precisión alcanzable al
intentar leer un reloj remoto y la probabilidad 1-p de éxito. Cuanto mejor sea la precisión
deseada, menor será la probabilidad de éxito. Por el contrario, cuanto peor es la
precisión, mayor es la probabilidad de éxito. En el caso límite, si se conoce un retardo
máximo de mensaje en tiempo real max, estableciendo una precisión de lectura de reloj
remoto de max(1+3ρ)-minρ)-min)-min (correspondiente a un retardo de tiempo de espera de
max(1+ρ)-min)), se obtiene un algoritmo de lectura de reloj remoto determinista. El precio de
tal elección es la falta de precisión.
Considere ahora una cierta precisión especificada Ɛ y la probabilidad asociada p de que

falle un intento de lectura. Para esta precisión, la probabilidad de que el proceso P
alcance una relación con el proceso Q puede incrementarse si se permiten varios
intentos de lectura del reloj antes de que P se dé por vencido. Para lograr un cierto
grado de independencia entre intentos sucesivos, estos deben estar separados por un
retardo de espera mínimo W. Este retardo debe elegirse de modo que garantice que si
P y Q permanecen conectados y sin fallos, entonces cualquier tráfico de red transitorio
que se presente y que afecte su comunicación, desaparece dentro de W unidades de
tiempo de reloj con alta probabilidad. Para evitar que P intente, infinitamente, leer el
reloj de Q, cuando Q no está conectado con P o se encuentre bloqueado, se debe
decidir un valor máximo k para el número de intentos sucesivos que P puede realizar.
Para una elección dada de k, permitir hasta k intentos de lectura aumenta la
probabilidad de éxito a 1-pk. Dado que p<1, esta probabilidad puede hacerse
arbitrariamente cercana a 1, eligiendo una k suficientemente grande. Para valores
grandes de k y una elección de W que asegure la independencia entre intentos de
lectura sucesivos, la ley de Bernoulli produce que el número promedio de intentos de
lectura necesarios para lograr la relación sea (1-ρ)-min )-1. Dado que cada intento cuesta dos
mensajes, se deduce que el número medio de mensajes n̄ para lograr la relación es
2
n̄=
(1− p)
Las fórmulas e=D(1+2 )−min y la anterior indican la existencia de una colección

de diferentes algoritmos de lectura de reloj indexados según los diferentes retardos de
tiempo de espera U, desde algoritmos agresivos, pero arriesgados, indexados por U

cercanas al min que son capaces de lograr altas precisiones utilizando posiblemente un
número muy grande de mensajes, a algoritmos "deterministas" de bajo riesgo indexados
por U's cercanos a max que logran precisiones pobres usando una pequeña cantidad
de mensajes.
Referencias
[1] L. Lamport. “Time, Clocks, and the Ordering of Events in a Distributed
System”. Communications of the ACM. Vol. 21 No. 7. 1978.
[2] Riccardo Gusella y Stefano Zatti. “The Accuracy of the Clock Synchronization
Achieved by TEMPO in Berkeley UNIX 4.3 BSD”. 1987.
[3] Andrew S. Tanenbaum. “Sistemas Operativos Distribuidos”. Prentice Hall. 1996.
[4] F. Cristian. “Probabilistic clock synchronization”. Distributed Computer. Springer-
Verlag. 3. pp. 146-158. 1989.
REALIZAR:
Con base al artículo de Flaviu Cristian, Probabilistic clock synchronization,

1989.
1. Describa el método probabilistico para sincronizar relojes
2. ¿ Cómo trata los fallos de procesos, comunicación y relojes?
x
Capítulo III
Exclusión mutua
Para llevar a cabo la exclusión mutua el proceso debe proteger su sección crítica para
garantizar que ningún otro proceso utilice el recurso compartido. En los sistemas con un
procesador, las secciones críticas se protegen mediante semáforos, colas de mensajes,
o constructores similares; mecanismos que no se tienen en los sistemas distribuidos,
por lo que llevar a cabo la exclusión mutua necesita diferentes técnicas para que los
procesos de diferentes procesadores puedan utilizar los recursos compartidos.
1. Introducción
Según Michel Raynal en su artículo “A simple taxonomy for distributed mutual
exclusion algorithms”[1] de 1991, clasifica los algoritmos de exclusión mutua
distribuida en: basados en permisos, basados en tokens y el caso especial de
coordinador central. También, se puede decir que dentro de los algoritmos basados en
permiso, se encuentra la clasificación de los algoritmos basados en quorum (o mayoría),
los cuales suelen utilizarse cuando existen fallos en la comunicación. Desde 1997, Le
Lann, en su artículo “Distributed Systems: towards of a formal approach” y en el
artículo de Lamport “Time, clocks and the ordering of events in a distributed
systems” de 1978 [8], aportan algoritmos distribuidos para tratar de resolver el
problema de la exclusión mutua. Para ello, se considera que el sistema distribuido está
formado por n sitios (P1 a Pn) cuya comunicación entre procesos es sólo por mensajes,
y el retardo de las transferencias es finito pero impredecible.
Los algoritmos basados en permiso son plasmados por Ricart y Agrawala (1981) en su
artículo “An Optimal Algorithm for Mutual Exclusion in Computer Networks” [9] y
formalizada por Sanders (1987) en su artículo “The Information Structure of
Distributed Mutual Exclusion Algorithms” [10]. La idea de los algoritmos es muy
simple: cuando un proceso quiere entrar a la sección crítica pregunta a los demás si le
dan permiso para entrar, y espera hasta que todos otorguen el permiso. Si un proceso
no está interesado en la sección crítica este envía su permiso tan pronto como haya
recibido la solicitud. Si está interesado, se establece una prioridad entre las solicitudes
conflictivas.
En Ricart y Agrawala se propone un mecanismo de etiqueta (semejante al de Lamport)
asociado a cada solicitud y como las etiquetas (#Secuencia) son totalmente ordenadas,
los conflictos son fáciles de resolver en favor de la solicitud con la etiqueta mas baja, en
el caso de presentarse la igualdad, el conflicto se resuelve con base en el número de
nodo. En la propuesta, un proceso debe preguntar a un conjunto procesos
estáticamente definidos para que otorguen el permiso. Las mejoras al mecanismo
propuesto por Ricart y Agrawala están en la gestión y el tamaño del conjunto. Algunas
mejoras que plantean otros autores son:
1. El tamaño del conjunto varía dinámicamente para cada proceso. [2]

2. Elimina la necesidad de etiqueta de tiempo, usando un grafo acíclico dirigido (los
vértices son los procesos) representando solicitudes prioritarias. [3]
3. Protocolos de mayoría y basados en quorum. [4][5]
Por otra parte, Maekawa [6], usando una técnica basada en plano proyectivo finito,
reduce la complejidad a √ n y; Agrawala y El Abbadi [7] reduce a log ( n) usando
una estructura lógica de un árbol. Ellos asumen las siguientes propiedades:
1. La propiedad de seguridad (el estado de la exclusión mutua nunca es violada) es
garantizada obteniendo un número suficiente de permisos;
2. La propiedad liveness (cada solicitud se otorgará) es garantizada por el orden
total, cada solicitud está asociada con una etiqueta de tiempo o por la
administración de un grafo acíclico dirigido distribuido, los vértices son los
procesos solicitantes.
En la siguiente sección se analizaran los algoritmos basados en permiso, el algoritmo
propuesto por Lamport en su artículo “Time, Clocks, and Ordering of Events in
Distributed System” [8], y el algoritmo de Ricart y Agrawala propuesto en “An Optimal
Algorithm for Mutual Exclusion in Computer Networks” [9].
2. Algoritmo basado en permiso propuesto por Lamport

Lamport considera un sistema compuesto de una colección fija de procesos que
comparten un sólo recurso. Sólo un proceso puede usar el recurso en un tiempo, así
que deben sincronizarse para no entrar en conflicto.
Se debe encontrar un algoritmo que permita que un recurso sea usado por un proceso,
y que satisfaga las siguientes condiciones:
i. Al proceso que se le otorga el recurso debe liberarlo antes de que sea otorgado
a otro proceso.
ii. Las diferentes solicitudes del recurso deben ser otorgadas en el orden en el cual
fueron realizadas.
iii. Si cada proceso al cual se le otorga el recurso eventualmente lo libera, entonces
cada solicitud es eventualmente otorgada.
Supuestos:
• El sistema cuenta con un orden total de eventos.
• Para cualesquiera de dos procesos Pi y Pj, los mensajes enviados de Pi a Pj se
reciben en el mismo orden que fueron enviados.
• Todos los mensajes son recibidos.
• Cada proceso puede enviar mensajes directamente a cada uno de los demás
procesos.
• Cada proceso mantiene su propia cola de solicitudes, la cual nunca es conocida por
los demás procesos.
• Cada cola de solicitudes contiene inicialmente un sólo mensaje To:Po de solicitud de
recurso, donde Po es el proceso al cual se le otorga inicialmente el recurso y To es
menor que el valor inicial de cualquier reloj.
Algoritmo
x
Por conveniencia, las acciones definidas por cada regla se supone que forman un sólo
evento:
1. Para solicitar el recurso, el proceso Pi envía los mensajes Tm:Pi de solicitud de
recurso a todos los demás procesos y coloca el mensaje en su cola de
solicitudes, donde Tm es la etiqueta de tiempo del mensaje.
2. Cuando un Pj recibe el mensaje de solicitud de recurso Tm:Pi, lo coloca en su
cola de solicitudes y envía un mensaje (de etiqueta de tiempo) de acuse de
recibo a Pi
3. Al proceso Pi se le otorga el recurso cuando se satisfacen las dos condiciones:
i. Existe un mensaje Tm: Pi de solicitud de recurso en la cola de solicitud, el
cual está ordenado antes de cualquier otra solicitud por la relación ⇒
ii. Si Pi a recibido un mensaje de cualquier otro proceso la etiqueta de tiempo
recibida es más grande que Tm (las condiciones i e ii son pruebas locales de
Pi).
4. Para liberar el recurso, el proceso P i elimina cualquier mensaje de solicitud de
recurso Tm:Pi de su cola de solicitudes y envía un mensaje (de etiqueta de
tiempo) Pi de liberación de recursos a todos los demás procesos.
5. Cuando un proceso Pj recibe un mensaje Pi de liberación de recursos, este
elimina cualquier mensaje Tm:Pi de solicitud de recurso de su cola de
solicitudes.
3. Algoritmo basado en permiso propuesto Ricart y Agrawala

Este Algoritmo, es propuesto por Glenn Ricart y Ashok K. Agrawala en 1981 en su
artículo “An Optimal Algorithm for Mutual Exclusion in Computer Networks” [9],
para realizar exclusión mutua en un sistema distribuido. El algoritmo que proponen es
una extensión y optimización del algoritmo propuesto por Lamport [8] que usa 3(N-1)
mensajes, Ricart y Agrawala remueven la necesidad de los mensajes de liberación que
envían los procesos al terminar de utilizar la sección crítica, de esta forma logran la
exclusión mutua por medio de 2(N-1) mensajes. Para implantar este algoritmo se hacen
los siguientes supuestos:
1. Los nodos de la red funcionan correctamente y su comunicación está libre de
errores.
2. Los nodos se comunican vía mensajes y no comparten memoria.
3. El tiempo de transmisión de los mensajes es variado.
4. Los mensajes pueden ser entregados sin el orden en el cual fueron enviados.
5. Cada nodo ejecuta un algoritmo idéntico.
6. Todos los nodos tienen un ID único.
También se realizan las siguientes especificaciones para los N nodos que forman la red:
• El algoritmo idéntico en cada nodo tiene tres procesos para implementar la
exclusión mutua:
◦ P1. Se despierta cuando la exclusión mutua es invocada.
◦ P2. Recibe y procesa los mensajes de SOLICITUD.
◦ P3. Recibe y procesa los mensajes de RESPUESTA.
• Los tres procesos se ejecutan de forma asíncrona pero operan en un conjunto

de variables comunes. Se utiliza un semáforo para serializar el acceso a las
variables comunes cuando sea necesario. Si un nodo puede generar múltiples
solicitudes internas para exclusión mutua, debe tener un método para serializar
esas solicitudes.
Descripción del algoritmo

Un nodo entra en su sección crítica (SC) después que los demás nodos han sido
notificadas de la solicitud y hayan enviado una respuesta para conceder su permiso.
Un nodo que intenta de invocar la exclusión mutua envía un mensaje de SOLICITUD a
todos los demás nodos. Tras la recepción del mensaje de SOLICITUD, el otro nodo
bien envía una RESPUESTA inmediatamente o pospone una respuesta hasta después
de que sale de su propia sección crítica. El nodo solicitante entra en la sección crítica
después que los demás nodos han sido notificadas de la solicitud y han enviado una
respuesta para conceder su permiso.
El algoritmo se basa en el hecho de que un nodo que recibe un mensaje de
SOLICITUD puede determinar inmediatamente si el nodo solicitante o sí él mismo debe
permitirse ser el primero entrar a la sección crítica. Al nodo que origina el mensaje de
SOLICITUD nunca se le comunica el resultado de la comparación. Un mensaje de
RESPUESTA se devuelve de inmediato si el autor del mensaje de SOLICITUD tiene
prioridad, de lo contrario, la RESPUESTA se retrasa.
La decisión de orden de prioridad se hace mediante la comparación de un número de
secuencia presente en cada mensaje de SOLICITUD. Si los números de secuencia son
iguales, los números de nodo se comparan para determinar quién entrará primero.
Algoritmo
Un nodo entra a la sección crítica (SC) después que se les notifica (SOLICITUD) a
todos los demás nodos y envían una RESPUESTA
• Un Nodo (ni) que desea entrar a la SC

 Elige un número de secuencia (#seq)
• El número de secuencia es usado para la prioridad de primero en
entrar-primero en salir de la SC.
• Mientras más pequeño sea el #seq se tendrá mayor prioridad.
 Envía un mensaje de SOLICITUD (#seq, ID) a todos los demás nodos.
• Un nodo (nj) que recibe el mensaje de SOLICITUD

 Envía una mensaje de RESPUESTA al nodo ni solicitante si:
• el nodo nj no es solicitante o no está en la SC, o
• el nodo nodo nj ha solicitado la SC y ha enviado un mensaje de
SOLICITUD con un número de secuencia (#seq) mayor que el número
de secuencia del nodo ni solicitante.
 En otro caso el mensaje de RESPUESTA es detenido.
x
• Un nodo entra la SC sólo después de recibir los mensajes de RESPUESTA de

todos los demás nodos.
• Cuando un nodo sale de la SC
 Este envía los mensajes de RESPUESTA de todas las solicitudes
pendientes.
• Una solicitud de un nodo es bloqueada sólo por el nodo que solicita la SC con
prioridad alta, es decir, con el número #seq más pequeño.
• La ejecución de solicitud de SC se encuentra ordenada según su número de
secuencia.
Cada nodo en la red almacena la siguiente información en una estructura:

· ID único
· Número de secuencia elegido como parte del mensaje de SOLICITUD originado
por dicho nodo.
· El mayor número de secuencia encontrado en los mensajes de SOLICITUD.
· Contador de los mensajes de RESPUESTA en espera.
· ID´s de los nodos a los que hay que enviar mensajes de RESPUESTA.
Se deben hacer las siguientes anotaciones para el funcionamiento del algoritmo:
• El nodo con el número de secuencia más bajo es el siguiente en entrar a la SC.

• Los empates se rompen comparando el número ID del nodo.
• Un mensaje de RESPUESTA es enviado sólo después que den el
consentimiento a la solicitud de entrar primero a la SC.
• #seq y ID forman un orden virtual entre los nodos que hacen una solicitud.
4. Algoritmos basados en tokens – clasificación de Michel Raynal

La presente sección es basada en la información de Michel Raynal [1]. Estos algoritmos
indican que: ya que sólo un proceso a la vez puede entrar a la sección crítica, el
derecho es materializado por un único objeto especial (Propiedad de Seguridad)
conocido en el sistema, como el token. Debe también darse una administración para
mover el token de un proceso a otro con un orden para que cada solicitud sea
satisfecha (Propiedad liveness).
En este punto se debe considerar dos posibilidades: el movimiento perpetuo y el
método token-asking. En el movimiento perpetuo, el token viaja de un proceso a
otro para otorgar el derecho de entrar a la sección crítica (si el proceso no está
interesado en entrar a la sección crítica pasa el token al siguiente proceso en el anillo).
En el método token-asking, si un proceso quiere entrar a la sección crítica pregunta
por el token (si no es el propietario) y espera hasta que el token llegue.
Tanenbaum[11] menciona lo siguiente: las posiciones en el anillo se pueden asignar

según el orden numérico de las direcciones de la red o mediante algún otro medio.
El proceso para entrar a la sección crítica se lleva a cabo de la siguiente manera:
1. Al inicia el anillo, se le da al proceso 0 un token, el cual circula en todo el anillo
del proceso k al proceso k+1.
2. Cuando un proceso obtiene el token, de su vecino, verifica si quiere entrar a la

sección crítica, si este es el caso, el proceso entra y al salir pasa el token a
su siguiente vecino. No se permite entrar a una segunda sección crítica con el
mismo token. El token circulará mientras ninguno de los procesos desee entrar
a la sección crítica.
Las desventajas que presenta el algoritmo son:
1. Es difícil detectar si el token llega a perderse, debido a que la cantidad de
tiempo entre las apariciones sucesivas de el token en la red no está acotada.
2. Si falla un proceso, no podrá pasar el token, pero su recuperación se puede
lograr si se pide un reconocimiento al proceso que recibe el token.
Si su vecino intenta darle el token y fracasa en el intento, el proceso fallido se puede

eliminar del grupo y el poseedor de el token puede enviar el token por encima de él, al
siguiente miembro del grupo.
5. Coordinador central
La exclusión mutua más sencilla de implementar en un sistema distribuido se realiza por
medio de la designación de una máquina como el coordinador. Siempre que un proceso
desea entrar a una sección crítica, envía un mensaje de solicitud al coordinador,
indicando que desea entrar a una sección critíca. Si ningún otro proceso está en ese
momento en la sección crítica, el coordinador envía una respuesta otorgando el
permiso, y al llegar la respuesta al solicitante este puede entrar a la sección crítica
[11].
Suponga que el proceso P4 de la figura 1, pide permiso para entrar a la misma sección
crítica. El coordinador sabe que un proceso distinto ya se encuentra en esta sección,
por lo que no puede otorgar el permiso. El método de negación del servicio depende del
sistema, una alternativa es que el coordinador no responda, con lo cual se bloqueará el
proceso P4, que espera una respuesta, otra alternativa es enviarle una respuesta de
negación del servicio. Cuando el proceso P1 sale de la sección crítica, envía un mensaje
al coordinador para liberarla. El coordinador extrae a un proceso solicitante de la cola de
solicitudes y envía un mensaje al proceso solicitante para otorgarle el permiso. Si el
proceso estaba bloqueado, elimina el bloqueo y entra a la sección crítica.
Las desventajas de este método son:

1. La utilización del coordinador, dado que si él falla, todo el sistema puede fallar.
Si los procesos se bloquean por lo general después de realizar una solicitud, no
pueden distinguir entre un coordinador muerto y un permiso negado, puesto que
en ambos casos no se reciben mensajes de respuesta.
2. El coordinador se puede convertir en un cuello de botella en un sistema de gran
tamaño.
x
Figura 1. Tareas del Coordinador
Referencias
[1] Raynal Michel. “A simple taxonomy for distributed mutual exclusion

algorithms”. ACM Operating Systems Review. Vol. 25, No. 2. pp. 47-50. 1991.
[2] Carvalho O.S.F., Roucairol G. “On mutual exclusion in computer networks”.
Comm ACM. Vol. 26, No. 2, pp. 145-147. 1983.
[3] Chandy K. M., Misra J. “The drinking philosophers problem”. ACM Trans. on
Prog. Languages and Systems, Vol. 6, No, 4, pp. 632-646. 1984.
[4] Gifford D. K. W. “Weighted voting for replicated data”. Proc. 7th ACM
Symposium on Op. Systems Principles, pp. 150-159. 1989.
[5] Thomas R. H. “A majority consensus approach to concurrency control for
multiple copy databases”. ACM Trans. on Database Systems. Vol. 4, No. 2, pp. 180-
209. 1979.
[6] Maekawa M. A. ” √ n algorithm for mutual exclusion in decentralized
systems”. ACM Trans. on Comp. Systems. Vol. 3, No. 2, pp. 145-159. 1985.
[7] Agrawala D., El Abbadi A. “An efficient solution to the distrbuted mutual
exclusion problem”. Proc. 8th ACM Symposium on PODC, pp. 193-200. 1989.
[8] L. Lamport. “Time, Clocks, and the Ordering of Events in a Distributed
System”. Communications of the ACM. Vol. 21, No. 7. 1978.
[9] Glenn Ricart and Ashok K. Agrawala. “An Optimal Algorithm for Mutual Exclusion in
Computer Networks”.. Communications of the ACM. Vol. 24, No. 1. 1981.
[10] Sander Bervely. “The Information Structure of Distributed Mutual Exclusion
Algorithms”. ACM Transaction on Computer Systems. Vol. 5, No. 3, pp. 284-299. 1987.
[11] A. S. Tanenbaum. “Sistemas Operativos Distribuidos”. 1a. Edición. Prentice-Hall,
1996, pp. 134-141.
REALIZAR:
1. Programar los algoritmos de Lamport y Ricart & Agrawala para un conjunto de n

maquinas (n>=3)
Capítulo IV
Elección
Muchos algoritmos distribuidos necesitan que un proceso actúe como coordinador,
iniciador, secuenciador o que desempeñe de alguna forma un papel especial de líder de
un grupo. Pero, si todos los procesos son idénticos, sin ninguna característica que los
distinga, no existe forma para elegir a uno de ellos como especial. Para esto, se supone
que cada proceso tiene un identificador único, y a partir de ello se toma la decisión de
elección. El objetivo de una elección es garantizar que al iniciar dicho proceso esta
concluya con el acuerdo de todos y se designe al líder.
1. Introducción
Después de un fallo en el sistema distribuido es frecuentemente necesario reorganizar a
los nodos activos para que continúen la ejecución de las tareas, y el primer paso para la
reorganización es elegir a un nodo coordinador para administrar las operaciones.
Hay al menos dos estrategias básicas que pueden adaptarse cuando se presentan los
fallos:
1. Tener un software que pueda operar continuamente, y cuando se presente un
problema este pueda ser reparado.
2. Realizar temporalmente una operación de paro y tomar un tiempo fuera para
reorganizar el sistema (durante este tiempo los componentes de estado del
sistema pueden ser evaluados, cualquier trabajo pendiente puede ser finalizado
o descartado, y puede ser seleccionado algún algoritmo para tratar la situación
que ocurre).
En la presente sección se mostrará la propuesta de García-Molina (1982) en su artículo

“Elections in a Distributed Computing System”. [1]
2. Elección en un sistema distribuido propuesta de García-Molina

La reorganización del sistema es administrada por un sólo nodo llamado el
Coordinador, de está manera lo primero en cualquier reorganización es elegir quién
será el coordinador de los nodos activos. La elección de un coordinador es básicamente
un problema de sincronización de procesos paralelos. Cuando no existe fallo de
comunicación, la elección de un coordinador es similar al problema de exclusión mutua.
Los tipos de fallos que pueden ocurrir juegan un papel importante en la elección del
protocolo, y tratar de protegerse contra todos los posibles fallos es algo impráctico; por
lo que primeramente hay que tratar el punto de cómo se comportarán los nodos, el
software de cada nodo, y el sistema de comunicación. Por lo que se hacen las
siguientes suposiciones:
x
Suposición 1: Todos los nodos cooperan y usan el mismo algoritmo de elección.
Suposición 2: El algoritmo de elección de cada nodo debe hacer uso de ciertas

facilidades que brinda el software: sistema operativo local, manipulación de mensajes,
software sin bugs, y servicios propios.
Suposición 3: Si un nodo i recibe un mensaje M de un nodo j, entonces este

mensaje M fue enviado por j al nodo i en un tiempo anterior. De está manera se asume
que el subsistema de comunicación no genera espontáneamente mensajes.
Suposición 4: Todos los nodos tienen algunas (posiblemente limitada) celdas de

almacenamiento seguras. Los datos almacenados en estas celdas seguras sobreviven
a cualquier fallo del nodo. Cada actualización es ejecutada correctamente en la celda.
Suposición 5: Cuando un nodo falla (es decir, cuando su procesador o su memoria

no segura falla) entonces inmediatamente detiene todos los procesamientos. Algún
tiempo después, el procesador del nodo es reiniciado a un estado previamente fijado y
retoma la ejecución a partir de dicho estado.
Suposición 6: No existen error de transmisión. Esto es, si un mensaje M es enviado

y recibido, entonces el mensaje recibido es precisamente M. Los errores de transmisión
pueden ser detectados y corregidos sumando redundancia a M.
Suposición 7: Todos los mensajes del nodo i que llegan al nodo j, son procesados
en j en el mismo orden en el cual ellos son enviados. Esto pueden ser garantizado por
el número de secuencia añadido a los mensajes.
Las siguientes suposiciones simplifican el diseño del protocolo de elección:
Suposición 8: Los subsistemas de comunicación no presentan fallos. El subsistema

tiene un tiempo límite T en el cual se garantiza que un mensaje debe ser entregado si el
nodo destino está activo, es decir, si un nodo i desea enviar un mensaje M a un nodo j,
el nodo i entrega a M al subsistema de comunicación, si después de T segundos el
nodo i no recibe un acuse de recibo del subsistema de comunicación indicando que M
fue recibido por el nodo j, entonces el nodo i conoce con certeza que el nodo j está
defectuoso.
Suposición 9: Un nodo nunca pausa y siempre responde a los mensajes que le

llegan, sin retardo.
Notación
El vector de estado de un nodo i, S(i), es una colección de celdas de almacenamiento
seguras, las cuales contienen datos cruciales para los algoritmos de elección y
aplicación.
Los principales componentes de un vector de estado S(i) son:

1. S(i)∙s que será el estado de un nodo i, que puede ser
S(i)∙s = “Abajo” o
S(i)∙s = “Elección” o
S(i)∙s = “Reorganizar” o
S(i)∙s = “Normal”
Si S(i)∙s = “Abajo” entonces el nodo i fue detenido por la presencia de un fallo,

independientemente de lo que se almacene en la celda, y fue reiniciado a un estado
fijado previamente. El estado del nodo se coloca en S(i)∙s = “Abajo” desde que nodo i
falla hasta que inicia la elección.
Si S(i)∙s = “Elección” entonces el nodo i está participando en una elección.
Si S(i)∙s = “Reorganizar” el nodo i está participando en una reorganización. Se hace

notar que una reorganización sigue después de la elección de un coordinador. Entonces
los nodos en el estado de reorganización conocen la identidad del coordinador, pero no
conoce que tareas deben ser ejecutadas.
Si S(i)∙s = “Normal”, el nodo i está trabajando en una operación normal, es decir,

realizando alguna tarea.
2. S(i)∙c indicará que el coordinador será del nodo i, entonces

Si S(i)∙c = i, indica que el nodo i se considera así mismo como el coordinador.
3. S(i)∙d indicará la tarea definida que iniciará la ejecución en el nodo i. Esto usualmente
incluye los algoritmos de las aplicaciones que inician la ejecución, una lista de los nodos
participantes, y otros estados de información.
Elección sin fallos de comunicación y sin pausas de nodos
Un protocolo de elección debe seguir un conjunto de reglas en forma ordenada para ser
considerado como un “buen” protocolo.
1. Suponga que se tienen dos nodos i y j, y que en algún instante de tiempo

S(i)∙s=“Reorganizar”=S(j)∙s y S(i)∙c≠S(j)∙c. Claramente, esta situación no es deseable
porque se tienen dos nodos que no tiene convenio sobre el coordinador. Pero la
situación donde S(i)∙s=“Abajo” o S(j)∙s=“Abajo” y donde S(i)∙c≠S(j)∙c es aceptable
porque uno de los nodos no está realizando ninguna tarea. De esto se desprenden las
siguientes afirmaciones:
Afirmación 1: En cualquier instante de tiempo, para cualquiera de dos nodos i y j en

el sistema distribuido, se cumple lo siguiente:
a) Si (S(i)∙s=“Reorganizar” o S(i)∙s=“Normal”) & Si (S(j)∙s=“Reorganizar” o
S(j)∙s=“Normal”)
entonces
S(i)∙c = S(j)∙c
b) Si (S(i)∙s=“Normal” & S(j)∙s=“Normal”)
entonces
S(i)∙d = S(j)∙d
El hecho de que S(i)∙d es igual a S(j)∙d bajo la operación normal no quiere decir que
todos los nodos se les asigna exactamente el mismo conjunto de tareas.
Afirmación 2: Si no ocurren fallos durante la elección, el protocolo de elección querrá

eventualmente transformar al sistema de un estado a otro estado, donde:
a) Existe un nodo i con
S(i)∙s=“Normal” y S(i)∙c=i; y
x
b) Para todos los nodos j los cuales no son defectuosos

S(j)∙s=”Normal” y S(j)∙c= i
2.1 Algoritmo de Elección Bully

El algoritmo se llama así porque el nodo con el identificador mayor fuerza a los nodos
con los números de identificador menores a reconocerlo como su Coordinador.
Asumiendo que el identificar de los nodos se encuentra entre 1 y n.
En este acercamiento se supondrá que si un nodo llega a fallar se debe quedar fuera de
la elección de el coordinador para siempre. Si un nodo i descubre que el coordinador
está deshabilitado tratará de reemplazarlo.
El protocolo de elección en el nodo i es dividido en dos partes:

1) Si el nodo i intenta contactar a todos los nodos con prioridad más alta, es decir,
todos los nodos con número de identificación j tal que i<j≤n, donde n es el número
de nodos en el sistema.
Si cualquiera de estos nodos responde, el nodo i da la bienvenida al nuevo

coordinador y espera hasta que el nodo con prioridad más alta llega a ser el nuevo
coordinador (Después de espera por algún tiempo noticia de algún coordinador, el
nodo i debe reiniciar el protocolo de elección). En otro caso, si todos los nodos con
prioridad más alta no responden después de un tiempo límite de T segundos,
entonces el nodo i pueden garantizar que todos ellos tienen un fallo. Por las
anteriores suposiciones, los nodos fallidos deben reiniciarse. Entonces para i<j≤n,
S(j)∙s =”Abajo”.
Tan pronto como el nodo i completa la primera parte del protocolo, este debe
asumir el trabajo de ser coordinador.
2) Para informar a todos los nodos con prioridad más baja que es el coordinador,
el nodo i en la segunda parte del algoritmo de elección debe proceder en dos
pasos:
i) Desde que el nodo i no conoce el contenido de los vectores de estado de los
nodos con prioridad menor, fuerza a estos nodos a entrar “a un fallo simulado”.
Enviando un mensaje de “Paro” a los nodos k, el nodo i hace que un nodo k pare
cualquier procesamiento y coloque S(k)∙s=“Elección”. Desde que todos los nodos
están en un estado conocido, el vector de estado puede ser modificado.
ii) El nodo i envía el mensaje “Yo fui electo” a los nodos con prioridad menor.
Cuando el nodo k recibe el mensaje, este coloca S(k)∙s=“Reorganizar”.
Ahora que la elección es cubierta, el nodo i fija

S(i)∙c=i y S(i)∙s =“Reorganizar”.
Durante la reorganización, el nodo i distribuye los nuevos algoritmos a los nodos

(es decir, S(k)∙d ) y todos los estados se cambian a “Normal”.
Teorema 1
En un ambiente donde tenemos las suposiciones 1 al 9, el algoritmo de
Bully satisfacen las afirmaciones 1 y 2.
Elección con fallo en la comunicación y nodos pausados

Ahora se muestra en un ambiente donde las suposiciones del 1 al 7 son sólo válidas.
Por lo que se debe redefinir el significado de una elección. Los nodos en el sistema
pueden ser particionados en dos o más grupos de nodos aislados, donde los nodos
dentro del grupo pueden comunicarse unos con otros, pero no pueden comunicarse con
nodos de otros grupos. Algunos nodos pueden ser habilitados para enviar mensajes
hacia a fuera pero no recibirlos o viceversa.
Dos nodos i y j pueden habilitarse para comunicarse con un tercer nodo, pero al mismo
tiempo el nodo i y el nodo j pueden deshabilitarse para comunicarse con otro. Un nodo
puede parar los procesamientos en cualquier tiempo en un periodo arbitrario, y después
iniciar el procesamiento como si nada hubiese pasado.
Con las fallas anteriores es imposible elegir a un coordinador en el sentido de las

afirmaciones 1 y 2. Esto es, un nodo nunca puede garantizar que es el único nodo y
considerarse así mismo como el coordinador.
Teorema 2
En un sistema distribuido que no satisface las suposiciones 8 y 9, no
existe un protocolo de elección que satisfaga las afirmaciones 1 y 2.
Grupos de nodos
A continuación se introduce la notación de número de grupo en un conjunto de nodos
que se encuentran activos. Cualquier grupo de nodos que tienen, de algún modo, que ir
a juntos a una elección de coordinador y trabajan sobre una tarea común o alguna
manera se identifican con un único número de grupo. Todos los mensajes
intercambiados por los nodos de un grupo contienen el número del grupo, así que un
nodo puede ignorar los mensajes que pueden ser generados por otros grupos.
Notación
Se asume que un nodo i tiene su número de grupo en su vector de estado S(i). Así que
S(i)∙g será el número del grupo del nodo i.
Usando el número del grupo, se puede establecer la afirmación que debe ser satisfecha
por los protocolos de elección. Todos los nodos en un mismo grupo deben tener el
mismo coordinador.
Afirmación 3: En cualquier instante de tiempo, para cualquiera de dos nodos i y j en

el sistema distribuido, se cumple lo siguiente:
a) Si (S(i)∙s=“Reorganizar” o S(i)∙s=“Normal”) &
(S(j)∙s=“Reorganizar” o S(j)∙s=“Normal”) &
S(i)∙g=S(j)∙g
entonces
S(i)∙c=S(j)∙c
b) Si S(i)∙s= S(j)∙s= Normal” & S(i)∙g=S(j)∙g
entonces
S(i)∙d=S(j)∙d
El hecho de que S(i)∙d es igual a S(j)∙d bajo la operación normal no quiere decir que
todos los nodos se les asigna exactamente el mismo conjunto de tareas.
x
Afirmación 4: Suponga que se tiene un conjunto R de nodos operando, los cuales

tiene dos caminos de comunicación con todos los elementos de R. Estos es, para los
nodos en R las suposiciones 8 y 9 son ciertas. Además, se asume que no existe un
superconjunto R con estas propiedades. Si no ocurren fallos durante la elección, el
algoritmo de elección querrá eventualmente transformar los nodos en el conjunto R de
cualquier estado a otro estado, donde:
a) Existe un nodo i en R con

S(i)∙s=“Normal” y S(i)∙c=i; y
b) Para todos los nodos j en R
S(j)∙s=”Normal”, S(j)∙c=i y S(j)∙g=S(i)∙g
2.2 Algoritmo de Elección por invitación

Se presenta un algoritmo de elección que satisface las afirmaciones 3 y 4 en un
ambiente donde sólo se cumplen las suposiciones del 1 al 7. En el algoritmo de Bully el
nodo activo con prioridad alta, “fuerza” a todos los demás nodos a abstenerse de tratar
de llegar a ser el coordinador, de está manera asume con éxito la elección.
En el caso donde se presentan fallos en el sistema, lo que se realiza es que los nodos
que desea llegar a ser coordinador deben “invitar” a otros nodos a formar un nuevo
grupo. El nodo que recibe la invitación puede aceptar o declinar dicha invitación.
Cuando acepta la invitación el nodo modifica su vector de estado para juntarse con un
nuevo grupo. Para simplificar el algoritmo, se toma en consideración que un único nodo
puede formar un grupo y por lo tanto él será coordinador.
Ejemplo: Suponga que se tienen 6 nodos y el nodo 6 es el coordinador. En un

instante de tiempo el nodo 6 deja de funcionar, dejando a los otros 5 sin coordinador y
estos se pueden comunicar. Cada uno de los 5 nodos se da cuenta que el coordinador
fallo, y cada uno de ellos forma un grupo.
El coordinador de cada grupo periódicamente busca alrededor del sistema si hay otros
grupos los cuales quieren unirse a este. Para evitar que todos los coordinadores envíen
invitaciones a los demás, se implementa un mecanismo que utilice una prioridad para
que los de baja prioridad dejen de enviar invitaciones por un largo periodo de tiempo.
Ahora, suponga que, el nodo 4 y 5 creyeron que ellos son los coordinadores con
prioridad más alta, envían invitaciones al resto de los coordinadores. El nodo 3 acepta la
invitación del nodo 4, mientras el nodo 1 y 2 aceptan la invitación del nodo 5. Entonces
de esta manera se forman dos nuevos grupos. Después de un tiempo, uno de los dos
coordinadores invita al otro a unirse con su grupo, y al final se puede tener un sólo
grupo con un sólo coordinador.
Hay dos ideas principales en el algoritmo de invitación:

1. Los nodos recuperados de un fallo forman un sólo grupo nuevo; y
2. Los coordinadores periódicamente tratan de combinar sus grupos con
otros grupos para formar un grupo más amplio.
Teorema 3
En un ambiente donde las suposiciones 1 al 7 se satisfacen, el
algoritmo de Invitación satisface las afirmaciones 3 y 4.
3. Algoritmos de elección en un anillo – Le Lann, Chang&Roberts, y

Frederickson&Lynch
En está sección se presentan los algoritmos de elección de líder propuestos por Le
Lann [4], Chang y Roberts [2], y de Frederickson y Lynch [2], los cuales asumen un
anillo unidireccional asíncrono con procesos que tienen un identificador único.
Gérard Le Lann es su artículo “Distributed Systems-Towards a formal Approach” de

1977, plantea un algoritmo de elección en una disposición circular aleatoria de
controladores. Supone que los controladores tienen un orden, físico o lógico, de modo
que cada uno conoce a su sucesor. Cuando algún controlador, después de un tiempo
de espera, observa que el coordinador no funciona, construye un mensaje elección con
su propio número de controlador y envía el mensaje a su sucesor. Si éste está inactivo,
el emisor pasa sobre el sucesor y va hacia el siguiente controlador o al siguiente de
éste, hasta que localiza un controlador en ejecución. En cada paso, el emisor añade su
propio número de controlador a la lista en el mensaje. Cada controlador recoge así, a
través de los mensajes vistos, los números de los otros controladores del anillo. Cada
controlador ordena su lista, y el controlador cuyo propio número es el más alto en su
lista es elegido. En cierto momento, el mensaje regresa al controlador que inicio. Ese
controlador reconoce este evento cuando recibe un mensaje de entrada con su propio
número. En este punto, el mensaje cambia a coordinador y circula de nuevo, esta vez
para informar a todos quién es el coordinador (el miembro de la lista con el número
máximo) y quiénes son los miembros del nuevo anillo. El algoritmo de Le Lann, requiere
el total de mensajes enviados proporcional a n2, O(n2).
Por otra parte, Ernest Chang y Rosemary Roberts en 1979, plantean en “An improved
algorithm for decentralized extrema-finding in circular configurations of processes”, un
esquema basado en Le Lann, para reducir el número de mensajes a O(n log n). El
algoritmo supone que cada proceso conoce su propio número, e inicialmente genera un
mensaje con su propio número, pasándolo a la izquierda. Un proceso que recibe un
mensaje compara el número del mensaje con el suyo. Si su número es más bajo, el
proceso pasa el mensaje (a su izquierda). Si su propio número es mayor, el proceso
descarta mensaje que le llegó y envía el mensaje con su número. Si llega un mensaje
con su propio número, es decir igual al suyo, entonces es el proceso con el número más
alto del sistema. El algoritmo detecta uno y sólo uno número más alto. Por la naturaleza
circular de la configuración y la dirección consistente de los mensajes, cualquier
mensaje debe cumplir con todos los demás procesos antes de regresar a su iniciador.
Sólo un mensaje, el que tiene el número más alto, no encontrará un número más alto en
su camino. Por lo tanto, el único proceso que recibe su propio mensaje es el que tiene
el número más alto y será el líder.
Los casos en el paso de mensajes:
1. Mejor de los casos. Los procesos son ordenados en el sentido de las agujas del reloj
en una secuencia de incremento, de modo que cada mensaje (excepto el mensaje n)
sólo viaja una vez en el anillo. Hay n-1 de estos, mientras el mensaje n requiere n
pasadas. Por lo tanto, el número total de mensajes que viajan son n + n-1 = 2n-1.
2. Peor de los casos. Los procesos son ordenados en el sentido de las agujas del reloj
en una secuencia decreciente, de modo que el mensaje i debe pasar i veces en el
n
n(n+1)
anillo. Así, el total de mensajes que viajan son ∑ i= 2
i=1
x
3. Caso promedio. La probabilidad de un mensaje i en una ronda (o pasada) en k

tiempo, P(i,k), puede ser que sea k-1 veces menor que i, y k veces mayor que i. Hay
etonces i-1 procesos menores que i y n-i procesos mayores que i. Conociendo que el
mensaje n realiza n rondas (pasadas), y existe sólo uno de ellos, se considera sólo n-1
mensajes viajando, como máximo, teniendo así n-1 pasadas. Por lo tanto, el número
esperado de pasadas del mensaje que no sea n es:
n−1
Ei (k )=∑ k P(i ,k ) para i≠n
k=1
Por cual, el número esperado de pasadas del mensaje, para todos los mensajes, es
n−1 n−1 n−1
n 1 1 1
E( k)=n+ ∑ ∑ k P(i , k )=n+ ∑ ( )=n(1+ + + ...+ )
i=1 k=1 k=1 k +1 2 3 n
La serie armónica tiene una suma parcial de C + log en, por lo cual, el número promedio
de mensajes es O(n log n).
Otro algoritmo de elección descrito por Frederickson y Lynch en el artículo de 1987

llamado “Electing a Leader in a Synchronous Ring”, se basa en el uso de un anillo de n
procesadores. El algoritmo propuesto usa el orden O(n) de mensajes en el peor de los
casos y una comparación de mensajes de identificadores de Ω(n log n) como límite
inferior de los casos. Además, puede ser implementado en un modelo síncrono o
asíncrono usando solamente comparaciones de un entero que identifica al procesador
(llamado ID). A continuación se describe lo propuesto por Frederickson y Lynch.
El algoritmo usa un orden de O(n) mensajes pero puede requerir un gran número de
rondas. El procesador elegido, y sólo él, entra al conjunto de estado “elegido”. El
número total de mensajes, incluyendo cualquier mensaje que deba ser enviado después
de ganar la elección es O(n). El algoritmo es para un anillo unidireccional, pero puede
ser aplicado para anillo didireccional, asumiendo que la comunicación se realiza en
sentido contrario al de las agujas del reloj. El IDi único del procesador i es un entero. El
algoritmo es iniciado por un procesador que decide libremente despertarse. La
restricción es que no se permite que ningún procesador (participante en la elección)
inicie una elección después de recibir un mensaje del procesador que inicia la elección.
Cuando un procesador despierta para la iniciar la elección genera un mensaje, que se

mueve alrededor del anillo, llevando la ID del procesador de origen. Al mensaje se le
añade el ID por cada procesador que pasa.
Las dos ideas que maneja el algoritmo son:
1. Los mensajes que se originan en los diferentes procesadores se transmiten en

velocidades diferentes: el mensaje que lleva el ID del procesador i se transmite a una
velocidad de 2i rondas (es decir, un retardo de 2i-1 rondas antes de que el procesador i
transmita el mensaje). Cualquier mensaje más lento que es superado por un mensaje
más rápido es eliminado. Un mensaje i con un ID que llega al procesador j es eliminado
si j<i, y el procesador j genera el mensaje. Un mensaje que retorna a su originador
indica que es el elegido. Se supone que todos los participantes se levantan en la misma
ronda de elección (con esto se garantiza que O(n)). Veamos, considere que el
procesador i es el ID más pequeño que participa, porque el mensaje i viaja por todos los
procesadores a un costo de n. Considere otro mensaje j, y este es superado por el
mensaje i o el mensaje j lleva al procesador i, en cada caso el mensaje j es eliminado

cuando se completa el recorrido de i. Debido a las diferentes velocidades de transmisión
el mensaje j podría viajar una distancia máxima de n/(2j-i) durante el tiempo que el
mensaje i recorre la distancia n. Sumando todos los mensajes, el número es menor a
2n.
2. Se tiene una fase preliminar para cada proceso de mensaje. En esta fase todos los
mensajes viajan a la misma velocidad, una transmisión de mensaje por ronda. Cuando
un procesador decide que desea participar genera un mensaje y lo envía a su vecino. El
mensaje viaja por el anillo hasta que encuentra al siguiente procesador participante.
Después de ello continua con la fase que se describió en el punto 1.
Teorema 1.
Existe un algoritmo de elección de líder en un anillo síncrono de n procesadores
que usa menos que 4n mensajes y un tiempo O(n2i), donde i es el ID del
eventual ganador.
Los mensajes se dividen en tres categorias separadas:
1. Mensajes para saber quienes serán los participantes, n mensajes, después de un
tiempo de n rondas pasan a la segunda categoría.
2. Mensajes para buscar quien será el líder, dentro de los participantes, n/2j como
máximo de mensajes para j>0, lo cuál es menor que n.
3. Mensajes para notificar al ganador, n/2j-i mensaje j en un tiempo i en un recorrido n, lo
cuál es menor que 2n.
Por lo que el total de mensajes (sumando los mensajes de las tres categorías) es menor
que 4n y como la velocidad de trasmisión es variable el número de rondas requeridas es
O(n2i) donde i es el ID del eventual ganador.
Teorema 2.
Dado c>1. Existe un algoritmo de elección de líder en un anillo síncrono de n
procesadores que usa menos que 2cn/(c-1) mensajes y un tiempo O(nci), donde
i es el más pequeño ID de los procesadores en el anillo.
Algoritmo
Suposiciones:
1. Cada procesador es idéntico a todos los demás, excepto su identificador (ID).
2. Cada ID es único y es elegido de un espacio X, que está completamente ordenado.
Dichos ID serán de 0 a n-1.
3. Todos inician su algoritmo de elección al mismo tiempo.
4. Todos parte de un estado inicial (que será simplemente su ID), para pasar de un
estado a otro, examina su estado para decidir si envia un mensaje a su vecino y si
recibido mensaje de su vecino.
5. Existe un estado llamado “elegido”
6. Un tamaño de anillo n sobre el espacio X de ID es una n-tupla de elemetos de X.
7. Un vector de mensajes de tamaño n es una n-tupla de pares ordenados de L(X) U
{Null}.
x
Un algoritmo de anillo está en forma normal, si cada procesador registra exactamente

su ID, y el historial de mensajes recibidos. Cada mensaje que se envía contiene el
estado completo del procesador emisor. El histórico es un expresión S bien formada
sobre X que: 1) es un elemento de X, ó 2) es una expresión de la forma (s 1, s2, s3),
donde s2 es una expresión bien formada sobre X, y cada s 1 y s3 es una expresión bien
formada sobre X o es NULO. Así se tiene que L(X) el conjunto de expresiones bien
formadas sobre X.
Un estado inicial de un procesador es simplemente su ID. Cada mensaje contendrá

exactamente el estado del procesador que envía. Cuando un procesador en el estado s
recibe un mensaje de sus vecinos a la izquierda y derecha (a favor y en contra de las
manicellas del reloj) s1, y s2, respectivamente. Su nuevo estado se formará como la
expresión S=(s1, s, s2), o Nulo en el lugar donde no se reciba mensaje del vecino. Se
tendrá una función para determinar cuando los mensajes son enviados en cualquier
dirección, y una designación de que estados indican cuando el procesador es elegido.
Así, un algoritmo sobre X es un par (E, μ) donde E⊆μ es un conjunto de estados de
elección y μ es un mapeo de L(X) x {a favor de las manecillas, en contra de las
manecillas} a {si, no}, será la función generadora de mensajes. El conjunto E de estados
elegidos será cerrado por lo qué una vez que se ha elegido un procesador este seguirá
siendo electo.
Referencias
[1] García-Molina. “Elections in a Distributed Computing System”. IEEE Transactions on
Computers, Vol. 31, No.1. 1982.
[2] Greg N. Frederickson, and Nancy A. Lynch. “Electing a Leader in a Synchronous
Ring”. Journal of the Association for Computing Machinery, Vol. 34, No. 1. 1987.
[3] E. Chang, and R. Roberts. “An Improved Algorithm for Decentralized Extrema-
Finding in Circular Configurations of Processes”. ACM Communications, Vol. 22, No. 5.
1979.
[4] G. Lee Lann. “Distributed Systems-Towards a formal approach”. IFIP Congress
Proceedigs. 1977.
REALIZAR:
1. Suppose that two processes detect the demise of the coordinator simultaneously and
both decide to hold an election using the bully algorithm. What happens?
2. To achieve totally-ordered multicasting with Lamport timestamps, is it strictly
necessary that each message is acknowledged?
3. In Fig. 6-21 we have two ELECTION messages circulating simultaneously. While it
does no harm to have two of them, it would be more elegant if one could be killed
off. Devise an algorithm for doing this without affecting the operation of the basic
election algorithm.
4. In the centralized approach to mutual exclusion (Fig. 6-14), upon receiving a message
from a process releasing its exclusive access to the resources it was using, the
coordinator normally grants permission to the first process on the queue. Give
another possible algorithm for the coordinator.
x
Capítulo V
Deadlock
Los bloqueos en los sistemas distribuidos son similares a los bloqueos en los sistemas
con un procesador, sólo que peores. Son más difíciles de evitar, prevenir e incluso
detectar, además de ser más difíciles de eliminar cuando se les sigue la pista, puesto
que toda la información relevante está dispersa en muchas máquinas. En ciertos
sistemas, como los sistemas de bases de datos, los bloqueos pueden ser en extremo
serios, por lo que es importante comprender sus diferencias con los bloqueos ordinarios
y lo que se puede hacer con ellos.
1. Introducción
Los deadlocks son un problema fundamental en los sistemas distribuidos. Un proceso
puede solicitar recursos en cualquier orden, el cuál puede no ser conocido a priori y un
proceso puede solicitar recursos mientras tiene otros recursos. Si la secuencia de las
asignaciones de los recursos a los procesos no se controla, pueden ocurrir deadlocks.
Un deadlock es un estado donde un conjunto de procesos solicitan recursos que están
en manos de otros procesos del conjunto.
2. Modelo del sistema

Un programa distribuido está compuesto de un conjunto de n procesos asíncronos P 1,
P2, ..., Pi, ..., Pn, que se comunican en la red por paso de mensajes. En forma general
se asume que cada proceso está ejecutándose en diferente procesador. Los
procesadores no comparten una memoria global común y se comunican solamente por
medio de paso de mensajes en la red. No existe físicamente un reloj global en el
sistema al cual los procesos tendrían acceso de forma instantánea.
El medio de comunicación pueden entregar mensajes fuera de orden, los mensajes

pueden ser perdidos o duplicados y retransmitidos, los procesadores pueden fallar y
los enlaces de comunicación pueden caerse.
Se realizan los siguiente supuestos:
• Los sistemas tienen solamente recursos reutilizables.
• A los procesos se les permite tener solamente acceso exclusivo a los recursos.
• Existe solamente una copia de cada recurso.
Un proceso puede estar en alguno de los siguientes estados: ejecución o bloqueado.

En el estado de ejecución (además llamado estado activo), un proceso tiene todos los
recursos necesarios y los utiliza para su ejecución o lee de ellos para su ejecución. En
el estado de bloqueado, un proceso está en espera de adquirir algún recurso.
3. Wait-For-Graph (WFG)
En esta sección se mostrará la aportación de Selvaraj Srinivasan y Rajaram de su
artículo, A decentralized deadlock detection and resolution algorithm for generalized
model in distributed systems, del 2011. Ellos proponen que el estado de un sistema
puede ser modelado por un grafo dirigido, llamado un wait for graph (WFG). En un
WFG , los nodos son procesos y existe un lado dirigido de un nodo P 1 a un nodo P2, si
P1 está bloqueado es porque espera a que P2 libere algún recurso. Un sistema está
bloqueado si y sólo si existe un ciclo dirigido o nudo en el WFG.
Figura 1. Ejemplo de un WFG
La Figura 1 muestra un WFG, donde un proceso P11 del sitio 1 tiene un lado al proceso
P21 del sitio 1 y otro lado P 32 del sitio 2, está esperando entonces un recurso el cuál
actualmente es retenido por el proceso P21, y al mismo tiempo el proceso P32 está
esperando que le proceso P33 libere un recurso. Si P21 es esperado por el proceso P11,
entonces los procesos P11, P32 y P21 forman un ciclo y los 4 procesos están involucrados
en un deadlock en función del modelo de solicitud.
4. Estrategias de tratamiento de un deadlock

El tratamiento de deadlock lleva una complicación muy alta en los sistemas distribuidos
porque los sitios no tienen conocimientos exactos del estado actual del sistema y
porque cada una de las comunicaciones entre los sitios involucra un retardo finito e
impredecible. Existen tres estrategias para tratamiento de deadlocks:
• Detección. Permitir que ocurran los bloqueos, detectarlos e intentar recuperarse de
ellos.
• Prevención. Lograr estáticamente que los bloqueos sean imposibles desde el punto
de vista estructural.
• Evitación. Evitar los bloqueos mediante la asignación cuidadosa de los recursos.
x
La prevención del deadlock es comúnmente lograda teniendo una totalidad del proceso
de adquisición de los recursos necesarios antes de iniciar la ejecución o adelantarse
antes de que un proceso mantenga el recurso que será necesitado. Una manera de
prevención del deadlock en un sistema distribuido es conceder un recurso a un
proceso si el estado global del sistema resultante es SEGURO (tenga en cuenta que el
estado global incluyen todos los procesos y todos los recursos del sistema distribuido).
Sin embargo, debido a varios problemas, evitar los deadlock es impráctico en sistemas
distribuidos.
El descubrimiento de métodos generales para prevenir o evitar bloqueos distribuidos

parece un tanto difícil, por lo que muchos investigadores han intentado resolver el
problema más sencillo consistente en la detección de bloqueos, en vez de tratar de
inhibir su aparición. Sin embargo, la presencia de las transacciones atómicas en ciertos
sistemas distribuidos es una diferencia conceptual fundamental. Cuando se detecta un
bloqueo en un sistema operativo convencional, la forma de resolverlo es eliminar uno o
más procesos. Esto produce uno o varios usuarios infelices. Cuando se detecta un
bloqueo en un sistema basado en transacciones atómicas, se resuelve abortando una o
más transacciones, pero cuando una transacción es abortada, el sistema restaura en
primer lugar el estado que tenía antes de iniciar la transacción, por lo que puede
comenzar de nuevo la misma.
4.1. Problemas en la detección de deadlock

Manejar el deadlock usando el enfoque de detección aborda dos cuestiones básicas:
primero, detectar la existencia de deadlocks, y segundo solucionar los deadlocks
detectados.
La detección de deadlocks implica abordar dos cuestiones: mantener el WFG y buscar

en el WFG la presencia de ciclos (o nudos).
Un algoritmo de detección de deadlock debe satisfacer las siguientes dos condiciones:

(i) Progreso (No hay deadlock detectados)
El algoritmo debe detectar todos los deadlocks existentes en un tiempo finito.
En otras palabras, después que todas las dependencias wait-for del
deadlock se han formado, el algoritmo no debe esperar que ocurran más
eventos para detectar los deadlock.
(ii) Seguridad (No hay deadlocks falsos)
El algoritmo no debe reportar deadlocks que no existan (llamados deadlocks
fantasmas o falsos)
4.2. Prevención de un deadlock

La prevención de bloqueos consiste en el diseño cuidadoso del sistema, de modo que
los bloqueos sean imposibles, desde el punto de vista estructural. Entre las distintas
técnicas se incluye el permitir a los procesos que sólo conserven un recurso a la vez,
exigir a los procesos que soliciten todos sus recursos desde un principio y hacer que
liberen todos sus recursos cuando soliciten uno nuevo. Un método para llevar a cabo lo
anterior, es ordenar todos los recursos y exigir a los procesos que los adquieran en
orden estrictamente creciente. Este método significa que un proceso nunca puede
conservar un recurso y pedir otro menor, por lo que son imposibles los bloqueos. Sin
embargo, en un sistema distribuido con tiempo global y transacciones atómicas, son
posibles otros algoritmos prácticos. Ambos se basan en la idea de asociar a cada
transacción una marca de tiempo global al momento de su inicio, aquí es esencial que
ninguna pareja de transacciones tenga asociada la misma marca de tiempo. La idea
detrás de este algoritmo es que cuando un proceso está a punto de bloquearse en
espera de un recurso que está utilizando otro proceso, se verifica cuál de ellos tiene la
marca de tiempo mayor (es decir, es más joven). Puede permitir entonces la espera
sólo si el proceso en estado de espera tiene marca inferior (más antiguo) que el proceso
esperado. De esta forma, al seguir cualquier cadena de procesos en espera, las marcas
siempre aparecen en forma creciente, de modo que los ciclos son imposibles. Otra
alternativa consiste en permitir la espera de procesos sólo si éste tiene una marca
mayor (es más joven) que el proceso esperado, en cuyo caso las marcas aparecen en
la cadena de forma descendente.
Aunque ambos métodos previenen los bloqueos, es más sabio dar prioridad a los
procesos más viejos, ya que se han ejecutado durante más tiempo, por lo que el
sistema ha invertido mucho en ellos y es probable que conserven más recursos.
Además, un proceso joven eliminado en esta etapa llegará en cierto momento al punto
en que sea el más antiguo del sistema, de modo que esta opción elimina la inanición.
Veamos la figura 2, para visualizar mejor el algoritmo, en (a), un proceso antiguo desea
un recurso que mantiene un proceso joven, en (b), un proceso joven desea un recurso
que mantiene un proceso antiguo. En el primer caso debemos permitir al proceso que
continúe (lo colocamos en espera); en el otro caso lo eliminamos (matamos el proceso).
Por lo anterior este algoritmo se llama espera-muerte.
Figura 2. Algoritmo espera-muerte.
Una vez que hemos supuesto la existencia de transacciones, podemos hacer algo que
antes estaba prohibido: tomar los recursos de los procesos en ejecución. Con lo que
estamos diciendo que al surgir un conflicto, en vez de eliminar el proceso que hace la
solicitud, podemos eliminar los procesos propietarios. Sin las transacciones, la
eliminación de un proceso podría tener severas consecuencias, puesto que el proceso
podría haber modificado ciertos archivos, con las transacciones estos efectos se
desvanecen si la transacción muere. Consideremos ahora la situación de la figura 3,
donde se van a permitir las prioridades. Dado que nuestro sistema venera a los
ancestros, no queremos que un joven tenga prioridad sobre un viejo, de modo que la
figura 3(a) y no la figura 3(b) recibe el nombre de “derecho de prioridad”. Por esta razón,
podemos llamar con seguridad a la figura 3(b) espera. Este algoritmo recibe el nombre
de herida-espera, puesto que se supone que una de las transacciones queda herida
(en realidad se le elimina) y la otra espera.
Si un proceso antiguo desea un recurso mantenido por uno joven, el proceso antiguo
ejerce su derecho de prioridad sobre el joven, cuya transacción es eliminada, como se
x
muestra en la figura 3(a). Es probable que el joven vuelva a iniciar su ejecución de

manera inmediata, con lo que intentaría adquirir de nuevo el recurso; esto lleva a la
situación de la figura 3(b), obligándolo a esperar.
Figura 3. Algoritmo herida-muerte.
4.3. Resolviendo un deadlock detectado

Resolver el deadlock involucra romper las dependencias wait-for existentes entre los
procesos. Se trata de retroceder uno o más procesos involucrados en el deadlock y
asignar sus recursos a los procesos bloqueados para que puedan continuar su
ejecución.
5. Modelos de deadlock
Los sistemas distribuidos permiten varios tipos de solicitudes de recursos, y con base
en esto se puede hacer una clasificación de ellos:
1) Modelo de recurso simple o individual.
En este modelo, un proceso puede tener como máximo una solicitud
pendiente para una sola unidad de un recurso. Dado que el grado máximo
de salida de un nodo en un WFG para el modelo de recurso simple puede
ser 1, la presencia de un ciclo en el WFG indicará que existe un deadlock.
2) Modelo AND.
En el modelo AND, un proceso puede solicitar más de un recurso
simultáneamente y la petición se satisface sólo después de conceder todos
los recursos solicitados. El grado de un nodo en el WFG para el modelo AND
puede ser más de 1. La presencia de un ciclo en el WFG indica un
deadlock en el modelo AND. En comparación con el modelo de recurso simple,
en donde un proceso sólo puede tener como máximo una solicitud
pendiente, el modelo AND es una forma más general.
3) Modelo OR.
En el modelo OR, un proceso puede realizar una solicitud para varios
recursos simultáneamente y la solicitud es satisfecha si alguno de los
recursos solicitados es garantizado.
6. Algoritmo centralizado para la detección de bloqueos
1. Cada máquina mantiene la gráfica de los recursos de sus propios procesos y

recursos.
2. Un coordinador central mantiene la gráfica de los recursos de todo el sistema
(unión de todas las gráficas individuales).
3. Cuando el coordinador detecta un ciclo, elimina uno de los procesos para

romper el bloqueo.
En este algoritmo se presenta el problema de retraso de mensajes que anuncian

las actualizaciones de los recursos y procesos. Consideremos un sistema donde los
procesos A y B se ejecutan en la máquina 0 y el proceso C se ejecuta en la máquina 1.
Existen tres recursos, R, S, T. En un principio, la situación es como se muestra en la
figura 4(a) y 4(b): A conserva a S pero desea a R, que no puede tener debido a que B lo
utiliza. C tiene a T y también desea a S. La visión del coordinado es como se muestra
en la figura 1(c). Esta configuración es segura. Tan pronto termina B, A puede obtener
R y terminar, con lo que libera S a C. Después de un tiempo, B libera a R y pide T, un
intercambio por completo válido y seguro. La máquina 0 envía un mensaje al
coordinador para avisarle la liberación de R y la máquina 1 envía un mensaje al
coordinador para anunciar el hecho de que B espera su recurso T. Por desgracia, el
mensaje de la máquina 1 llega en primer lugar, lo que hace que el coordinador
construya la gráfica de la figura 4(d). Con ella, el coordinador concluye, de manera
errónea, que existe un bloqueo y elimina el proceso. Esta situación recibe el nombre de
falso bloqueo. Una posible solución a este problema es utilizar el algoritmo de
Lamport para disponer de un tiempo global.
Figura 4. Procesos y recursos
7. Propuesta de Chandy-Misra-Haas
En los siguientes párrafos se mostrarán las aportaciones de K. Mani Chandy, Jayadev
Misra, Laura M. Haas en su artículo Distributed Deadlock Detection publicado en 1983
[2].
En un sistema de procesos los cuales se comunican solamente con un único agente

central, el deadlock puede ser detectado fácilmente porque el agente central tiene
completa información acerca de cada proceso. La detección de deadlock es más difícil
en sistemas donde no existe dicho agente y los procesos pueden comunicarse
directamente entre ellos. En su artículo, se presenta un algoritmo de detección de
x
deadlock para redes de procesos que no cuentan con un agente central, y en los
cuales los retardos de mensajes son arbitrarios pero finitos. El único supuesto que se
hace es que los mensajes enviados por el proceso A al proceso B son recibidos por B
en el orden en el cual fueron enviados por A.
Se consideran dos modelos de deadlocks en los sistemas de comunicación de

mensajes: deadlocks en recursos y deadlocks en comunicación. En el modelo de
recursos, un proceso que solicita recursos debe esperar hasta que adquiera todos los
recursos solicitados antes de que pueda proceder con sus actividades. Por ejemplo, un
proceso puede solicitar los recursos a, b y c; el proceso puede proceder sólo después
de recibir los tres recursos: a, b y c. El modelo de comunicación es aplicable para
solicitudes de recursos arbitrarios involucrando la lógica de los procesos AND y OR.
7.1. Modelo de computo distribuido

Una red consiste de un conjunto de procesos los cuales se comunican entre ellos
exclusivamente por mensajes y adoptan el protocolo de comunicación de mensajes de
Dijkstra y Scholten: cualquier mensaje enviado por un proceso a otro es recibido
correctamente después de un retardo arbitrario, pero finito, y los mensajes de
transmisión obedecen la regla Primero en Entrar - Primero en Salir, es decir, los
mensajes enviado por cualquier proceso Pi a cualquier otro proceso Pj son recibidos por
Pj en la secuencia en la cual fueron enviados por Pi. Un proceso Pi sólo puede asegurar
que cualquier mensaje que envía al proceso Pj será recibido eventualmente, sin
embargo, un proceso Pi no puede afirmar que Pj en realidad ha recibido el mensaje, al
menos que reciba algún tipo de acuse de recibo por parte de P j. En este modelo, un
proceso nunca espera para enviar mensajes.
En cualquier tiempo dado, un proceso está en uno de dos estados: inactivo o ejecución.
Solamente los procesos que están en estado de ejecución pueden enviar mensajes. Un
proceso en ejecución puede cambiar su estado (a inactivo) en cualquier momento, pero
un proceso inactivo solo puede cambiar su estado (a ejecución) después de que se han
concedido sus peticiones; cabe hacer notar que las condiciones para cambio de estados
son diferentes para los modelos de recursos y de comunicación.
7.2. Modelo de recursos
Una BDD consiste de recursos, controladores y procesos. Asociado con cada

controlador se encuentra un conjunto de recursos (los cuales administra) y un conjunto
de procesos que lo integran. Un proceso sólo puede solicitar recursos desde su propio
controlador, pero este controlador podrá tener comunicación con otros controladores
con el fin de reservar un recurso en particular. Un proceso no podrá estar en ejecución
al menos que adquiera todos los recursos que está esperando. Un conjunto de
procesos se dice que está en deadlock cuando ningún proceso en el conjunto puede
ejecutarse dado que cada uno de ellos requiere que se le otorgue un recurso en manos
de otro proceso en el conjunto.
Una BDD esta implementada por N computadoras S 1,..., SN. Un sistema operativo local
o controlador Cj en cada computadora Sj planifica procesos, administra recursos, y lleva
a cabo la comunicación. Existen M transacciones T1.....TM ejecutándose en la BDD. Una
transacción está implementada por una colección de procesos con un máximo de un
proceso por computadora. Cada proceso está etiquetado con una dupla P ij donde Ti es
el identificador de la transacción donde pertenece el proceso y S j es la computadora en
la cual se ejecuta el proceso.
Algunos estados en el cálculo de una transacción pueden necesitar bloquear recursos

(tales como archivos). Cuando un proceso Pij necesite un recurso, este envía una
solicitud a su controlador Cj. Si el administrador de recursos Cj y si el recurso en
particular está disponible, este podrá accesar al recurso inmediatamente; en otro caso,
el proceso deberá esperas la adquisición del recurso solicitado. Si el recurso solicitado
es administrado por algún otro controlador Cm, entonces Cj transmitirá dicha solicitud del
proceso Pim vía Cm; y ahora el proceso Pim solicitará el recurso desde el controlador Cm .
Cuando Pim adquiere el recurso solicitado desde Cm, este envía un mensaje a Pij (vía Cm
y Cj) indicando que la solicitud del recurso ha sido otorgada. P ij podrá proceder a su
cálculo sólo después de que haya recibido respuestas positivas a todas sus solicitudes
de recursos. Cuando los procesos en una transacción Ti ya no necesitan un recurso
administrado por Cm, ellos se comunican con el proceso P im el cual es responsable de
liberar el recurso de Cm. Los mensajes enviados por cualquier controlador Ci a otro Cj,
llegan secuencialmente y en un tiempo finito.
Un proceso no puede proseguir con su cálculo hasta que adquiera todos los recursos
que haya solicitado. Un conjunto de recursos se dice que está inactivo cuando espera
adquirir un recurso; se dice que está en ejecución cuando no está inactivo. Por lo tanto,
si un proceso nunca adquiere un recurso solicitado, estará permanentemente inactivo.
Se supondrá que si un sola transacción se ejecuta por si misma en un BDD, está
terminará en un tiempo finito y eventualmente liberará todos los recursos. Cuando dos
o más transacciones se ejecutan en paralelo, puede surgir un deadlock.
Pi denota al i-ésimo proceso. Un proceso Pj se dice que es dependiente de otro proceso

Pk si existe una secuencia (seq) de procesos Pj, Pi(1).....Pi(m), Pk, donde cada proceso
en la seq está inactivo y cada proceso (excepto el primero) en la seq mantiene un
recurso, que el proceso anterior en la seq está esperando. P j se dice ser localmente
dependiente de Pk si todos los procesos en la seq pertenecen al mismo controlador. Si
Pj es dependiente de Pk entonces Pj debe permanecer inactivo por lo menos como Pk
permanezca inactivo. Pj esta en deadlock si es dependiente de si mismo o de un
proceso que es dependiente de si mismo. En cualquier caso, existe un deadlock sólo si
existe un ciclo de procesos inactivos cada uno dependiente del siguiente proceso en el
ciclo. El objetivo de los algoritmos de detección de deadlock de recursos es declarar
que existe un deadlock si y sólo si existen tales ciclos.
7.3. Modelo de comunicación

El modelo de comunicación es una descripción abstracta de una red de procesos que
se comunican vía mensajes. No existe controladores explícitos (o recursos) en este
modelo. Asociados con cada proceso inactivo está un conjunto de procesos llamado su
conjunto de dependencia. Un proceso inactivo inicia su ejecución al recibir un mensaje
de cualquier proceso en su conjunto de dependencia; de lo contrario, no cambia de
estado o su conjunto de dependencia. Un proceso se termina si está inactivo y su
x
conjunto de dependencia asociada es vacío. Por el momento, se asume que los

procesos no terminan, fallan o abortan.
Intuitivamente, un conjunto S no vacío de procesos está en deadlock si todos los
procesos en S están permanentemente inactivos. Un proceso está permanentemente
inactivo si este nunca recibe un mensaje de algún proceso en su conjunto de
dependencia. No es posible detectar la inactividad permanente en las siguientes
situaciones:
• Un proceso A está en la espera de un mensaje del proceso B;
• Un proceso B está actualmente en ejecución y enviará un mensaje al proceso A
solamente después que termine un bucle;
• Un proceso A parece estar permanentemente inactivo si el cómputo del bucle
del proceso B no ha terminado.
Por lo tanto, se adopta la siguiente definición de deadlock: Un conjunto no vacío de
procesos S está en deadlocked si y sólo si
1. Todos los procesos en S están inactivos;
2. El conjunto de dependencias de cada proceso en S es un subconjunto de S; y
3. No existe mensajes en transito entre los procesos en S.
Un proceso está deadlocked si este pertenece a algún conjunto deadlocked.
Un conjunto no vacío S de procesos que cumpla con las tres condiciones anteriores
debe estar permanentemente inactivo por que:
1. un proceso Pi inactivo en S puede iniciar su ejecución solamente después de
recibir un mensaje de algún proceso Pj en su conjunto de dependencia,
2. cada proceso Pj y los restantes Pi's en su conjunto de dependencia que están
también en S y no pueden enviar un mensaje mientras permanezca en estado
inactivo, y
3. no existe mensajes en transito entre P j y Pi, lo cual implica que P i nunca recibirá
mensaje de algún proceso en su conjunto de dependencia.
7.4. Comparación de los deadlocks de recursos y comunicación
Una diferencia fundamental es que en el modelo de comunicación, un proceso puede

conocer la identidad de los procesos de los cuales debe recibir un mensaje antes de
que pueda continuar. Si un proceso A necesita recibir un mensaje del proceso B,
entonces A puede conocer que está en espera de B. Por lo tanto, los procesos tienen la
información necesaria para realizar la detección del deadlock si ellos actúan
colectivamente. En el modelo de recurso no se conoce directamente la dependencia de
una transacción con otra. Lo único que se sabe es si una transacción está esperando un
recurso determinado o si una transacción tiene un recurso determinado. El controlador
de cada sitio mantiene un registro de sus recursos y sólo los controladores pueden
deducir que una transacción está esperando otra.
La segunda mayor diferencia es que en el modelo de asignación de recursos, un

proceso no puede proceder su ejecución hasta que reciba todos los recursos por los
cuales espera; en el modelo de comunicación, un proceso no puede proceder con su
ejecución hasta que puede comunicarse con al menos uno de los procesos de los
cuales está en espera. La diferencia entre los modelos de recursos y comunicación se
encuentre entre la espera de todos los recursos y la espera de algún mensaje.
7.5. Detección de un deadlock

Un explorador es una tripleta (i, j, k) que denotará que pertenece a prueba iniciada por
Pi, y que está prueba está siendo enviada desde el proceso P j en un controlador a un
proceso Pk en otro. El significado intuitivo del explorador(i, j, k) es lo siguiente:
• Pj envía un explorador (i, j, k) a Pk cuando se dan las siguientes condiciones:
◦ Pj está inactivo, Pj está esperando a (es decir, está esperando adquirir un

recurso desde) Pk, y Pj ha determinado que Pi es dependiente de Pj. Este
explorador puede ser descartada o aceptada por Pk;
◦ El explorador es aceptado por Pk si y sólo si Pk está inactivo, Pk no sabía que

Pi era dependiente de él, y Pk puede ahora deducir que Pi es dependiente de
él. De esto se desprende que si Pi acepta el explorador (i, j, i), de cualquier j,
entonces Pi se encuentra deadlocked.
En la figura 5 se presenta una gráfica de los recursos modificada, donde sólo se

muestran los procesos. El proceso 3 de la máquina 1 espera dos recursos, uno de los
cuales lo tiene el proceso 4 y el otro lo tiene el proceso 5. Algunos de los procesos
esperan recursos locales, como el proceso 1, pero otros, como el proceso 2, esperan
recursos localizados en una máquina distinta.
Figura 5. Detección de un deadlock por un explorador
x
El algoritmo Chandy-Misra-Haas es utilizado cuando un proceso debe esperar cierto

recurso. Por ejemplo, el proceso 0 se bloquea debido al proceso 1. En este momento,
se genera un mensaje especial de exploración, el cual se envía al proceso (o procesos)
que detienen los recursos necesarios. El mensaje consta de tres números: el proceso
recién bloqueado, el proceso que envía el mensaje y el proceso al cual se envía. El
mensaje inicial de 0 a 1 contiene la tercia (0, 0, 1). Al llegar el mensaje, el receptor
verifica si él mismo espera a algunos procesos. En este caso, el mensaje se actualiza,
conservando el primer campo pero reemplazando el segundo por su propio número de
proceso y el tercero por el número del proceso al cual espera. El mensaje se envía
entonces al proceso debido al cual se bloquea. Si se bloquea debido a varios procesos,
a todos ellos se les envía mensajes (diferentes). Este algoritmo se lleva a cabo sin
importar si el recurso es local o remoto. Si un mensaje recorre todo el camino y regresa
a su emisor original, es decir, al proceso enumerado en el primer campo, existe un ciclo
y el sistema está bloqueado.
Existen varias formas de romper un bloqueo. Una forma es que el proceso que inició la
exploración se comprometa a suicidarse. Sin embargo, este método tiene problemas si
varios procesos llaman en forma simultánea al algoritmo. Por ejemplo, en la figura 5,
imaginemos que 0 y 6 se bloquean al mismo tiempo y ambos inician exploraciones,
entonces ellos descubrirían el bloqueo y se eliminarían a si mismo. Esto es demasiada
eliminación, con que uno desaparezca es suficiente.
Referencias
[1] Andrew S. Tanenbaum, Sistemas Operativos Distribuidos, Prentice Hall.

[2] K. Mani Chandy, Jayadev Misra, Laura M. Haas. “Distributed Deadlock Detection”.
ACM Transactions on ComputerSystems,Vol. 1, No. 2. 1983
[3] Selvaraj Srinivasan, R. Rajaram. “A decentralized deadlock detection and resolution
algorithm for generalized model in distributed systems”. Springer. 2011.
[4] Mukesh Singhal. “Deadlock Detection in Distributed Systems”. IEEE Computer, No.
22, 37-48, 1989.
REALIZAR:
Investigar y reportar los siguientes algoritmos
1. Algoritmo de Mitchell-Merrit
2. Algoritmo de Sinha-Natarajan
Capítulo VI
Tolerancia a fallos
El diseño y la verificación de las aplicaciones distribuidas tolerantes a fallas es
ampliamente vistas como un esfuerzo complejo. En recientes años, varios paradigmas
han surgido para simplificar esta tarea. La clave es el consenso general y los tipos
fiables broadcast. Los consensos permiten a los procesos tener una decisión común, los
cuales dependen en sus entradas iniciales, a pesar de las fallas. Los algoritmos de
consenso pueden ser usados para resolver muchos problemas que surgen en la
práctica, tales como la elección de un líder. En algunas aplicaciones los procesos deben
de confiar en los mensajes broadcast, así que ellos acuerdan los mensajes de entrega o
arreglar un orden de entrega. Por otra parte, supongamos que la comunicación es
perfecta, pero ¿qué pasa cuándo los procesadores no lo son?
1. Introducción al problema de tolerancia de fallos
Como en los sistemas distribuidos puede fallar uno de los equipos que lo forman, el
sistema debe continuar su ejecución y/o recuperarse del fallo parcial sin afectar el
rendimiento general, es decir, debe ser tolerante a fallos. Un punto específicamente
difícil en los grupos de procesos es llegar a un consenso entre los miembros del grupo
sobre qué operación se debe realizar, para ello se envían mensajes en multidifusión
atómica. La tolerancia a fallo está fuertemente relacionada con la confiabilidad que se
tiene sobre el sistema: disponiblidad, fiabilidad, seguridad y mantenimiento.
Dentro del conjunto de fallas que se pueden presentar se encuentran:
• Paro del sistema, pero puede funcionar correctamente hasta llegar a detenerse.
• Falla de omisión de mensajes: responder, recibir, enviar mensajes.
• Falla de tiempo de respuesta: responde en un tiempo mayor de lo esperado.
• Envio de respuestas incorrectas.
Una clasificación de los fallos en cuanto a severidad de ellos se muestra en la figura 1.

Este modelo es aplicado a los sistemas síncronos y asíncronos. El comportamiento
arbitrario de los sistemas cuando fallan, también es conocido como fallo bizantino o
malicioso. En la siguiente sección se muestra la información de Lamport, Shostak, y
Pease, de su articulo “The Byzantine Generals Problem”, de 1982.
x
Quiebre
Omisión Omisión
de envío de recibo
Omisión
general
Arbitrario con
mensajes de autenticación
Arbitrario
Figura 1. Clasificación de fallo del sistema.
2. Problema de los Generales Bizantinos

Los sistemas de cómputo seguros pueden en determinado momento presentar
componentes que tengan un mal funcionamiento, y dar información errónea a
diferentes partes del sistema. Esta situación puede expresarse abstractamente en
términos de un grupo de generales del ejercito Bizantino acampados con sus tropas en
torno de una ciudad enemiga. Los generales para ponerse de acuerdo en un plan
común de batalla lo realizar por medio de envío de mensajes. Sin embargo, uno o más
de ellos puede ser un traidor y tratar de confundir a los demás.
Los generales deben tener un algoritmo para garantizar que:

A. Todos los generales leales decidan el mismo plan de acción.
B. Un pequeño número de traidores no pueda ocasionar que los generales leales
adopten un mal plan.
Para que la condición A sea satisfecha, debe ser verdadero lo siguiente:

1. Cada general leal debe obtener la misma información v(1), … ,v(n).
2. Si el i-ésimo general es leal, entonces el valor que envía debe ser usado por todos
los generales leales como el valor de v(i)
Re-escribiendo la condición 1 como la condición de cada i (sea o no el i-ésimo general

leal),
1'. Cualquiera de dos generales leales usa el mismo valor de v(i).
Problema de los Generales Bizantinos. Un comandante general debe enviar una orden
a sus n-1 tenientes generales de manera que:
IC1. Todos los tenientes leales obedecen la misma orden.
IC2. Si el comandante general es leal, entonces cada teniente leal obedece la orden
que le fue enviada.
Las condiciones IC1 y IC2 son llamadas condiciones de consistencia interactiva.

Resultados imposibles
Se demuestra que con mensajes orales no hay solución para tres generales en la
presencia de un traidor. Para simplificar, se considera el caso en el cuál las únicas
decisiones posibles son “atacar” o “retirada”.
Examinando el primer escenario presentado en la Figura 2, en el cual el comandante es

leal y envía una orden de “ataque”, pero el Teniente 2 es un traidor y reporta al Teniente
1 que él recibió una orden de “retirada”. Para que IC2 sea satisfecha, el Teniente 1 debe
obedecer la orden de ataque.
Figura 2. El teniente 2 es un traidor
Considerando otro escenario, en la Figura 3 se muestra que, el comandante es un

traidor y envía una orden de “atacar” al Teniente 1 y una orden de “retirada” al Teniente
2. El Teniente 1 no sabe quién es el traidor, y no puede decir cuál fue el mensaje que el
comandante envío realmente al Teniente 2. Por lo tanto, los escenarios en estas dos
figuras se presentan exactamente iguales al Teniente 1. Si el traidor miente
consistentemente, entonces no hay manera de que el Teniente 1 distinga entre estas
dos situaciones, por lo que debe obedecer la orden de “atacar” en ambos casos. Por lo
tanto, cada vez que el Teniente 1 recibe una orden de “atacar” del comandante, debe
obedecerla. Sin embargo, un argumento similar muestra que si el Teniente 2 recibe una
orden de “retirada” del Comandante entonces debe obedecer, incluso si el Teniente 1 le
dice que el Comandante le dijo “atacar”. Por lo tanto, en el escenario de la Figura 3, el
Teniente 2 debe obedecer la orden de “retirada” mientras el Teniente 1 obedece la
orden de “atacar”, violando así la condición IC1. Por lo tanto, no existe solución para
tres generales que trabajan en la presencia de un sólo traidor.
Usando este resultado, se puede mostrar que existe solución con al menos 3m+1
generales enfrentando a m traidores.
x
Figura 3. El comandante es un traidor.
Se supone que el comandante ordena el tiempo del ataque, y requiere las dos
condiciones siguientes:
IC1'. Todos los tenientes leales atacan con 10 minutos de diferencia.
IC2'. Si el comandante general es leal, entonces cada teniente leal ataca 10 minutos
después que el comandante ordenó.
Cada teniente usa el siguiente procedimiento para obtener su orden:

(1) Después de recibir el tiempo de ataque del comandante, un teniente realiza una de
las siguientes opciones:
(a) Si el tiempo es 1:10 o anterior, entonces ataca.
(b) Si el tiempo es 1:50 o más tarde, entonces se retira.
(c) De lo contrario, continué con el paso (2).
(2) Pregunta al otro teniente que decisión le llegó en el paso (1):
(a) Si el otro teniente llegó a una decisión, entonces hace la misma decisión que
él.
(b) De lo contrario, se retira.
Una solución con mensajes
La definición de un mensaje oral se materializa con las siguientes suposiciones, las

cuales se hace para el sistema de mensajes de los generales:
A1. Cada mensaje que se envía es entregado correctamente.
A2. El receptor de un mensaje conoce quién lo envío.
A3. La ausencia de un mensaje puede ser detectado.
Inductivamente se definen los algoritmos de Mensajes Orales OM(m), para todos los
enteros no negativos m, por los cuales el comandante envía una orden a los n-1
tenientes. Se demuestra que OM(m) resuelve el Problema de los Generales Bizantinos
para 3m + 1 o más generales en la presencia de a lo más m traidores.
El algoritmo asume una función mayoría con la propiedad de que si la mayoría de los
valores de vi es igual a v, entonces la función mayoría (v1,.. ,vn-1) es igual a v. (En
realidad, asume una secuencia de tales funciones -- una para cada n). Existen dos
elecciones naturales para el valor de mayoría (v1, ... ,vn-1):
1. El valor mayoría entre los vi si este existe, de lo contrario el valor será RETIRADA;
2. La mediana de los vi, en el supuesto de que provienen de un conjunto ordenado.
Algoritmo OM(0)
(1) El comandante envía su valor a cada uno de los tenientes.
(2) Cada uno de los tenientes usa el valor recibido del comandante, o usa el valor
RETIRADA si no recibió ningún valor.
Algoritmo OM(m), m>0

(1) El comandante envía su valor a cada uno de los tenientes.
(2) Para cada i, vi es el valor del Teniente i que recibió del comandante, o es RETIRADA
sino recibió ningún valor. El Teniente i actúa como el comandante para el algoritmo
OM(m-1) para enviar el valor vi a cada uno de los n-2 tenientes.
(3) Para cada i, y para cada j≠ i, v j es el valor del Teniente i que recibió del Teniente j en
el paso (2) (usando el Algoritmo OM(m-1)), o es RETIRADA sino recibió ningún valor. El
Teniente i usa el valor mayoría (v1, ....., vn-1).
Figura 4. Algoritmo OM(1); n= 4. El teniente 3 es un traidor.
Figura 5. Algoritmo OM(1); n= 4. El comandante es un traidor.
x
Lema 1
Para cualquier m y k, el Algoritmo OM(m) satisface IC2 si existen a lo más
2k+m generales y a lo más k traidores.
Teorema 1
Para cualquier m y k, el Algoritmo OM(m) satisface IC1 e IC2 si existen a lo más
3m generales y a lo más m traidores.
Solución con mensajes firmados

Anexando a A1-A3 el siguiente supuesto:
A4.
(a) La firma de un general leal no se puede falsificar, y cualquier alteración de los
contenidos de sus mensajes firmados puede ser detectado.
(b) Cualquier persona puede verificar la autenticidad de la firma de un general.
El algoritmo asume una función de elección, la cual es aplicada a un conjunto de

ordenes para obtener una única. Los requisitos que se tienen para esta función son:
1. Si el conjunto V está formado por un único elemento v, entonces elección(V)=v.
2. elección(∅) = RETIRADA, donde ∅ es el conjunto vacío.) = RETIRADA, donde ∅) = RETIRADA, donde ∅ es el conjunto vacío. es el conjunto vacío.
Note que una posible definición es dejar que elección(V) sea el elemento de la mediana
de V -- suponiendo que existe un ordenamiento de los elementos.
En el siguiente algoritmo, x:i denota el valor x firmado por el General i. Por lo tanto, v:j:i
denota el valor v firmado por j, y el valor v:j firmado por i. Sea el General igual a 0 para
el comandante. En este algoritmo, cada teniente i mantiene su conjunto Vi, que contiene
el conjunto de ordenes debidamente firmados que ha recibido hasta ese momento (Si el
comandante es leal, entonces este conjunto nunca debe contener más de un sólo
elemento).
Algoritmo SM (m)
Inicialmente Vi = ∅) = RETIRADA, donde ∅ es el conjunto vacío..
(1) El comandante firma y envía su valor a cada uno de los tenientes.
(2) Para cada i:
(a) Si el Teniente i recibe un mensaje de la forma v:0 del comandante y aún no ha
recibido ninguna orden, entonces
←(i) Coloca a Vi igual a {v};
←(ii) Envía los mensajes v:0:i a cada uno de los demás tenientes.
(b) Si el Teniente i recibe un mensaje de la forma v:0:j1:...:jk y v no está en el

conjunto de Vi, entonces
←(i) Anexa v a Vi;
←(ii) si k<m, entonces envía el mensaje v:0:j1:...:jk a cada uno de los demás
tenientes que están entre j1,...,jk
(3) Para cada i: Cuando el Teniente i no recibe más mensajes, obedece la orden de
elección (Vi).
Figura 6. Algoritmo SM(1). El comandante es un traidor.
Teorema 2
Para cualquier m, el Algoritmo SM(m) resuelve el Problema de los Generales
Bizantinos si existen a lo más m traidores.
Ausencia de rutas de comunicación
Hasta el momento, se ha asumido que un general puede enviar mensajes directamente

a los demás generales. Ahora, se remueve este supuesto. Para ampliar el Algoritmo de
mensajes orales OM(m), se necesita la siguiente definición, donde dos generales se
dice que son vecinos si están unidos por un arco.
Definición 1
(a) Un conjunto de nodos {i1,...,ip} se dice que es un conjunto regular de vecinos
de un nodo i si:
(i) cada ij es un vecino de i, y
(ii) para cualquier k diferente de i, existen caminos ɣ j,k desde ij a k no pasando
a través de i tal que cualquiera de los dos caminos diferentes ɣj,k no tiene ningún
nodo en común a parte de k.
(b) El grafo G se dice ser p-regular si cada nodo tiene un conjunto regular de
vecinos consistente de p nodos distintos.
Figura 7. Ejemplo de Grafos
x
Algoritmo OM (m,p)
Extendiendo OM(m) a un algoritmo que resuelve el Problema de Generales Bizantinos

en la presencia de m traidores si el grafo G de generales es 3m-regular. (Note que un
grafo 3m-regular debe contener al menos 3m + 1 nodos).
(0) Elija un conjunto regular N de vecinos del comandante, consistente de p tenientes.
(1) El comandante envía su valor a cada uno de los N tenientes.
(2) Para cada i en N, vi será el valor del Teniente i recibido del comandante, o en otro
caso RETIRADA sino recibe ningún valor. El Teniente i envía vi a cada uno de los k
tenientes como sigue:
(a) Si m = 1, entonces se envía el valor a través de la ruta ɣ i,k cuya existencia es
garantizada por la definición 1 (a)(ii)
(b) Si m > 1, entonces actuando como el comandante en el algoritmo OM(m-1,p-1), con
el grafo de los generales obtenido mediante la eliminación del comandante original de
G.
(3) Para cada k, y cada i en N con i ≠ k, vi será el valor que el Teniente k recibió del
Teniente i en el paso (2), o RETIRADA sino recibe ningún valor. El Teniente k usa el
valor de mayoría(vi1,...,vip), donde N = {i1..... ip}.
Lema 2
Para cualquier m>0 y cualquier p ≥2k+m, el algoritmo OM(m,p) satisface IC2 si
existen a lo más m traidores.
Teorema 3
Para cualquier m>0 y cualquier p ≥ 3m, el Algoritmo OM(m,p) resuelve el
Problema de los Generales Bizantinos si existen a lo más m traidores.
Se prueba el siguiente resultado en forma general, en el cuál el diámetro de un grafo es

el número más pequeño d tal que cualquiera dos nodos están conectados por una ruta
que contiene a lo más d arcos.
Teorema 4
Para cualquier m y d, si existen a lo más m traidores y el subgrafo de generales
leales tiene el diámetro d, entonces el Algoritmo SM(m+d-1) (con la modificación
anterior) resuelve el Problema de los Generales Bizantinos.
Corolario
Si el grafo de los generales leales es conectado, entonces SM(n-2) (con la
modificación anterior) resuelve el Problema de los Generales Bizantinos.
Sistemas Confiables
Para que la votación por mayoría se produzca en un sistema fiable, las siguientes dos
condiciones deben cumplirse:
1. Todos los procesadores no defectuosos deben usar el mismo valor de entrada (así
ellos producen la misma salida).
2. Si la unidad de entrada es no defectuosa, entonces todos los procesadores no
defectuosos usan el valor proporcionado como entrada (así ellos producen la salida
correcta).
El uso del tiempo de espera para satisfacer A3 requiere dos supuestos:

1. Existe un tiempo máximo fijado necesario para la generación y transmisión
de un mensaje.
2. El emisor y el receptor tienen relojes que son sincronizados dentro de algún error
máximo fijo.
Referencia
[1] Lamport, L., Shostak R, Pease M. “The Byzantine Generals Problem”. ACM
Transactionson Programming Languages and Systems,Vol. 4, No. 3. pp. 382-401.
1982.
x
Capítulo VII
Control de acceso
Un sistema de cómputo o una red de computadoras incluyen datos, archivos,
programas, dispositivos y otros recursos que se les llama objetos, estos son accesibles
para algunos usuarios, procesos y otros componentes activos que se les llama sujetos
del sistema o de la red. Los sujetos pueden poseer derechos de acceso a los objetos, y
este par (objeto, derechos) se les llama capacidad del sujeto, de esta forma, el conjunto
de todas las capacidades de un sujeto se llama el dominio de protección.
1. Introducción
Los controles de acceso garantizan que todos los accesos directos a los objetos sean
autorizados, regulando la lectura, modificación, y borrado de los datos y programas. De
esta manera se protegen en contra de amenazas accidentales o maliciosas.
La eficacia del control de acceso se basa en dos premisas:
1. La identificación del usuario propietario: nadie puede ser capaz de adquirir los
derechos de acceso de otro (debe existir Autenticación).
2. La información que especifica los derechos de acceso de cada usuario o programa
está protegida contra modificaciones no autorizadas. Esta se cumple mediante
control de acceso a objetos del sistema, así como control a los objetos del usuario.
Una política especifica las reglas de utilización de acceso al sistema y un mecanismo es

el medio para hacer cumplir dichas reglas.
2. Matriz de acceso
La matriz de acceso proporciona un framework para describir un sistema de protección.
La versión del modelo para protección del sistema operativo fue formulada por Lampson
(1971) en su artículo “Protection”, y refinada por Graham y Denning (2972) en su
artículo “Protection: Principles and Practice ”. La versión formal del modelo fue dado por
Harrison, Ruzzo, y Ullman (1976) en el artículo “Protection in Operating Systems”. El
modelo es definido en términos de estados y transiciones, donde el estado de un
sistema protegido es representado por una matriz, y las transiciones de los estados son
descritas por comandos.
2.1 Estado de protección
El estado de un sistema esta definido por la tripleta (S, O, A) donde:

1. S es el conjunto de sujetos, los cuales son las entradas activas del modelo. Se
asume que los sujetos son considerados también objetos; por lo que
S ⊆ O
2. O es el conjunto de objetos, los cuales son entidades protegidas del sistema. Cada
objeto tiene un identificador único asignado por un nombre.
3. A es una matriz de acceso, con filas correspondientes a los sujetos y columnas a los
objetos. Una entrada A[s,o] enumera los derechos de acceso (o privilegios) del un
sujeto s sobre el objeto o.
Los objetos típicamente son: archivos, segmentos de memoria y procesos. Los sujetos
pueden ser: usuarios, procesos y dominios. Los dominios son el ambiente de protección
en el cual el proceso se ejecuta. Un proceso puede cambiar de dominio durante su
ejecución. Los derechos de acceso especifican las clases de acceso que pueden ser
ejecutadas sobre diferentes tipos de objetos. Los derechos de segmentos y archivos
usualmente son R (read), W (write) y E (ejecución), algunos sistemas tienen además el
derecho de Añadir, con el cual el sujeto le añade datos al final de un objeto pero no
sobre escribe en los datos existentes. El número de derechos genéricos es finito.
Figura 1. Ejemplo de una matriz de acceso.
La figura 1 muestra el estado de un sistema que tiene dos procesos (sujetos), dos
segmentos de memoria y dos archivos (objetos). Cada proceso tiene su segmento
privado y es propietario de un archivo. Ningún proceso puede controlar otro proceso.
Graham y Dennig asocian a cada tipo de objeto un monitor que se encarga de controlar
el acceso a dicho objeto. El monitor de un objeto o impide a un sujeto s accesar a o
cuando A[s,o] no contiene el derecho necesario.
2.2. Transiciones de estados

Los cambios en el estado de un sistema son modelados por un conjunto de comandos.
Los comandos están especificados por una secuencia de operaciones primitivas que
cambian la matriz de acceso. Estas operaciones están condicionadas con la presencia
de ciertos derechos en la matriz de acceso y son controladas por el monitor responsable
de administrar la protección del estado. Harrison, Ruzzo, y Ullman identifican 6
operaciones primitivas:
enter r into A[s, o]

delete r from A[s, o]
create sujeto s
create objeto o
destroy sujeto s
destroy objeto o
x
Dado op un operador primitivo y Q = (S, O, A) un estado del sistema. Entonces la

ejecución de op sobre el estado Q causa una transición de Q al estado Q' = (S', O', A')
bajo las condiciones definidas en la Tabla 1. Esto es escrito como:
Q ⊦op Q' op Q' (se lee: “Q deriva Q' bajo op”)
La tabla 1 muestra las operaciones primitivas y los nuevos estados a los que cambia el
sistema si la operación se ejecuta correctamente.
Tabla 1. Tabla de operaciones primitiva.

________________________________________________________________
Operación Condición Nuevo estado
________________________________________________________________
________________________________________________________________
Harrison, Ruzzo, y Ullman consideran los comandos de la siguiente forma:

command c(x1,..., xk)
if r1 in A[xs1, xo1] and
r2 in A[xs2, xo2] and
.
.
.
rm in A[xsm, xom] then
op1;
op2;
.
.
.
opn
end
Donde
r1,..., rm son derechos,
s1,..., sm y o1,..., om son enteros entre 1 y k.
Un comando puede tener un conjunto vacío de condiciones (es decir, m=0). Aquí se
asume que cada comando ejecuta al menos una operación.
2.3. Comandos
El efecto de un comando sobre el estado de un sistema protegido es como sigue:
Sean
c(a1,..., ak) un comando con parámetros a1..... ak, y
Q = (S, O, A) un estado de un sistema protegido.
Entonces Q produce un estado Q' bajo c:

Q ⊦op Q' c(a1, ..., ak) Q'
Siempre que
1. Q' = Q si una de las condiciones de c no se satisfizo, y
2. Q' = Qn en otro caso, cuando existen estados Q0, Q1, . . . , Qn tales que
Q = Qo ⊦op Q' op1 * Q1 ⊦op Q' op2 * ... ⊦op Q' opn * Qn,
donde opi* denota la operación primitiva opi, sustituyendo el actual parámetro de a i por
el parámetro formal xi.
Se escribirá Q ⊦op Q' c Q' si existen parámetros a1, … ,ak tales que Q ⊦op Q' c(a1, ..., ak) Q'; y
Q ⊦op Q' Q' si existe un comando c tal que Q ⊦op Q' c Q' . Finalmente se escribirá Q ⊦op Q' * Q' si existe
una secuencia de longitud n ≥ 0 : Q = Q0 ⊦op Q' Q1 ⊦op Q' ... ⊦op Q' Qn = Q'
Cualquier proceso puede crear un archivo nuevo. El proceso que crea el archivo
automáticamente es el propietario, y tiene acceso R y W sobre él. Esto se representa
por el comando:
command create.file(p, f)
create objeto f;
enter Own into A [p, f];
enter R into A[p, f];
enter W into A[p, f]
end.
x
El proceso propietario de un archivo puede cambiar los derechos del archivo. Por
ejemplo, un proceso p propietario de un archivo f puede proteger a f de modificaciones
involuntarias removiendo el acceso W sobre f. Puede además conferir cualquier
derecho del archivo (excepto propietario) a otros procesos. Por ejemplo, el acceso R
puede ser conferido por el proceso p al proceso q con el comando.
command confer.read (p, q, f)

if Own in A[p, f]
then enter R into A[q, f]
end.
Los anteriores comandos, violan el principio de attenuation of privilege, dado que al

proceso que se le concedió el derecho puede conceder también derecho o aumentar
sus derechos o transferirlos dado que no es el propietario. Pero se puede revocar el
derecho de lectura:
command revoke.read (p, q, f)

if Own in A[p, f]
then delete R from A[q, f]
end.
Algunos sistemas permite a los sujetos transferir un derecho de acceso r a un objeto sin
ser los dueños. Este es modelado con una bandera de copia (denotada como un
asterisco después de r). Siguiendo el principio de attenuation of privilege, un proceso
puede transferir derecho de acceso que tiene sobre el objeto siempre que la bandera se
establezca. El siguiente comando transfiere el acceso R de proceso p a q, pero no le da
habilidades a q para transferir derechos:
command transfer.read (p, q, f)

if R* in A[p, f]
then enter R into A[q, f]
end.
Alternativamente, un proceso puede ser capaz de transferir derechos de acceso, pero

perderá entonces el derecho al hacerlo. Esto es modelado con la bandera de sólo
transferencia (denotada por +). El siguiente comando transfiere el acceso R bajo estas
condiciones:
command transfer-only.read (p, q, f)

if R+ in A[p, f]
then delete R+ from A[p, f];
enter R+ into A[q, f]
end.
El propietario de un objeto debe ser capaz de conferir los derechos con o sin cualquier
de las banderas. Algunos sistemas permiten a un proceso generar procesos
subordinados y controlar los derechos de acceso de estos subordinados. Con el
siguiente comando, un proceso p puede crear un subordinado q teniendo un segmento
de memoria m:
command create.subordinate (p, q, m)

create sujeto q;
create objeto m;
enter Ctrl into A[p, q]
enter R into A[q, m]
enter W into A[q, m]
enter E into A[q, m]
end.
Un proceso p da el derecho Ctrl a q, lo que le permite tomar o revocar cualquier

derecho sobre q, incluyendo los que le confiere q a otros procesos. En el siguiente
comando p da acceso R a q sobre el segmento de memoria:
command take.subordinate.read (p, q, m)

if Ctrl in A[p, q] and R in A[p, m]
then enter R in A[q, m]
end.
El siguiente comando revoca a q el acceso R sobre el archivo f:
command revoke.subordinate.read (p, q, f)

if Ctrl in A[p, q]
then delete R from A[q,f]
end.
Si el formato de nuestro comando permite disyunciones, se puede combinar

revoke.subordinate.read con revoke.read:
command revoke.read (p, q, f)

if Own in A[p, f] or Ctrl in A [p, q]
then delete R from A [q, f]
end.
Figura 2. Matriz de acceso después de la secuencia de comandos.
Referencias
x
[1] Butler W. Lampson. “Protection”. Proc. 5th Princeton Conf. on Information Sciences
and Systems, Princeton. 1971.
[2] Michael A. Harrison, Walter L. Ruzzo and Jeffrey D. Ullman. “Protection in Operating
Systems”. Communications of ACM. Vol. 19, No. 8. pp. 461-471. 1976.
[3] James P. Anderson. “Computer Security Technology Planning Study”. Deputy for
command and management systems. Electronic Systems Division. ESD-TR-73-51. Vol
1. 1972.
[4] G. Scott Graham and Peter J. Dennig. “Protection - Principles and Practice”. Spring
Joint Computer Conference. pp. 417-429. 1972.
REALIZAR:
1. Con base en el comportamiento de las operaciones primitivas, define

a) el comando Eliminar archivo.
b) el comando Crear proceso
Capítulo VIII
Modelos de
seguridad
Un sistema lo consideraremos seguro si podemos confiar en él, y se comporta como los
usuarios esperan que lo haga. Por otra parte si vemos al sistema como un autómata
finito y contamos con un conjunto de operaciones que le permiten pasar de un estado a
otro, entonces podemos definir a los estados en autorizados (seguros) y no autorizados
(no seguros). Bajo esto, podemos decir que un sistema es seguro si inicia en un estado
autorizado y nunca entra en un estado no autorizado; pero si llegase a caer, aplicando
una operación, en un estado no autorizado entonces el sistema tiene un problema de
seguridad.
1. Introducción
En los sistemas de computo los tipos de seguridad que podemos aplicar a los datos los
podemos clasificar en:
• Confidencial. Sea X un conjunto de entidades e Y una cierta información. Entonces
Y tiene la propiedad de confidencialidad con respecto de X si ningún x∈X puede
obtener información sobre Y.
• Integridad. Sea X un conjunto de entidades e Y una cierta información. Entonces Y
tiene la propiedad de integridad con respecto de X si todos los x∈X confían en Y.
• Disponibilidad. Sea X un conjunto de entidades e Y una cierta información.
Entonces Y tiene la propiedad de disponibilidad con respecto de X si todos los x∈X
pueden acceder a Y.
La aplicación de ellos depende en primeramente del modelo que se aplica en el

sistema, y de lo que se desea asegurar en dicho sistema. En las secciones siguientes
veremos algunos de los modelos que existen para proteger la información de usuarios
no autorizados.
2. Modelo de Bell-LaPadula
La siguiente información mostrada está basada en el artículo de Elliott Bell, Leonard J.
LaPadula (1973): Secure Computer Systems: Mathematical Foundations.
El modelo de Bella-LaPadula (BLP) es una descripción formal (matemática) del control

de acceso obligatorio. El cual tiene tres propiedades: Propiedad ds (seguridad
x
discrecional), Propiedad ss (seguridad simple - No “read up”) y Propiedad *

(propiedad estrella- No “write down”). Bajo este modelo se considera a un sistema como
seguro si satisface todas las anteriores propiedades. BLP incluye las demostraciones
matemáticas de que si un sistema es seguro y una transacción satisface todas las
propiedades entonces el sistema seguirá siendo seguro.
Para colocar un orden de clasificación de seguridad, BLP opta por colocar lo siguiente:
– Ultra Secreto: Nivel más alto
– Secreto
– Confidencial
– No clasificada: Nivel más bajo
Diremos que los sujetos tienen cierto nivel de habilitaciones de seguridad y

escribiremos L(S), y diremos que los objetos tienen cierta clasificaciones de seguridad
y escribiremos L(O).
Por lo que las propiedades que puede tener un sujeto sobre un objeto las podemos
describir en forma temporal de la siguiente manera.
Propiedad SS (Condición de Seguridad Simple). Versión Preliminar

El sujeto S puede leer el objeto O sii L(O) ≤ L(S) y S tiene permiso para leer el
objeto O
El modelo combina control de acceso obligatorio (relaciones entre niveles de seguridad)

y control discrecional (el permiso requerido). Esta propiedad también es conocida como
la Regla de “Read Down”, lo cual quiere indicar, que el sujeto sólo puede leer un objeto
que se encuentra en su mismo nivel o en un nivel inferior.
Propiedad * (Propiedad Estrella). Versión Preliminar

El sujeto S puede escribir el objeto O sii L(S) ≤ L(O) y S tiene permiso de
escritura para O
El modelo combina control de acceso obligatorio (relaciones entre niveles de seguridad)

y control discrecional (el permiso requerido)
Esta propiedad también es conocida como la Regla de “Write Up”, lo cual indica, que el
sujeto sólo puede escribir un objeto en su mismo nivel o en un nivel superior. Con base
en estas dos propiedades se desprende el siguiente teorema de seguridad.
Teorema Básico de Seguridad (Versión Preliminar)

Sea S un sistema con un estado de seguridad inicial S o, y T un conjunto de
estados de transformaciones. Si cada elemento de T preserva la condición de
seguridad simple (versión preliminar) y la propiedad * (versión preliminar)
entonces cada Si, i ≥0, es seguro.
Expandiendo el modelo añadiendo un conjunto de categorías para cada clasificación

de seguridad. Donde cada categoría describe un tipo de información.
Los objetos colocados en múltiples categorías tienen el mismo tipo de información en

todas esas categorías. Estas categorías surgen del principio de la “necesidad de
conocer”, la cual señala que ningún sujeto debe ser capaz de leer los objetos sin
derechos de lectura sobre ellos, al menos de que sea necesario para dichos sujetos
para completar sus funciones de ejecución.
El conjunto de categorías a las que una persona puede tener acceso es simplemente el
conjunto potencial del conjunto de categorías. Por ejemplo, si las categorías son NUC,
EUR, y US, alguien puede tener acceso a cualquiera de los siguientes conjuntos de
categorías: ∅) = RETIRADA, donde ∅ es el conjunto vacío., {NUC},{EUR}, {US}, {NUC,EUR}, {NUC,US},{EUR,US}, y
{NUC,EUR,US}. Este conjunto de categorías forma una lattice bajo la operación de
subconjunto ⊆ .
Cada nivel de la seguridad y categoría forma en conjunto un nivel de seguridad. Al

igual que antes, decimos que los sujetos tienen acreditados un nivel de seguridad y
que los objetos están también en un nivel de seguridad.
Por ejemplo: Willy puede estar acreditado en el nivel (SECRET, {EUR}), Jorge dentro
del nivel (TOP SECRET,{NUC,US}). Un documento puede ser clasificado como
(CONFIDENCIAL, {EUR}). Los niveles de seguridad cambian el acceso. Debido a que
las categorías se basan en “una necesidad de conocer”, alguien con acceso a la
categoría {NUC,US} presumiblemente no tiene ninguna necesidad de accesar a los
elementos en la categoría EUR.
Aquí el acceso de lectura debe ser denegada, incluso si la seguridad acreditada del
sujeto es mayor (superior) que la seguridad de clasificación del objeto. Pero si el objeto
deseado está en cualquier nivel de seguridad ∅) = RETIRADA, donde ∅ es el conjunto vacío., {NUC},{US}, o {NUC,US}, y la
seguridad de acreditación del sujeto es nada menos que la clasificación de seguridad
del documento, debería permitir el acceso porque el sujeto esta acreditado en el mismo
conjunto de categoría del objeto.
Esto sugiere una nueva relación para cubrir la combinación de los conjuntos de
clasificación de seguridad y categoría. De esta manera se define dom (domina) como
sigue.
Definición
El nivel de seguridad (L,C) domina el nivel de seguridad (L´, C´) si y sólo si L´≤
L y C´⊆ C.
x
Al escribir (L,C) ¬dom(L´, C´) donde (L,C) dom (L´, C´) es falso. Esta relación además
induce a una lattice sobre el conjunto de los niveles de seguridad.
Ejemplo: Supongamos que:

Jorge esta acreditado dentro del nivel de seguridad (SECRET, { NUC, EUR} ),
Luis está acreditado como ( CONFIDENCIAL, { NUC } ),
Pedro está acreditado como ( SECRET, { EUR, US}), y
Hugo está acreditado como (SECRET, { EUR }).
Entonces:
Jorge dom Luis como CONFIDENCIAL ≤ SECRET y { NUC }⊆ { NUC, EUR }
Jorge ¬dom Pedro como { EUR, US }⊈{ NUC, EUR } { NUC, EUR }
Jorge dom Hugo como SECRET ≤SECRET y { EUR } ⊆ { NUC, EUR }
Sea L(S) la categoría del conjunto de sujetos S, y sea L(O) la categoría del conjunto de
objetos O. La condición de seguridad simple, versión preliminar, es modificada como:
Propiedad SS (Condición de Seguridad Simple).

El sujeto S puede leer el objeto O sii L(S) dom L(O) y S tiene permiso para leer
el objeto O
Propiedad * (Propiedad Estrella).

El sujeto S puede escribir el objeto O sii L(O) dom L(S) y S tiene permiso de
escritura para O
Con base a estas dos propiedades modificadas bajo un domino se desprende la nueva
versión del teorema de seguridad.
Teorema Básico de Seguridad

Sea S un sistema con un estado de seguridad inicial S o, y T un conjunto de
estados de transformaciones. Si cada elemento de T preserva la condición de
seguridad simple y la propiedad * entonces cada Si, i ≥0, es seguro.
3. Modelo de Biba
La siguiente información se ha tomado del reporte de K. J. Biba (1975): Integrity
Considerations for Secure Computer Systems. The Mitre Corporation. Bedford,
Massachusetts.
3.1. Introducción al modelo de Biba

El modelo de Biba fue publicado en 1977 en la Mitre Corporation, un año después del
modelo de Bell La-Padula. Como vimos antes, el modelo de Bell-LaPadula garantiza la
confidencialidad de los datos pero no su integridad. Biba crea un modelo dirigido a la
necesidad de cubrir la integridad en un sistema de cómputo, donde existen un conjunto
de sujetos y un conjunto de objetos. Los sujetos son componentes activos en el
sistema tales como procesos creados por los usuarios. Los objetos son un conjunto de
entidades protegidas en el sistema tales como los archivos. El modelo de Biba propone
un grupo de políticas de integridad donde a cada sujeto y objeto se le asigna una
etiqueta de integridad, y a cada política se le considere diferentes condiciones para
garantizar la integridad de la información. Estas poíticas pueden ser políticas
discrecionales y políticas no discrecionales. Así como el modelo de Bell La-Padula usa

etiquetas para dar acceso a un nivel al sujeto y nivel de clasificación a los objetos, el
modelo de Biba usa etiquetas para definir seguridad, pero en este caso las etiquetas
asignan niveles de integridad a los sujetos y objetos. Los datos marcados con un nivel
alto de integridad serán mas precisos y fiables que los datos marcados con un nivel
bajo de integridad.
Esta política de integridad obligatoria estricta garantiza “no escribir-arriba - no write-up”

y “no leer-abajo - read-down” sobre los datos en el sistema, lo cuál es lo opuesto del
modelo Bell-LaPadula. Restringiendo la contaminación de los datos en el nivel superior,
ya que un sujeto sólo se le permite la modificación a su mismo nivel o nivel inferior.
El “no write up” es esencial ya que limita el daño que puede ser ocasionado por objetos
maliciosos en el sistema. Por ejemplo, “no write up” limita la cantidad de daño que
puede ser hecho por los caballos de troya en el sistema. Si el código malicioso se
oculta en un sujeto que sólo tiene habilitado escribir a objetos en su mismo nivel o nivel
inferior. El “no read down” impide que un sujeto de confianza sea contaminado por un
objeto de menor confianza.
La propiedad de integridad estricta es la más restrictiva de las políticas implantadas por

el modelo de Biba. Esta propiedad tiene éxito en hacer cumplir la integridad de un
sistema, pero no deja de tener sus debilidades. Especialmente, esta propiedad restringe
la lectura de objetos de nivel inferior que puede ser demasiado restrictiva en algunos
casos. Para combatir este problema, Biba ideó una serie de políticas de integridad
dinámica que permitirán a los sujetos de confianza accesar a objetos o sujetos que no
sean de confianza. Biba implemento esto en un número de diferentes políticas llamadas
marcas de agua-baja – low-water-mark.
A continuación se presenta la información versada en el reporte del 1975 de Biba,

iniciando con algunas nociones fundamentales.
3.2. Nociones fundamentales
Biba basa su proyectos en las siguientes nociones fundamentales:

1. el monitor de referencia;
2. una política de seguridad formalizada; y
3. el concepto de núcleo.
Monitor de referencia
El monitor de referencia es una noción abstracta para dar solución genérica al problema
de protección de los sistemas.
x
Monitor
Sujetos de Objetos
referencia
Políticas de protección
Figura 5-1. Un monitor de referencia.
Un monitor de referencia es una entidad que monitorea y decide la permisibilidad de

todos los accesos de las entidades que procesan información (sujetos) a los repositorios
donde se encuentra dicha información (objetos). La política de protección aplicada por
el monitor de referencia, se refleja en la base de datos en la que se codifica la decisión
de admisibilidad.
Un monitor de referencia debe satisfacer tres propiedades lógicas:

1. Ser completo: todos los accesos de los sujetos a los objetos son monitoreados y
aplicados;
2. Estar protegido: su función no puede ser modificada malintencionada o
accidentalmente por acciones no autorizadas; y
3. Tener un comportamiento demostrablemente correcto: debe hacer cumplir
fielmente la política de protección especificada.
Se define los siguientes axiomas para restringir el acceso de los sujetos a los objetos.
Donde S es el conjunto de sujetos, O es el conjunto de objetos y una relación
a⊆S×O que denota que un sujeto s puede accesar a un objeto o; y una función
dominio: S → POWERSET(O).
Axioma 1.1 Definición de la función del monitor de referencia
∀ s∈ S , o∈O s a o→o∈dominio(s)
El axioma 1.1 especifica que un sujeto s puede acceder a un objeto o sólo si o está en
dominio de s. La función dominio es una codificación de una política de protección que
identifica la accesibilidad al espacio de nombres por parte del sujeto.
Una política de protección toma la forma de un algoritmo de decisión que define los
espacios de nombres (o particiones de espacios de nombres) asignados a sujetos. Las
líneas punteadas de la Figura 5-2 representan los dominios de acceso dos sujetos S1 y
S2. Las flechas tienen la siguiente interpretación: las flechas que apuntan a un objeto
representan una modificación de un objeto por parte de un sujeto; las flechas que
apuntan a un sujeto desde un objeto representan una observación del objeto por parte
del sujeto.
1 4
2 a
a a a
a a
S1 3 S2
Dominio (S1) Dominio (S2)
Figura 5-2 Dominios de acceso.
Modos de acceso.
Existe tres modos de acceso básicos a los objetos por parte de los sujetos:
1. Observación. El sujeto puede visualizar la información. El sujeto que puede
observar puede elegir basado en la información observada.
2. Modificación. Puede definirse en términos de observación, es decir, un sujeto
modifica la información si cambia de modo después de una observación.
3. Invocación. La invocación es una solicitud lógica de servicio de un sujeto a otro.
Debido a que el estado de control del sujeto invocado esta en función del hecho
que el sujeto fue invocado, se dice que la invocación es un caso especial de
modificación.
La invocación es una abstracción del constructor de control primario para transferir el

control entre distintos sujetos, posiblemente, entre diferentes dominios de acceso. La
comunicación entre procesos es una instancia de un mecanismo de invocación donde la
señal de activación que pasa del proceso invocador al proceso invocado constituye la
invocación. Un tipo de subrutina de estructura de control entre sujetos puede lograrse
mediante dos invocaciones: el invocador primero señala (enviar una señal) al sujeto in-
vocado y luego espera a que el sujeto invocado lo (regrese una señal) reactive a través
de una invocación posterior. Una consecuencia necesaria del tipo de estructura de
control de una subrutina es que los sujetos invocadores e invocados deben tener
privilegios de invocación entre sí.
Cabe señalar que el acceso de "ejecución" es bastante diferente a la invocación.

Mientras que la invocación representa un acceso de control entre distintos sujetos,
posiblemente en diferentes dominios, la ejecución es el acceso, por parte de un sujeto,
a un objeto con el fin de obtener instrucciones. Dado que durante la ejecución un sujeto
obtiene sus instrucciones al observar el objeto en el que residen las instrucciones, se
considera que el acceso de ejecución es equivalente al acceso de observación.
x
Políticas de seguridad formalizada.

El modelo de políticas de seguridad propuesto por Biba contiene los siguientes
elementos:
S: Un conjunto de sujetos,
O: Un conjunto de objetos, donde la intersección de S y O es nula,
SL: Un conjunto parcialmente ordenado de niveles de seguridad que forman una red
(lattice),
sl: S×O→ SL Una función que mapea sujetos y objetos dentro de los niveles de
seguridad,
≤: Un subconjunto SL×SL que define el orden parcial “menor que o igual”,
o: Un subconjunto S×O que define la capacidad de acceso para observación, y
m: Un subconjunto S×O que define la capacidad de acceso para modificación.
El dominio de acceso de cada sujeto se divide con respecto al modo de acceso. Para
ello se presentan los siguientes axiomas.
Axioma 1.2 Dominio de acceso de observación de cada sujeto

∀ s ∈S , o ∈O s o o → s l (o) ≤ sl (s )
Axioma 1.3 Dominio de acceso de modificación de cada sujeto

∀ s ∈S , o ∈O s m o → s l ( s)≤ s l (o)
De los axiomas anteriores se tiene entonces que, el dominio de acceso de cada sujeto s
es entonces el conjunto
{o∈O∣sl (o)≤sl (s)∨sl ( s)≤s l (o)}
Un sujeto puede observar la información contenida dentro de un objeto si su nivel es

mayor que o igual que la del objeto. Un sujeto puede modificar la información contenida
dentro un objeto si su nivel de seguridad es menor que o igual que la del objeto. Estas
restricciones aseguran que la información se transfiera sólo “hacia arriba” en el nivel de
seguridad, incluso para sujetos que no son de confianza y actuen como propietarios.
Se puede extender los axiomas anteriores para la invocación entre sujetos mediante la
relación i : subconjuto S×S que define la capacidad de acceso para la invocación
entre sujetos.
Axioma 1.4 Dominio de acceso de invocación de cada sujeto

∀ s1 , s2 ∈ S s1 i s 2 → sl (s 1) ≤s l (s 2)
Concepto de kernel.
La implementación de un monitor de referencia dentro de un sistema de cómputo se
denomina kernel. Conceptualmente, el kernel es el centro de sistema de
hardware/software que aplica la política de protección del monitor de referencia. El
kernel define una máquina abstracta compuesta de operaciones y objetos lógicos, cuyo
acceso está determinado por la política de protección. Una parte crucial del proceso de
desarrollo del kernel es la verificación formal de la propiedad: la política de protección
se aplica para todos los accesos designados.
3.3. Problema de Integridad
Un subsistema posee la propiedad de integridad si se puede confiar en que se apega a

un código de comportamiento bien definido. Ninguna declaración a priori sobre las
propiedades de este comportamiento es relevante. Por lo tanto, la integridad de un
sistema de cómputo es la garantía de que un subsistema funcionará como su creador
lo concibió. El problema de integridad es la formulación de políticas y mecanismos de
control de acceso que proporcionan a un subsistema el aislamiento necesario para la
protección.
La forma abstracta de una amenaza a la integridad es una modificación del subsistema

que no se considera en la verificación inicial del comportamiento adecuado del
subsistema. Biba considera dos dimensiones de amenazas contra la integridad de un
subsistema: fuente y tipo. Las amenazas de integridad de fuente identifican dónde se
puede originar una amenaza, mientras que la amenaza de tipo identifica cómo llevarla a
cabo.
Amenazas de fuente
Se consideran dos fuentes de amenazas:
1) subsistema externo; y
2) subsistema interno.
El origen del ataque está implícito en su nombre. Una amenaza externa es planteada
por un subsistema que intenta, indebidamente, cambiar el comportamiento de otro
subsistema, mediante datos falsos, invocaciones indebidas o la modificación directa de
su propio comportamiento. Una amenaza interna se presentan si el subsistema es
malicioso o realiza funciones incorrectas.
Amenazas de tipo
Este tipo de amenazas se clasifican en:
1. Directas (abierto), e
2. Indirectas (encubierta).
Las amenazas directas implican medios "directos": una escritura en un objeto de base
de datos protegido. Se deben considerar, en este caso, solamente las propiedades de
protección del sujeto que accede y del objeto accedido. Las amenazas indirectas
incluyen una clase mucho más grande de escenarios. Generalmente, las amenazas
indirectas se refieren a modificaciones inapropiadas que resultan del uso de datos o
procedimientos realizados (modificados) por un subsistema malicioso. Estos datos
(procedimiento), al no cumplir con los requisitos esperados, pueden sabotear las
funciones de sus usuarios. Esta estructura requiere conocimiento, de cada acceso,
tanto de la última fuente como de la ruta de transferencia de la información a la que se
accede. Ejemplos de amenazas de tipo pueden ser:
• Directo externo. Un subsistema modifica maliciosamente el código de ejecución
de una base de datos de otro subsistema.
• Indirecta externa. Un subsistema coloca en otro subsistema una subrutina con
comportamiento malicioso (ataque de caballo de troya).
• Directo interno. Código automodificable.
• Indirecto interno. Código automodificable involuntario, por ejemplo, apuntadores
inicializados incorrectamente.
x
Cumplimiento de las poíticas de Integridad

La preocupación principal es identificar las modificaciones que preservan validez
(propiedades previstas) de los elementos del sistema de cómputo. La política de
integridad debe organizar de manera concisa la información para que un mecanismo de
cumplimiento a la evaluación de un acceso determinado, para ello de tienen dos
aspectos que rigen la política:
1. Mecanismos de ejecución disponibles; y
2. Problemas de integridad que debe abordar el sistema.
Frecuencia de aplicación
Estático
Frecuencia de granularidad
Grueso Fino
Dinámico
Figura 5-3. Mecanismos de aplicación.
El espacio de los mecanismos de aplicación se muestran en la Figura 5-3. Se pueden

identificacan dos dimensiones: la frecuencia de la aplicación y la granularidad de la
aplicación. La frecuencia se refiere al tiempo en el que se produce la aplicación del
control de acceso. Si la aplicación se realiza sólo una vez (es decir, en el momento en
que se crea un programa), la frecuencia se denomina estática. Si la aplicación se realiza
en cada acceso de un programa a un objeto, la frecuencia se denomina dinámica. La
verificación del programa sola una vez como idoneidad del acceso es un mecanismo de
cumplimiento estático. Los mecanismos descriptores de hardware admiten la aplicación
dinámica. La granularidad se refiere al tamaño y la resolución de los elementos del
sistema protegido. Para la aplicación efectiva de una política de integridad, la
granularidad de la aplicación debe coincidir con la granularidad de la política. Por
ejemplo, si una política de protección controla el acceso a partes de un archivo, un
mecanismo de aplicación que sólo controle el acceso a todo el archivo no puede
implementar la política de manera efectiva.
Problemas de integridad
Las interpretaciones específicas de la noción de modificación "adecuada" y las
consiguientes políticas de protección dependen de los requisitos de protección
específicos del problema. Biba se enfoca en tres clases de modificaciones adecuadas:
1. Propiedad de modificación con respecto a la importancia de información de la
seguridad;
2. Propiedad de modificación con respecto a la identidad de acceso de un usuario
(“necesidad para modificar”); y
3. Propiedad de modificación con respecto razones especificas de la aplicación.
Ambiente de protección
Los subsistemas de un sistema de cómputo realizan diferentes funciones y, por lo tanto,
a menudo requieren diferentes políticas de integridad. Los requisitos de protección
están además en función de la perspectiva a tomar en consideración por los

subsistemas:
1. cada usuario del sistema tiene (al menos) un proceso ejecutándose;
2. cada proceso está compuesto de un número de sujetos y objetos, divididos
dentro de dominios de privilegios acceso dentro de cada proceso; y
3. algún subconjunto de los sujetos y objetos con más privilegiados dentro de cada
proceso define el subsistema protegido que comprende el kernel de seguridad.
Con base en estas definiciones, se puede identificar dos ambientes con distintos
requisitos de integridad:
1. el conjunto de sujetos y objetos no contenidos en el kernel de seguridad. Estos
se denominarán colectivamente como el ambiente virtual del usuario; y
2. el conjunto de sujetos y objetos que componen el kernel de seguridad. Estos se
denominarán colectivamente como el ambiente del kernel.
3.4. Políticas de Integridad
Biba define dos clases de política de integridad: obligatoria y discrecional. Ellas

difieren en la forma en que se puede cambiar la política de protección, una vez
realizadas. La política de integridad obligatoria se refiere a una política de protección
que, una vez definida para un objeto, no se puede cambiar y debe cumplirse para todos
los estados del sistema (mientras exista el objeto). La naturaleza estática de la política
se rige por controles externos (del sistema). Por otro lado, una política de integridad
discrecional es aquella en la que la política de protección puede ser definida
dinámicamente (durante la existencia de un objeto) por el usuario.
Política de integridad obligatoria

Una política de protección obligatoria debe considerar dos aspectos:
1) la identificación de objetos abstractos protegidos, y
2) la determinación del acceso de modificación permisible.
Los siguientes análisis definen un conjunto de primitivas para el modelo que, aunque
comparten una identificación de objeto abstracto común, proponen diferentes políticas
para restringir el acceso.
Cada política se define como un conjunto de relaciones, una para cada tipo de modo de
acceso definido, sobre los conjuntos de elementos activos y pasivos del sistema de
cómputo. Esta categorización identifica los elementos del sistema que realizan accesos
a la información (sujetos) y aquellos a los que se accede (objetos). Claramente,
diferentes políticas de protección pueden proteger diferentes tipos de objetos de
diferentes tipos de accesos de sujetos. Por lo tanto, la identificación de sujetos y objetos
a menudo depende de la política. Una política de protección se identifica mediante una
regla de decisión que determina las relaciones de acceso.
El conjunto de clases de integridad puede estar separado del conjunto de clases de

seguridad. Sin embargo, estos conjuntos tendrán propiedades comunes. De hecho, un
conjunto de clases de integridad puede definirse como:
• Máximo secreto (Top secret): información cuya modificación no autorizada
podría esperarse razonablemente que cause un daño excepcionalmente grave a
la seguridad;
• Secreto: información cuya modificación no autorizada podría esperarse
razonablemente que cause un daño grave a nuestra seguridad; y
x
• Confidencial: información cuya modificación no autorizada razonablemente

podría causar daño a nuestra seguridad.
Para indicar el nivel de integridad se toman las siguientes etiquetas: TS para máximo
secreto, S para secreto, y C para confidencial. Tienendo ellos un orden parcial C < S <
TS.
Definiciones
Cada modelo tiene los siguientes elementos:
S: El conjunto de sujetos s, los elementos activos de procesamiento de información del
sistema de cómputo;
O: El conjunto de objetos o, los elementos pasivos del repositorio de información del
sistema de cómputo;
I: El conjunto de niveles de integridad;
il: S×O→ I una función que mapea el nivel de integridad de cada sujeto y objeto;
define una red (lattice) bajo la relación ≤;
≤: Una relación (un subconjunto I ×I ) que define el orden parcial “menor que o igual”
en el conjunto de niveles de integridad I;
<: Una relación transitiva antisimetría (un subconjunto I ×I ) que define la relación
“menor que” en el conjunto de niveles de integridad I;
min: POWERSET (I )→I Una función que retorna el mayor de los menores
(conocido) del subconjunto de I especificado;
o: Una relación (subconjunto S×O ) que define la capacidad de un sujeto, s ∈S ,
para observación de un objeto, o∈O :s o o ;
m: Una relación (subconjunto S×O ) que define la capacidad de un sujeto, s ∈S ,
para modificación de un objeto, o∈O :s mo ;
i: Una relación (subconjunto S×S ) que define la capacidad de un sujeto, s 1 ∈S ,
para invocación de otro sujeto, s 2 ∈S : s1 i s 2 ;
A continuación se describen tres políticas alternativas de integridad obligatoria.
Política Obligatoria de marca de agua-baja (Lower-Water Mark)

para sujetos
El modelo de marca de agua-baja es dinámico, en el sentido de que el nivel de

integridad de un sujeto no es estático, sino que es una función de su comportamiento
previo.
La política prevé un valor dinámico, monótono y no creciente de il (s) para cada sujeto.
El valor de il(s), en cualquier momento, refleja la marca de agua-baja del
comportamiento previo del sujeto. La marca de agua-baja es el nivel de integridad
mínimo de un objeto al que accede el sujeto para su observación. Además, un sujeto
está obligado a modificar sólo aquellos objetos que poseen un nivel de integridad
inferior o igual al del sujeto. Las propiedades se formalizan mediante los siguientes
axiomas.
Axioma 1.5
Para cada acceso de observación de un un sujeto s sobre un objeto o, el nivel de
integridad del sujeto il'(s), inmediatamente posterior al acceso, se define por:
i l ' ( s)=min{i l (s), i l (o)}
Donde i1(s) es el nivel de integridad de s inmediatamente anterior al acceso.
Axioma 1.6
Para cada acceso de modificación de un un sujeto s sobre un objeto o.
∀ s∈S , o∈O s m o→i l ( o)⩽i l ( s)
Axioma 1.7
Para cada acceso de invocación de un un sujeto s1 sobre un sujeto s2.
∀ s1 , s2 ∈S s1 i s 2 → i l (s 2)≤i l (s1 )
El axioma 1.6 garantiza que la modificación directa en forma maliciosa es imposible, y el

axioma 1.5 garantiza que el sabotaje indirecto usado para “contaminar” datos o
procedimiento es también imposible. El axioma 1.7 asegura que la activación incorrecta
de sujetos con mayor privilegios no causa daños indirectos a objetos de nivel de
integridad “superior”.
Definición 1
Una ruta de transferencia de información es una secuencia de objetos {o 1, … , on+1} y
una correspondiente secuencia de sujetos { s1, … , sn } tal que
∀ i ∈(1,. .. , n) si o o i ∧ si m oi +1
Teorema 1
Si existe una ruta de transferencia de información del o1 ∈O a el objeto o n+1 ∈O
entonces la aplicación de la política de marca de agua-baja requiere
i l (o n+1 )⩽i l (o 1)
Política Obligatoria de marca de agua-baja para objetos

Las discusiones anteriores asumen explícitamente que es el nivel de integridad de los
sujetos lo que cambia. Una formulación alternativa postula que lo que cambia es el nivel
de integridad de los objetos modificados.
Para cada acceso de observación de un sujeto s sobre un objeto o:

i ' l ( s)=min{i l (s), i l ( o)}
Para cada acceso de modificación de un sujeto s sobre un objeto o:

i ' l ( o)=min{i l (s) , i l (o)}
Debería ser evidente que el nivel de integridad de un objeto (o sujeto) determinado no

aumenta de forma monótona. El comportamiento imprudente por parte de los sujetos
dará como resultado que cada sujeto y objeto posea el nivel de integridad más bajo de
cualquier objeto al que se acceda. Además, esta política no impide la modificación
indebida; más bien asegura que dichas modificaciones sean evidentes. Por lo tanto,
esta política parece adecuada para un entorno de un sistema cómputo.
Política de auditoría de integridad de marca de agua-baja

Una variante del modelo anterior, es un modelo de “nivel de corrupción”, que
proporciona una medida de posible corrupción de bases de datos de información de
nivel de integridad “más bajo”. Se define para sujetos y objetos un “nivel de corrupción
actual” (llamado cl ).
x
Definición. Auditoría.
Para cada acceso de observación de un sujeto s sobre un objeto o:
c l ( s)=min {c l (s ), cl (o)}
Definición. Auditoría.
Para cada acceso de modificación de un sujeto s sobre un objeto o:
c l ( o)=min{c l (s), c l ( o)}
El valor de cl para un objeto representa el nivel mínimo de integridad de la información

que podría haberse utilizado para modificar el objeto.
Política de Anillo
En la secciones anteriores se identificaron dos clases de modificaciones impropias:
directas e indirectas. La política de marca de agua-baja abordó directamente el
problema de la modificación directa: prohibió las modificaciones directas (Axioma 1.6 y
Axioma 1.7). Las modificaciones incorrectas indirectas se evitaron mediante un cambio
en el nivel de integridad del sujeto que accede (y, por lo tanto, su dominio de acceso).
La política de anillo proporciona la aplicación del kernel sólo de una política de
protección que aborda la modificación directa. Los niveles de integridad tanto de los
sujetos como de los objetos se fijan durante su vida útil y sólo se permiten
modificaciones de objetos de menor o igual nivel de integridad. Si bien permite
garantías de integridad menos sustanciales, particularmente en lo que respecta a la
modificación incorrecta indirecta, la flexibilidad del sistema aumenta sustancialmente.
Esto se logra al permitir la observación de objetos en cualquier nivel de integridad. La
política esta definida por los siguientes axiomas.
Axioma 1.8
∀ o ∈O , s ∈S s m o→i l ( o)⩽i l ( s)
Axioma 1.9
∀ s1 , s2 ∈S s1 i s 2 → i l (s 2)≤i l (s1 )
Por construcción, ningún objeto de un nivel de integridad "mayor" o "incomparable"

puede ser modificado (o invocado indebidamente) por un sujeto dado.
Por supuesto, la corrupción de bases de datos (y programas) a nivel de integridad de un

sujeto es la responsabilidad programada del sujeto. Dado que ningún control externo de
actividad evita la posibilidad de corromper las observaciones, el sujeto debe
proporcionar controles internos para validar los datos observados. La verificación del
programa (de alguna forma) debe asegurar que no ocurra tal corrupción. Sin embargo,
la falta de restricciones en el acceso a la observación permite un rango mucho más
amplio de discreción (y responsabilidad) a los sujetos en cuanto a la validez de los
datos y procedimientos observados.
Política de integridad estricta

La política de integridad estricta puede considerarse el "complemento" o "dualidad" de
la política de seguridad de Bell-Lapadula. Consta de dos axiomas que, son análogos a
su condición de seguridad simple y la propiedad *, impiden el sabotaje directo e
indirecto de la información. En este caso, en cuanto a la seguridad, esta propiedad es

verdadera sólo en la medida en que los niveles de integridad se asignan correctamente
a sujetos y objetos. En muchos sentidos, esta política proporciona las mismas
capacidades que la política de marca de agua-baja. Sin embargo, cuando la marca más
baja cambia el nivel de integridad de un sujeto para evitar el sabotaje indirecto, la
integridad estricta prohíbe el acceso. Esta estrategia permite la recuperación simple del
acceso inadecuado (observar): una situación que no se encuentra en la política de
marca de agua-baja. Sin embargo, esto se logra al precio de hacer muchos objetos
inaccesibles (no observables) para un sujeto dado. Los siguientes tres axiomas
caracterizan la política de integridad estricta.
Axioma 1.10
∀ s∈S , o∈O s o o→i l (s)⩽i l (o)
Axioma 1.11
∀ s∈S , o∈O s m o→i l ( o)⩽i l ( s)
Axioma 1.12
∀ s1 , s2 ∈S s1 i s 2 → i l (s 2)≤i l (s1 )
La satisfacción de Axioma 1.11 asegura que los objetos no puedan ser modificados
directamente por sujetos que no posean privilegios suficientes. Sin embargo, esto
supone que las modificaciones realizadas por un sujeto autorizado están bajo la
dirección explícita de un programa no malicioso. Claramente, el uso irrestricto de
subsistemas escritos por usuarios arbitrarios (cuyo carácter no malicioso que no se
puede atestiguar) no satisface esta suposición. Así, Axioma 1.10 restringe el uso de
subsistemas (datos o procedimientos) a aquellos cuyo carácter no malicioso (en virtud
de su nivel de integridad) pueda acreditar el sujeto: aquellos objetos que tienen un nivel
de integridad mayor o igual al del sujeto . Ahora podemos asegurarnos de que el
carácter no malicioso de estos objetos se conserva al demostrar que no se puede
transferir información (según los axiomas anteriores) de objetos con un nivel de
integridad "bajo" a otros con un nivel de integridad "superior" (similar a Teorema 1).
Teorema 2
Si existe una ruta de transferencia de información del o1 ∈O a el objeto o n+1 ∈O
entonces la aplicación de la política de integridad estricta requiere
i l (o n+1 )⩽i l (o 1)
Política de integridad discrecional

Las secciones anteriores han considerado la integridad obligatoria, sin embargo, los
problemas de protección de integridad se encuentran tambien en gran variedad de
aplicaciones, por lo que en la siguiente sección se identificará explicitamente los
mecanismos y clases de políticas que pueden ser compatibles de para un kernel.
Listas de control de acceso

Las listas de control de acceso (ACL) son un mecanismo para la especificación del
modo de acceso a un objeto determinado por parte de los sujetos asociados con los
usuarios. El contenido de una lista de control de acceso puede ser modificada en forma
x
dinámica por un sujeto con privilegios apropiados, por lo cual tiene un carácter
discrecional.
El modelo está formado por los siguientes elementos:

U: Un conjunto de usuarios;
M: { “o”,”m”} conjunto de modos de acceso abstractos;
user: S →U una función que mapea sujetos a usuarios;
acl: O→ POWERSET (U → M ) una función que mapea objetos dentro de elementos
del producto cruz POWERSET de usuarios y modos de acceso – el conjunto de
elementos de ACL.
name: U×M →U una función para seleccionar el componente del usuario al
elemento ACL; y
modo: U×M →M una función para seleccionar el componente del modo de acceso
de un elemento ACL
Se considera que las siguientes restricciones de acceso solo se aplican a sujeto ->
acceso al objeto.
Axioma 1.13
∀ s∈S , o∈O s o o→∃acl e∈acl (o), name (acl e)=user (s)∧modo (acl e)=' o '
Axioma 1.14
∀ s∈S , o∈O s m o→∃acl e∈acl (o), name ( acl e)=user (s )∧modo (acl e)=' m' .
La función acl define la política de protección discrecional. El axioma 1.13 restringe los
accesos de observación a esos objetos nombrando específicamente al usuario del
sujeto que accede en su ACL. El axioma 1.14 restringe de manera similar los accesos
de modificación. Las relaciones o y m pueden cambiarse mediante modificaciones a
acl. Este privilegio para modificar acl está definido por el privilegio a modificar el objeto
en el que se encuentra acl.
Propiedades de protección
El problema del acceso de modificación directa se aborda mediante las especificaciones
explícitas del contenido de ACL (Axioma 1.14). Sin embargo, persisten dos problemas:
1) modificación indirecta, y 2) identificación de qué sujetos pueden modificar la política
de protección (cambiar la ACL). El problema de la modificación indirecta es difícil de
abordar con esta política/mecanismo. La política de integridad estricta hizo
declaraciones precisas con respecto a la modificación indirecta, ya que se definieron
clases estáticas definidas externamente de sujetos y objetos (niveles de integridad). Las
propiedades atribuidas externamente a sujetos y objetos de un nivel de integridad dado
permitieron alguna declaración sobre la preservación de estas propiedades. Sin
embargo, tal afirmación no puede hacerse fácilmente en este caso. El problema se ve
agravado por la naturaleza dinámica de las ACL. Dado que el conjunto de sujetos
(usuarios) que pueden acceder a un objeto no está bajo control externo, ninguna
propiedad de estos sujetos (usuarios) puede definirse externamente. Por lo tanto, no se
puede hacer ninguna declaración sobre las propiedades de los objetos accedidos
únicamente sobre la base de el mecanismo de control de acceso. De hecho, la falta de
"enunciados precisos" es una característica fundamental de la política discrecional, y es
esta característica la que tiende a distinguirla de la política no discrecional. También se

debe tener en cuenta el comportamiento de los sujetos que acceden, en particular a qué
usuarios (sujetos) delegan privilegios. A diferencia de los niveles de integridad y
seguridad, la protección que brindan las ACL es dinámica. Es decir, el conjunto de
usuarios y modos de acceso especificados por una ACL (acl) puede ser modificado por
un sujeto debidamente privilegiado. Para ciertos sistemas o arquitecturas, un sujeto
debidamente privilegiado es aquel que tiene acceso de modificación al directorio que
contiene la rama que define un objeto determinado. Dado que la capacidad de cambiar
la ACL de un objeto está representada por tener acceso de modificación a su directorio
contenedor, un sujeto que tenga dicho acceso puede darse acceso directo al objeto si
aún no tiene dicho acceso. De hecho, podemos aplicar esta noción recursivamente a la
jerarquía de archivos. Por lo tanto, cualquier sujeto que posea acceso de modificación a
un directorio, puede otorgarse a sí mismo (u otros sujetos) acceso discrecional a
cualquier elemento del subárbol enraizado en ese directorio.
Se puede formalizar lo anterior definiendo la jerarquía de directorio y redefiniendo los

modos de acceso o y m en tal jerarquía de acceso. Una jerarquía de objetos H puede
definirse como un árbol de raíz de objetos: un subconjunto del conjunto completo de ob-
jetos O. Se pueden definir los siguientes axiomas que establecen una relación ancestro
para el árbol.
Para o , p∈H ancestro(o , p) establece que p es un ancestro de o.
Axioma 1.15
∀ o ∈H ancestro(o , o)
Axioma 1.16
∀ o , p∈H ancestro(o , p)∧ancestro( p , o)→o= p
Axioma 1.17
∀ o , p , q∈H ancestro( o , p)∧ancestro( p , q)→ancestro(o ,q )
Axioma 1.18
∀ o , p , q∈H ancestro( o , p)∧ancestro( o , q)→ancestro (p ,q )∨ancestro (q , p)
Dada la definición anterior, podemos aumentar las relaciones o y m dado que para
acceder a cualquier objeto en H, un sujeto debe tener acceso a todos sus antepasados.
Axioma 1.19
∀ s∈S , o , p∈ H s o o∧ancestro(o , p)→s o p
Axioma 1.20
∀ s∈S , o , p∈H s m o∧ancestro(o , p)∧o≠ p→s o p
Además,identifcamos el conjunto de sujetos que pueden acceder a ellos mismos o dar

acceso a otro sujeto mediante la relación accesible (o,s) para sujetos o cambiando el
dominio del obejto.
x
Axioma 1.21
∀ s∈S , o∈ H accesible (o , s)→s ∈o∨∃ p∈H ancestro(o , p)∧s m p
La comunidad de usuarios y sujetos identificados por accesible son aquellos que tienen
o pueden obtener acceso a un objeto. Observamos que la definición de accesible y la
jerarquía de objetos se pueden extender a otras políticas de protección o
combinaciones de políticas.
El análisis anterior establece que varios sujetos, no determinados de forma única,

pueden determinar el contenido de ACL de un objeto dado. Por lo tanto, la protección
contra modificaciones que brindan las ACL en la jerarquía de archivos está limitada por
la propagación de privilegios. Debemos confiar en el conjunto de sujetos que tienen
acceso modificado a algún directorio superior (de un objeto dado) no solo para darse
acceso (y utilizarlo adecuadamente) sino también para no dar acceso a otros sujetos
(de otros usuarios). En un entorno caracterizado por una rápida rotación de usuarios y
un amplio intercambio de datos, la naturaleza dinámica de las ACL proporciona solo una
protección limitada contra modificaciones indebidas.
Anillos
La política/mecanismo de protección de anillos que se discute es un prototipo de la
política de anillos vista anteriormente, ofrece la capacidad de:
a) proteger un subsistema de su invocador; o
b) proteger a un invocador de un subsistema invocado.
No puede proporcionar ambas capacidades para cualquier combinación de invocación y

subsistema invocado. El esquema de protección que se describe difiere de la política de
anillos obligatorios en los siguientes aspectos: 1) es hardware soportado por un
procesador específico (Multics); 2) se aplica a diferentes elementos del sistema; los
sujetos particulares se asignan a procedimientos intraprocesos en lugar de procesos; 3)
se prevé la modificación del privilegio de acceso (cambio de asignación de anillo); y 4)
se proporciona una mayor flexibilidad para la invocación entre sujetos.
Modelo
Se definen los siguientes elementos:
R: Un conjunto finito de nombres de anillo, normalmente números enteros pequeños;
≤: Orden lineal “menor que o igual que” en R;
<: Orden lineal “menor que” en R;
r: Una función, S×R que define el anillo de ejecución para cada sujeto;
lir: Una función, S×R que define el límite inferior del anillo para cada sujeto
invocador;
uir: Una función, S×R que define el límite superior del anillo para cada sujeto
invocador;
umr: Una función, O×R que define el límite superior del anillo para cada acceso de
modificación; y
uor: Una función, O×R que define el límite superior del anillo para cada acceso de
observación;
Las restricciones de acceso se formalizan en los axiomas siguientes.
Axioma 1.22
∀ s1 , s 2∈ S , s 1 i s 2→(lir (s 2)≤r ( s 1)≤uir (s2 )∧r (s 2)< r ( s1 )∨r ( s 1)≤r ( s2 ))
El axioma 1.22 restringe un sujeto para invocar sujetos: 1) de mayor privilegio solo a
través de un rango permitido de anillos; y 2) de menor o igual privilegio
indiscriminadamente.
Axioma 1.23
∀ s∈S , o∈O s o o→r ( s)≤uor (o)
El axioma 1.23 restringe a los sujetos a observar sólo a objetos en un rango permitido
de los anillos: O≤r (s )≤uor ( o)
Axioma 1.24
∀ s∈S , o∈O s m o→r (s)≤umr (o)
El axioma 1.24 restringe a los sujetos a modificar sólo a objetos en un rango permitido
de los anillos: O≤r (s )≤umr (o)
Se considera que cada sujeto tiene un único punto de invocación (entrada), El aximio
1.22 restringe la invocación entre sujetos en una “zona” especifica de dominios (anillos).
Mientras el axioma 1.22 asume un límite inferior explícitamente especificado, los
axiomas 1.23 y 1.24 implicitamente asumen un límite inferior del elemento mínimo de R.
Se observa, en cuanto a las listas de control de acceso que este mecanismo puede no
aplicarse uniformemente a todos los sujetos, objetos y modos de acceso dentro de una
implementación específica. El análisis proporcionado anteriormente para las listas de
control de acceso se aplica a la estructura de protección del anillo. Al igual que las ACL,
la política de protección puede ser modificada por un sujeto debidamente privilegiado.
La capacidad de alterar los atributos de protección de un sujeto u objeto debe estar
restringida a sujetos de mayor o igual privilegio. La forma en que se restringe el acceso
depende de la forma en que se organizan los sujetos y los objetos.
4. Modelo de Clark-Wilson
El modelo BLP esta dirigido a políticas de seguridad militar, metas de descubrimiento no
autorizado de información. Sin embargo en muchos ambientes, el descubrimiento es
menos importante que la prevención de la modificación de datos no autorizados. Un
ejemplo de esto es el procesamiento de datos comerciales que manejan la
administración y la contabilidad de fondos financieros. En estos ambientes, la
prevención de fraudes es más importante que el descubrimiento de información.
El modelo Clark-Wilson fue desarrollado para ser aplicado en los ambientes

comerciales. Además de manifestar que las políticas de integridad son más importantes
que las políticas de descubrimiento, Clark y Wilson también afirman que existe un
conjunto distinto de políticas que pueden ser usadas para la integridad, y señalan que
se necesitan mecanismos separados para llevar a cabo lo anterior. Clark y Wilson
expresan que la meta preocupante de un sistema comercial con integridad de datos es
x
asegurar que un usuario no pueda modificar datos de alguna manera que ocasione
pérdidas, corrupción de fondos o contabilidad de registros de la compañía.
El modelo usa dos categorías de mecanismos para llevar a cabo esta meta. La primera
de ellas es llamada transacciones bien formadas (web-formed transactions) y la
segunda es la separación de derechos (separation of duty). El propósito de una
transacción bien formada es garantizar que un usuario no pueda alterar
arbitrariamente datos. En cambio, los datos sólo pueden ser alterados en formas
específicas que estrictamente restringen los cambios posibles en un orden para
preservar su consistencia interna. La separación de derechos intenta mantener la
consistencia de los objetos de datos, separando todos las operaciones en varias partes
y requiere que cada parte sea ejecutada por un sujeto diferente. Básicamente menciona
que cualquier usuario que tiene permitido iniciar una transacción bien formada no le
esta permitido ejecutarla. Por ejemplo, el proceso de comprar algunos productos puede
incluir varios pasos.
Los usuarios en sistemas BLP están restringidos a los datos que pueden acceder
mientras que en modelo Clark-Wilson están restringidos por los programas que pueden
ejecutar. Mientras que las políticas de seguridad BLP usan la tripleta sujeto-objeto-
mododeacceso para determinar la restricción de acceso, el modelo Clark-Wilson usa
sujeto-objeto-programa donde el modo de acceso, y en consecuencia la operación a
ser ejecutada en los datos, esta implícita en el programa a ejecutar.
Elementos del modelo

1. Elementos de datos restringidos (CDIs – Constrained Data Items) son los elementos
de datos en el sistema para los cuales el modelo de integridad debe ser aplicado.
2. Elementos de datos no restringidos (UDIs- Unconstrained Data Items) son los ele-
mentos que no están cubiertos en el modelo de integridad y pueden ser manipulados li-
bremente.
3.Procedimientos de transformación (TPs – Transformation Procedures) transforman un

conjunto de CDIs que pueden también incluir información nueva en forma de un UDI de
un estado válido a otro.
4.Procedimientos de verificación de integridad (IVPs – Integrity Verification Procedures)

son usados para confirmar la consistencia de datos internos de CDIs.
Considera dos tipos de reglas: reglas de certificación y normas de aplicación.

Regla 1 de Certificación (C1): Cuando cualquier IVP está en ejecución, este debe
garantizar que todos los CDIs estén en un estado válido.
Regla 2 de Certificación (C2): Para algún conjunto asociado de CDIs, un TP debe
transformarlo de un estado valido (posiblemente diferentes) a otro estado válido.
Norma 1 de Aplicación (E1): El sistema debe mantener las relaciones de certificación
(regla C2), y debe garantizar que solo los TPs certificados para ejecutar un CDI
manipulen ese CDI
Norma 2 de Aplicación (E2): El sistema debe mantener una lista de relaciones de la
forma (UID, TPi, (CDIa, CDIb, CDIc, ...)). El TP podrá accesar estos CDIs en nombre
del usuario asociado. Si el usuario no está asociado con un TP en particular y un CDI,
entonces el TP no podrá accesar al CDI en nombre del usuario.
Regla 3 de Certificación (C3): La lista de relaciones en E2 debe estar certificado para
cumplir con el requisito de separación de servicio.
Norma 3 de Aplicación (E3): El sistema debe autenticar la identidad de cada usuario

que intenta ejecutar un TP.
Regla 4 de Certificación (C4): Todos los TPs deben estar certificados para escribir y
anexar al CDI (el registro/bitácora) suficiente información para permitir que la operación
pueda ser reconstruida.
Regla 5 de Certificación (C5): Cualquier TP que toma como entrada un UDI puede
ejecutar solo transformaciones válidas, o ninguna transformación, para todos los
valores posibles del UDI. La transformación rechaza o transforma el UDI en un CDI.
Norma 4 de Aplicación (E4): Solo el agente permitido para certificar entradas puede
cambiar la lista de estas entradas asociadas: especialmente, las asociadas con un TP.
4.1. Biba vs Clark-Wilson

El modelo Biba atribuye niveles de integridad de objetos y sujetos. En el modelo Clark-
Wilson, cada objeto tiene dos niveles: restringido o alto (el CDI) y sin restricciones o
bajo (la UDI). Del mismo modo, los sujetos tienen dos niveles: certificados (TPs) y no
certificadas (todos los otros procedimientos). Modelo Clark-Wilson tiene normas de
certificación. Biba no lo hace. Clark-Wilson tiene un procedimiento para verificar las
entidades de confianza y sus acciones. Clark-Wilson requiere un certificador de entidad
de confianza para certificar el método de actualización de nivel de integridad. En forma
práctica Biba requiere pasar cada entrada de las entidades para realizar los cambios de
nivel de integridad.
5. Modelo de Muralla China

El modelo de Muralla China lleva a cabo control discrecional para aplicaciones
comerciales, con controles obligatorios exigibles. Los cuales son requeridos por
organizaciones de servicios financieros.
A diferencia de BLP el acceso a los datos no es limitado por los atributos de los datos
en cuestión, dado que BLP permite accesar (reglas obligatorias) a los sujetos a mas de
un conjunto de datos agrupados dentro de “clases de conflictos de interés”, algo que
no es restringido por las reglas mandatorias si ésta es satisfecha.
Para entender el modelo se define primero que será la muralla china y luego, mediante
la elaboración de un conjunto de reglas de modo que ninguna persona (sujeto) nunca
puede acceder a los datos (objetos) en el lado equivocado de la muralla.
Toda la información de una corporación es almacenada en un sistema de archivos

jerárquico, donde se pueden observar tres niveles:
a) Nivel bajo: Elementos individuales de información (objeto), cada uno en relación
con una sola corporación.
b) Nivel intermedio: Grupo de objetos que se refieren a la misma corporación llamados
Conjunto de datos de la empresa
c) Nivel alto: Conjuntos de datos de la empresa cuyos corporativos están en
competencia, llamados Clases de conflictos de interés.
De esta forma se tiene la tripleta (Objeto, Conjunto de datos de la empresa, Clase

de conflicto de interés), lo que sería lo mismo (Or,Yr,Xr)
x
La base de la política Muralla China es: sólo se les permite a los usuarios el acceso a
la información que no se considera conflictiva con cualquier otra información que ellos
ya poseen. La única información que ya posee un usuario debe ser información que: a)
se lleva a cabo en la computadora y, b) el usuario ha accedido previamente.
Acercándonos al formalismo: Su es el sujeto, N matriz con renglón sujeto y columna

objeto, una celda es (sujeto,objeto).
Por ejemplo: si un sujeto Su, tiene acceso a un Objeto O r entonces N(u,r) debe ser
verdadero, en otro caso falso, si Su accesa a un nuevo objeto Ot entonces N debe ser
actualizado, y N´(u,t) debe tomar el valor de verdadero.
Regla de Seguridad Simple:
El acceso sólo se concede si el objeto solicitado:

a) Está en el mismo conjunto de datos de la empresa como un objeto ya accesado por
este sujeto, i.e, dentro del muro.
b) Pertenece a una totalmente diferente clase de conflicto de interés. (A2)
La regla anterior no es completamente suficiente, dado que se necesita inicializar

correctamente a N.
Regla de Seguridad Propiedad *
El acceso de escritura sólo se permite si:

a) El acceso es permitido por la regla de seguridad simple, y
b) Ningún objeto puede ser leído en un diferente conjunto de datos de la empresa a
aquella para la cual se solicita acceso de escritura y contiene información no
esterilizada. (A6)
Dado
S el conjunto de sujetos,
O el conjunto de objetos, y
L el conjunto de etiquetas de seguridad (x, y).
Donde una etiqueta es asociada con un objeto.
X(oj) y Y(oj) son las funciones que determinan la etiqueta de seguridad

correspondiente a xj y yj respectivamente, asignada a el objeto oj.
Así que para un objeto oj , xj es su clase de conflicto de interés y yj es la empresa que

proporciona el conjunto de datos.
Axioma 1
y1= y2 ➞ x x1=x2
Si cualquiera de los objetos o1 y o2, pertenecen a la mismo grupo de datos de la

empresa, entonces también tienen la misma clase de conflicto de interés.
Corolario 1
x1< > x2 ➞ x y1 < >y2
Si cualquiera de los objetos o1 y o2 pertenecen a diferentes clase de conflictos de

interés entonces pertenecen a diferentes conjuntos de datos de la empresa.
Definición 1
Sea N una matriz booleana con elementos N(v,c) correspondientes a los
miembros de SxO, la cual toma el valor de verdadero si el sujeto Sv tiene o ha
tenido acceso al objeto Oc o el valor es falso si Sv no tiene o no ha tenido
acceso al objeto Oc. Cuando un sujeto Su realiza alguna solicitud R(u,r) para
accesar a un nuevo objeto Or y está es aceptada entonces N(u,r) debe fijarse
en verdadero para que refleje el hecho del acceso concedido.
De esta forma podemos decir, que cualquier solicitud R(u,r) causa una transición de
estado donde N es reemplazado por N´.
Axioma 2
El acceso a cualquier objeto Oc por cualquier sujeto Su, es garantizado si y sólo
si para todo N(u,c)=true.
( ( xc < > xr ) or ( yc = yr ) )
Axioma 3
N(v,c)=false, para toda (v,c) que representa un estado inicial seguro.
Axioma 4
Si N(u,c) es en todas partes false para algún Su entonces cualquier solicitud
R(u,r) es concedida.
Teorema 1
Una vez que un sujeto a tenido acceso a un objeto, los únicos objetos
accesibles por él se encuentran en el mismo conjunto de datos de la empresa o
dentro de una clase de conflicto de interés diferente.
Teorema 2
Un sujeto puede a lo más tener acceso a un conjunto de datos de empresa en
cada clase de conflicto interés.
Teorema 3
Si por alguna clase de conflicto de interés X existe un conjunto de datos de la
empresa Xy entonces el número mínimo de sujetos que permitirá accesar a
cada objeto es Xy.
Definición 2
Para cualquier objeto Os,
ys = yo implica que Os contiene información esterilizada
ys < > yo implica que Os contiene información no esterilizada.
Axioma 5
yo ↔ xo
Si un objeto tiene la etiqueta de seguridad y o entonces también debe llevar la
etiqueta xo y viceversa. T2 indica que todos los sujetos pueden accesar al
conjunto de datos de la empresa.
x
Axioma 6
El acceso de escritura a cualquier objeto Ob, por cualquier sujeto Su es
permitido si y sólo si N´(u,b)=true y no existe ningún objeto Oa
(N´(u,a=true)) cual puede ser leído por Su para los que:
ya < > yb and ya < > yo
Teorema 4
El flujo de información no esterilizada se limita a su propia conjunto de datos de
la empresa; sin embargo, la información esterilizada puede fluir libremente por
todo el sistema.
5.1. Modelo de Muralla China extendido a Clark-Wilson

Sea P el conjunto de procesos que son usados para accesar a los objetos que
menciona el modelo Muralla China. Sea A la relación SxP que representa la relación
entre usuario y la ejecución del proceso. Por lo que se tiene el siguiente axioma.
Axioma 7
Un usuario Su, puede ejecutar un proceso pf si y sólo si (u,f) es un miembro de
A.
Aumentamos L para incluir un tercer atributo, z, i.e., L={x,y,z}, donde z es un miembro

del conjunto de Z. Z(Oj) es la función que determina etiqueta de seguridad z-
componente asignada a un objeto Oj e introducimos PZ para representar el conjunto
potencia de Z. Asociamos entonces con cada uno de los procesos, pf, un miembro de
PZ, determinado como pzf. Afirmamos que los procesos pueden accesar solo a los
objetos cuyos z-atributo es incluido en el proceso. Es decir,
Axioma 8
Un proceso pf puede solo accesar a un objeto Or si
Zf es un subconjunto de pzf
Las reglas de acceso son hasta ahora gobernadas por A2-A4 y A6-A8. En particular un
estado inicialmente seguro existe cuando ningún usuario haya accesado cualquier
objeto (A3) y la primera vez de su acceso de cualquier usuario a cualquier objeto es
totalmente sin restricciones (A4). Los usuarios pueden, sin embargo, accesar a aquel
sujeto (Su and Or respectivamente) vía algún proceso pf donde (u,f) está en A para
cuyo zr es subconjunto de pzf (A7-A8).
Los usuarios pueden entonces accesar a algún otro objeto Or vía pf si y sólo si ∀
N(u,c)=true:
((u,f) ∊ A) and (z A) and (zr ⊆ pzf) and ((xc < > xr or yc = yr )) A2, A7, A8
y finalmente, los usuarios pueden solo escribir información en un objeto Ob siempre

que este acceso no está prohibido por cualquiera de las reglas anteriores y que no
existe ningún objeto Oa que puede ser leído, para los cuales
ya < > yb and ya < > yo A6

6. Modelo de Goguen-Meseguer
El modelo tiene las siguientes propiedades:
• Introduce una teoría de autómatas simple y general para modelar sistemas se-
guros.
• Muestra el uso de las capacidades abstractas para modelar los aspectos dinámi-
cos de seguridad de los sistemas.
• El enfoque no solo se aplica a sistemas operativos, sino a sistemas de mensajes
y a sistemas de bases de datos.
• Introduce un concepto general de políticas de seguridad, tal que permite a las
políticas incluir seguridad multinivel (MLS), paso de capacidades, confinamiento,
acceso discrecional, acceso multiusuario/multillave, distribución automática, ca-
nales autorizados y degradación.
• Proporciona un formalismo para la especificación de políticas seguras.
• Proporciona técnicas para probar que un determinado sistema satisface una de-
terminada política.
Introduce el concepto de no interferencia entre usuarios. Evita que un usuario de nivel

alto interfiera con un usuario de nivel bajo. Simplemente formula, un sujeto, usuario, o
grupo de usuarios no interfiere a otro sujeto, usuario, o grupo de usuarios sin que lo que
haga el primero no afecte en algo al segundo. Los elementos de este modelo son:
• El conjunto de todos los posibles estados del sistema.
• El conjunto de usuarios.
• El conjunto de comandos que pueden ejecutar los usuarios.
• El conjunto de salidas.
• El próximo estado.
• El conjunto de niveles de seguridad.
Definiciones básicas:
1. Un grupo de usuarios, usando un cierto conjunto de comandos, no interfiere con
otro grupo de usuarios si lo que hace el primero grupo con estos comandos no
afectan a lo que el segundo grupo de usuarios puede ver.
2. Dado un estado seguro inicial, el sistema es seguro en multinivel si el primer
usuario no es interferido por el segundo usuario, a menos que el nivel del prime-
ro sea menos que o igual que el segundo usuario.
La implementación del modelo Goguen-Meseguer esta enfocado en la idea de la sepa-

ración de los usuarios basándose en sus dominios de protección para evitar interferen-
cia entre los grupos.
Definición 1
Una máquina de estado M consiste de lo siguiente:
• un conjunto U cuyos elementos llamados “usuarios” -sujetos
• un conjunto S cuyos elementos llamados “estados”
• un conjunto C cuyos elementos llamados “comandos de estado”
• un conjunto Out cuyos elementos llamados “salidas”
• junto con
◦ Una función de Salida out: SxU --> Out
x
◦ Una función Estado de Transición do: SxUxC --> S

◦ Una constante s0, estado inicial de la máquina
Nota 1:Lo anterior es para Sistemas Estáticos
Nota 2: UxC es el conjunto de entradas
Definición 2
Un Sistema de Capacidades M consiste de:
• Un conjunto U cuyos elementos son llamados “usuarios”
• Un conjunto S cuyos elementos son llamados “estados”
• Un conjunto SC cuyos elementos son llamados “comandos de estados”
• Un conjunto Out cuyos elementos son llamados “salidas”
• Un conjunto Capt cuyos elementos son llamados “tablas de capacidades”
• Un conjunto CC cuyos elementos son llamados “comandos de capacidades”
junto con:
◦ Una función out: S x Capt x U --> Out (función de salida)
◦ Una función do: S x Capt x U x SC --> S (función de estado de
transición)
◦ Una función cdo: Capt x U x CC --> Capt (función de capacidades de
transición)
◦ Las constantes t0∊ A) and (zCapt y s0∊ A) and (zS que son tabla de capacidad inicial y
estado de la máquina inicial, respectivamente.
Nota3ρ)-min: C = CC ∪ SC SC
Nota4: La definición 2 es aplicada para sistema de capacidades. Sistemas dinámicos.
Dado un sistema de capacidad de M, podemos definir una función de transición del

sistema que describe el efecto de los comandos en el espacio de estados del sistema
combinado, cual es S x Capt. Esta función
csdo: S x Capt x U x C --> S x Capt
Esta definida, para s∊ A) and (zS, t∊ A) and (zCapt, u∊ A) and (zU por
csdo (s,t,u,c) = (do(s,t,u,c), t) si c∊ A) and (zSC

y
csdo(s,t,u,c)=(s,cdo(t,u,c)) si c∊ A) and (zCC
Podemos por lo tanto extender la función de transición del sistema en el camino clásico
para cadenas de entrada, definiendo:
csdo: S x Capt x (UxC)* --> S x Capt
con las ecuaciones: csdo (s,t,NIL) = (s,t)
y csdo (s,t,w.(u,c)) = csdo (csdo(s,t,w),u,c)
Para s∊ A) and (zS, t∊ A) and (zCapt, u∊ A) and (zU, c∊ A) and (zC y w∊ A) and (z(UxC)*, donde NIL denota la cadena vacía y el
“punto” denota la concatenación de las cadenas.
Podemos usar la notación
[ [w] ] = csdo (t0, c0, w)
por la denotación o efecto de la cadena de entrada w en el estado, empezando desde

el estado inicial de todo el sistema.
Concepto (Teoría de autómata): Un estado s de una maquina de estados M es

alcanzable si y sólo si existe algún w en C* tal que [[w]] = s.
Políticas Estáticas
Notaciones:
Dado una máquina de estados M, w∊ A) and (z(UxC)*, y u∊ A) and (zU. Definimos [[ w ]]u como “la salida
de u después de hacer w sobre M”, es decir,
[[w]] u = out ([[w]],u)
Esta denotación es desde el punto de vista del usuario.
Tenga en cuenta que M puede tener una estructura adicional como un sistema de
capacidad. En ese caso, el espacio de estados tiene la forma SxCapt, el conjunto C de
los comandos es una unión disjunta CC U SC de estados y los comandos que cambian
la tabla de capacidad, y la función de transición de estado es csdo.
Definición 3
Dado G⊆ U un “grupo” de usuarios, A⊆ C una capacidad, y w∊ A) and (z(UxC)*. Entonces
decimos que PG(w) denota la subsecuencia de w obtenida por la eliminación de
aquellos pares (u,c) con u en G. Similarmente, decimos que PA(w) denota la
subsecuencia de w obtenida eliminando aquellos pares (u,c) con c en A.
Combinando estos dos, decimos que PG, A(w) denota la subsecuencia de w
obtenida eliminando los pares (u,c) con u en G y c en A.
Por ejemplo:
Si G ={ u , v } y A = { c1 , c2 }, entonces
PG,A ((u’,cl)(u,c3)(u,c2)(v’,c1)) =
(u’,c1)(u,c3)(v’,c1,)
donde u’,v’son otros usuarios, y c3 es otro comando.
Definición 4
Dada una máquina de estados M y los conjuntos de usuarios G y G´, decimos
que G no hace interferencia con (o no interfiere con) G´, escribiendo G :| G´, si y
sólo si ∀w∊ A) and (z(UxC)* y u∊ A) and (zG,
[[w]] u = [ [PG(w) ]] u
Similarmente, dada una capacidad A y un grupo de usuarios G, decimos que A no

interfiere con los usuarios en G, escribiendo A :| G, si y sólo si ∀w∊ A) and (z(UxC)* y u∊ A) and (zG,
[[w]] u = [ [PA(w) ]] u
En general, los usuarios en G con capacidad A no interfieren con los usuarios en G´,
escribiendo A,G :| G´ si y sólo si ∀w∊ A) and (z(UxC)* y u∊ A) and (zG,
[[w]] u = [ [PG,A(w) ]] u
Definición 5
Una política de seguridad es un conjunto de afirmaciones de no interferencia.
x
Definición 6
Dado los conjunto de usuarios G y G`, A el conjunto de comandos, y P un
predicado definido sobre (Ux C)*. Entonces G usando A no interfiere con G` bajo
la condición de P, escrito
G,A:| G` si P
si y sólo si ∀ u`∊ A) and (z G`, ∀w∊ A) and (z(UxC)*
[[w]] u` = [ [P(w) ]] u`
donde P es definido por P(λ)= λ)= λ)= λ
donde λ)= λ es la cadena vacía, y P(o1...on)=o`1...o`n
donde oí= λ)= λ si P(o´1...oí-1) y oí=(u,a)
con u∊ A) and (zG y a ∊ A) and (zA y oí= oi
Referencias
[1] Elliott Bell, Leonard J. LaPadula. “Secure Computer Systems: Mathematical
Foundations”. National Technical Information Service. Report ESD-TR-73-278. Vol. 1.
1973.
[2] K. J. Biba. “Integrity Considerations for Secure Computer Systems”. MITRE
Technical Report. MTR-3153. 1975.
[3] David D. Clark, David R. Wilson. “A Comparison of Commercial and Militar
Computer Security Policies”. IEEE. pp. 184-194. 1987.
[4] Goguen and Meseguer. “Security Policies and Security Models”. IEEE. pp. 11-20.
1982.
[5] David F.C. Brewer and Michael J. Nash. “The Chinese Wall Security Policy”. IEEE.
pp. 206-214. 1989.
[6] TrustedBSD. http://www.trustedbsd.org/

Un Vistazo A Los Sistemas Distribuidos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Un Vistazo A Los Sistemas Distribuidos

Cargado por

Copyright:

Formatos disponibles

SISTEMAS DISTRIBUIDOS

Teoría Fundamental para Sistemas Distribuidos

BORRADOR VERSIÓN 0.6 MAYO 2022.

Universidad Tecnológica de la Mixteca

...después del café.

Universidad Tecnológica de la Mixteca

2. Sincronización lógica de Lamport.................................................17

3. Sincronización de tiempos propuesto por Gusella y Zatti.............19

4. Probabilidad de sincronización propuesta de Flaviu Cristian........23

III. Exclusión mutua..............................................................................27

2. Algoritmo basado en permiso propuesto por Lamport.................28

3. Algoritmo basado en permiso propuesto Ricart y Agrawala.........29

4. Algoritmos basados en tokens – clasificación de Michel Raynal...31

2. Elección en un sistema distribuido propuesta de García-Molina...34

3. Algoritmos de elección en un anillo – Le Lann, Chang&Roberts, y

2. Modelo del sistema.......................................................................45

4. Estrategias de tratamiento de un deadlock..................................46

6. Algoritmo centralizado para la detección de bloqueos.................49

VI. Tolerancia a fallos...........................................................................56

1. Introducción al problema de tolerancia de fallos..........................56

2. Problema de los Generales Bizantinos..........................................57

VII. Control de acceso...........................................................................65

VIII. Modelos de seguridad...................................................................72

5. Modelo de Muralla China..............................................................92

Figura 1.1. Diagrama de transición de estados.

Figura 1.2. Diagrama de colas.

Figura 1.3. Diagrama de estado para un sistema operativo sencillo.

Cuando se añade un proceso a la lista administrada por el sistema operativo, se deben

Existen cuatro sucesos comunes que llevan a la creación de un proceso:

• cuando el SO lo crea para brindar un servicio.

1.1. Sistema de llamada fork

La creación de dos procesos totalmente idénticos que ejecuten el mismo código no es

1.2. Identificadores de procesos

El identificador del proceso se recupera por medio de la instrucción getpid(), y el

El tipo de dato pid_t representa el ID del proceso, y es un número de tipo entero. De

1.3. Sistema de llamada wait ()

pid_t wait (int *stat_loc);

stat_loc es un apuntador a una variable entera.

Después del llamado a wait, el estado de la información almacenada en la localidad

WIFEXITED (*stat_loc). Si en la evaluación el valor no es cero (true) indica que el

El hijo regresa su estado llamando a exit, _exit o return.

En options se coloca una combinación de las siguientes banderas: WEXITED que

1.4. Sistema de llamada exit

Tabla 1.1. Terminación de proceso.

Terminación normal El proceso ejecuta una llamada a un servicio del SO

Tiempo límite excedido El proceso se ha ejecutado sobre pasando el límite

No hay memoria disponible El proceso necesita más memoria de la que el

Violación de límites El proceso trata de acceder a una posición de

Error de protección El proceso intenta utilizar un recurso o un archivo que

Error aritmético El proceso intenta hacer un cálculo prohibido, o trata

Fallo de E/S Se produce un error en la entrada o la salida, tal

Instrucción privilegiada El proceso intenta usar una instrucción reservada

Intervención del operador o Por alguna razón el operador o el sistema operativo

Terminación del padre Cuando un proceso padre finaliza. El SO puede

Solicitud del padre Un proceso padre tiene normalmente la autorización

Como se ha visto el proceso debe terminar de alguna manera, es decir, de forma

void exit (int status)

El llamado a exit termina la ejecución del proceso y devuelve el valor de estatus al

1.5. Sistema de llamada exec

Las sintaxis de ellos se muestra a continuación:

int execv (const char *path, const char *argv[]);

Tabla 1.2. Lista de llamados en POSIX 1.c.

int execv (const char path, const char argv[]);

int pthread_create (pthread_t thread, const pthread_attr_t attr,