Universidad de Panamá

Facultad de Informática, Electrónica y Comunicación

Centro Regional Universitario de Veraguas
Escuela de Ingeniera
Licenciatura en Ingeniería en Informática

ASIGNATURA: SISTEMAS OPERATIVOS II

CAPÍTULO 14: PROTECCIÓN

PROFESOR RESPONSABLE: RAÚL ENRIQUE DUTARIDUTARI

ESTUDIANTE:

DAVID QIU HAU C.I.P: 8-843-341

II SEMESTRE 2012

CIUDAD DE SANTIAGO, DICIEMBRE DE 2012

 TABLA DE CONTENIDO
Contenido Páginas

1. Introducción ...................................................................................................... 1

2. Objetivos de la protección................................................................................. 1

3. Principios de la protección ................................................................................ 2

4. Dominio de Protección ...................................................................................... 3

4.1. Estructura de dominio ................................................................................ 3

5. Matriz de acceso ............................................................................................... 4

6. Implementación de la matriz de acceso ............................................................ 5

6.1. Tabla global................................................................................................ 5

6.2. Listas de acceso para los objetos .............................................................. 5

6.3. Listas de capacidades para los dominios ................................................... 6

6.4. Un mecanismo de bloque-clave ................................................................. 6

7. Control de Acceso ............................................................................................ 6

7.1. Revocación de derecho de Acceso ............................................................ 7

8. Sistemas Basados en Capacidades ................................................................. 8

9. Protección basada en el Lenguaje .................................................................... 8

9.1. Imposición de reglas basadas en compilador ............................................ 8

9.2. Protección en Java ..................................................................................... 9

10. Conclusiones ................................................................................................. 9

11. Referencias bibliográficas ........................................................................... 10

 1

1. Introducción

Los procesos en un sistema operativo deben protegerse de las actividades

realizadas por otros procesos.

Para proporcionar dicha protección, podemos utilizar diversos mecanismos para

garantizar que sólo los procesos que hayan obtenido la adecuada autorización del
sistema operativo puedan operar sobre los archivos, los segmentos de memoria,
sobre la CPU y sobre otros recursos del sistema.

El concepto de protección hace referencia a un mecanismo para controlar el

acceso de los programas, de los procesos o de los usuarios a los recursos
definidos por el sistema informático.

Este mecanismo debe proporcionar un medio de especificar los controles que hay
que imponer, junto con un modo de imponerlos.

2. Objetivos de la protección

La protección se concebía originalmente como algo asociado a los sistemas

operativos multi-programados, de modo que los usuarios que no fueran de
confianza pudieran compartir de manera segura un espacio lógico de nombres
común.

Los conceptos modernos de protección han evolucionado para incrementar la

fiabilidad de cualquier sistema complejo que haga uso de recursos compartidos.

Necesitamos proporcionar protección por diversas razones. La más obvia es la

necesidad de impedir una violación maliciosa e intencionada de una restricción de
acceso por parte de un usuario.

La detección temprana de errores de interfaz puede a menudo impedir que un

subsistema correcto se vea contaminado por otro que no esté funcionando
adecuadamente.
 2

El papel de la protección en un sistema informático es proporcionar un mecanismo

para la imposición de las políticas que gobiernen el uso de recursos.

El programador de aplicaciones necesita utilizar también los mecanismos de

protección, para defender de un uso incorrecto los recursos creados y soportados
por un subsistema de aplicación.

3. Principios de la protección

Uno de los principios directores clave y que ha resistido al paso del tiempo a la
hora de proporcionar protección es el principio del mínimo privilegio.

Este principio dicta que a los programas, a los usuarios, incluso a los sistemas se
les concedan únicamente los suficientes privilegios para llevar a cabo sus tareas.

Considere la analogía de un guardia de seguridad que dispusiera de una tarjeta

magnética. Si esta tarjeta le permite entrar simplemente en las áreas públicas que
está vigilando, un mal uso esa tarjeta provocará un daño mínimo.

Un sistema operativo que se ajuste al principio del mínimo privilegio implementará

sus características, programas, llamadas al sistema y estructuras de datos de
modo que el fallo o el premiso de un componente provoquen un daño mínimo y no
permitan realizar más que un daño mínimo.

La gestión de los usuarios con el principio del mínimo privilegio implica crear una
cuenta separada para cada usuario, con sólo los privilegios que ese usuario
necesite.

Un operador que necesite montar cintas y realizar copias de seguridad de archivos

del sistema tendrá sólo acceso a esos comandos y archivos que necesita para
llevar a cabo su tarea.

Las computadoras implementadas dentro de una instalación que se ajuste al

principio del mínimo privilegio pueden limitarse a ejecutar servicios específicos, a
acceder a máquinas host remotas a través de servicios específicos y a hacer esto
sólo durante períodos específicos.
 3

El principio de mínimo privilegio puede ayudar a obtener un entorno informático

más seguro.

4. Dominio de Protección

Un sistema informático es una colección de procesos y objetos. Por objetos

queremos definir tanto objeto hardware y objeto software.

Las operaciones posibles pueden depender de cada objeto.

4.1. Estructura de dominio

Para facilitar este esquema, un proceso opera dentro de un dominio de protección,
que especifica los recursos a los que el proceso puede acceder.

Cada dominio define un conjunto de objetos y los tipos de operaciones que

pueden invocarse sobre cada objeto.

La capacidad de ejecutar una operación sobre un objeto es un derecho de acceso.

Un dominio es una colección de derechos de acceso, cada uno de los cuales es

una pareja ordenada <nombre-objeto, conjunto-derechos>.

Los dominios no tienen por qué ser disjuntos, sino que pueden compartir derechos
de acceso.

La asociación entre un proceso y un dominio puede ser estática, si el conjunto de

recursos disponibles para el proceso está fijo durante la vida del proceso, o
dinámica.

Si la asociación entre los procesos y los dominios es fija y queremos adherimos al

principio de la necesidad de conocer, deberá haber disponible un mecanismo para
cambiar el contenido de un dominio.

Un dominio puede llevarse a la práctica de diversas formas:

 Cada usuario puede ser un dominio.

 Cada proceso puede ser un dominio.
 4

 Cada procedimiento puede ser un dominio.

5. Matriz de acceso

Nuestro modelo de protección puede contemplarse de forma abstracta como una

matriz, denominada matriz de acceso.

Las filas de la matriz de acceso representan dominios y las columnas representan

objetos. Cada entrada de la matriz está compuesta de un conjunto de derechos de
acceso.

La entrada access(i,j) define el conjunto de operaciones que un proceso que se

ejecute en el dominio D¡ puede invocar sobre el objeto Oj.

La matriz de acceso puede implementar decisiones de política relativas a la

protección. Las decisiones de política implican qué derechos deben incluirse en la
entrada (i,J).

Los usuarios normalmente deciden el contenido de las entradas de la matriz de

acceso. Cuando un usuario crea un nuevo objeto O¡, se añade la columna O¡ a la
matriz de acceso, con las apropiadas entradas de inicialización, según determine
el creador.

La matriz de acceso proporciona el mecanismo apropiado para definir e

implementar un trol estricto de la asociación tanto estática corno dinámica entre
procesos y dominios.

Los procesos deben poder conmutar de un dominio a otro. La conmutación del

dominio Di al domino Di estará permitida si y sólo si el derecho de acceso switch ε
access(i,j).

Un sistema puede seleccionar sólo uno de estos tres derechos de copia, o puede
proporcionar los tres identificándolos como derechos distintos: copia, transferencia
y copia limitada.
 5

También necesitamos un mecanismo para permitir la adición de nuevos derechos

y la eliminación de algunos derechos. El derecho owner controla estas
operaciones.

Los derechos de copia y el derecho de propietario permiten a un proceso modificar

las entradas de una columna. También hace falta un mecanismo para modificar
las entradas de una fila derecho control sólo es aplicable a los objetos dominio.

Los derechos de copia y el derecho de propietario proporcionan un mecanismo

para limitar la propagación de derechos de acceso.

6. Implementación de la matriz de acceso

En general, la matriz será alguna vez dispersa, es decir, la mayoría de las

entradas estarán vacías.

Aunque existen técnicas de representación de estructuras de datos para

representar matrices dispersas, no resultan particularmente útiles para esta
aplicación, debido a la forma en que se utiliza la funcionalidad de protección.

6.1. Tabla global

La implementación más simple de la matriz de acceso es una tabla global
compuesta de un conjunto de tripletas ordenadas <dominio, objeto, conjunto-
derechos>.

Esta implementación tiene varias desventajas. La tabla es usualmente muy grande

y no puede, por tanto, ser conservada en memoria principal, por lo que hacen falta
operaciones adicionales de E/S. A menudo se utilizan técnicas de memoria virtual
para gestionar esta tabla.

6.2. Listas de acceso para los objetos

Cada columna de la matriz de acceso puede implementarse como una lista de
acceso de un objeto.
 6

La lista resultante para cada objeto estará compuesta por una serie de parejas
ordenadas <dominio, conjunto-derechos>, que definen todos los dominios que
tengan un conjunto de derechos de acceso no vacío para dicho objeto.

Esta técnica puede extenderse fácilmente para definir una lista más un conjunto
predeterminado de derechos de acceso.

6.3. Listas de capacidades para los dominios

Una lista de capacidades para un dominio es una lista de objetos junto con las
operaciones permitidas sobre esos objetos. Cada objeto.se suele representar
mediante su dirección o nombre físico, denominada capacidad.

6.4. Un mecanismo de bloque-clave

El esquema de bloqueo-clave es un compromiso entre las listas de acceso y las
listas de capacidades. Cada objeto tiene una lista de patrones de bit distintivos,
denominados bloqueos.

Al igual que con las listas de capacidades, la lista de claves de un dominio debe
ser gestionada por el sistema operativo por cuenta del dominio. Los usuarios no
están autorizados a examinar o modificar la lista de claves (o de bloqueos)
directamente.

7. Control de Acceso

El control de acceso basado en roles (RBAC, role-based access control), esta

funcionalidad gira en tomo a los privilegios.

Un privilegio es el derecho a ejecutar una llamada al sistema o a usar una opción

dentro de dicha llamada al sistema (como por ejemplo, abrir un archivo con acceso
de escritura).

Los privilegios y programas también pueden asignarse a roles. A los usuarios se

les asignan roles (o los usuarios adoptan roles) basándose en contraseñas
asignadas a los roles.
 7

De esta forma, un usuario puede adoptar un rol que activa un privilegio,

permitiendo al usuario ejecutar un programa para llevar a cabo una tarea
específica.

7.1. Revocación de derecho de Acceso

En un sistema de protección dinámico, puede que necesitemos en ocasiones
revocar derechos de acceso a objetos compartidos por diferentes usuarios.

En este punto pueden surgir diversas cuestiones acerca de la revocación:

1. Inmediata o diferida. ¿La revocación tiene lugar inmediatamente o se

produce de forma diferida? Si se difiere la revocación, ¿podemos averiguar
cuándo tendrá lugar?
2. Selectiva o general. Cuando se revoca un derecho de acceso a un objeto,
¿afecta a todos los usuarios que tienen derecho de acceso a ese objeto o
podemos especificar un grupo seleccionado de usuarios cuyos derechos de
acceso deben revocarse?
3. Parcial o total. ¿Podemos revocar un subconjunto de los derechos
asociados con un objeto o debemos revocar todos los derechos de acceso
al objeto?
4. Temporal o permanente. ¿Podemos revocar el acceso permanentemente
(es decir, el derecho de acceso revocado nunca volverá a estar disponible),
o podemos revocar el acceso y luego obtenerlo de nuevo?

Entre los esquemas que pueden utilizarse para implementar la revocación en un

sistema basado en capacidades podemos citar:

 Re adquisición. Periódicamente, se borran las capacidades de cada

dominio.
 Retropunteros. Con cada objeto se mantiene una lista de punteros, que
hace referencia a todas las capacidades asociadas con ese objeto.
 Indirección. Las capacidades apuntan indirectamente, en lugar de
directamente, a los objetos.
 8

 Claves. Una clave es un patrón distintivo de bits que puede asociarse con
una capacidad.

8. Sistemas Basados en Capacidades

Estos sistemas varían tanto en lo que se refiere a su complejidad como en el tipo

de políticas que pueden implementarse sobre ellos. En ninguno de los dos
sistemas se utiliza ampliamente, pero constituyen casos de prueba interesantes
para verificar los análisis teóricos relativos a los mecanismos de protección.

Entre los sistemas que podemos citar se encuentran:

1. Hydra. Es un sistema de protección basado en capacidades que

proporciona una considerable flexibilidad.
2. Sistema CAP de Cambrigde. En el sistema CAP de Cambridge se ha
adoptado un enfoque distinto para la implementación del mecanismo de
protección basado en capacidades.

9. Protección basada en el Lenguaje

El grado de protección que se proporciona en los sistemas informáticos existentes

suele conseguirse mediante un kernel del sistema operativo.

Los diseñadores de sistemas de protección, han aprovechado al máximo una serie

de ideas que tienen su origen en los enlaces de programación y especialmente en
los conceptos de tipos abstractos de datos y objetos.

9.1. Imposición de reglas basadas en compilador

Esta técnica tiene varias ventajas significativas:

1. Las necesidades de protección simplemente se declaran, en lugar de

programarlas como una secuencia de llamadas a procedimientos de un
sistema operativo.
2. Los requisitos de protección pueden enunciarse independientemente de la
funcionalidad proporcionada por un sistema operativo concreto.
 9

3. El diseñador de un subsistema no tiene por qué proporcionar los medios

para imponer el mecanismo de protección.
4. La notación declarativa resulta bastante natural, porque los privilegios de
acceso están estrechamente relacionados con el concepto lingüístico de
tipo de datos.

9.2. Protección en Java

Como Java fue diseñado para ejecutarse en un entorno distribuido, la máquina
virtual de Java (o JVM) tiene muchos mecanismos de protección integrados.

Los programas Java están compuestos por clases, cada una de las cuales es una
colección de campos de datos y funciones (denominadas métodos) que operan
sobre esos campos.

Debido a estas capacidades de Java, la protección es una de las principales

preocupaciones. Las clases que se ejecutan en una misma JVM pueden tener
diferentes orígenes y pueden no gozar de un grado igual de confianza.

Como resultado, resulta insuficiente garantizar la protección con la granularidad de

los procesos JVM.

Por tanto, dichas decisiones dé protección se gestionan dentro de la JVM. Cuando

la JVM carga una clase, la asigna a un dominio de protección que proporciona los
permisos correspondientes a esa clase.

Puede ser complicado para la JVM determinar qué clase es responsable de una
solicitud de acceso a un recurso protegido. Los accesos se realizan a menudo
indirectamente, mediante bibliotecas del sistema u otras clases.

10. Conclusiones

Los sistemas informáticos contienen muchos objetos y estos objetos necesitan

protegerse frente a posibles malos usos.

Los objetos pueden ser hardware (como la memoria, el tiempo de CPU y los
dispositivos de E/5) o software (como los archivos, programas y semáforos).
 10

Un dominio es un conjunto de derechos de acceso. Los procesos se ejecutan en

dominios y pueden usar cualquiera de los derechos de acceso del dominio para
acceder a los objetos y manipularlos.

Durante su ciclo de vida, un proceso puede estar limitado a un dominio de

protección o se le puede permitir que conmute de un dominio de protección a otro.

La matriz de acceso es un modelo general de protección que proporciona un

mecanismo que no impone ninguna política concreta de protección al sistema ni a
sus usuarios. La separación entre política y mecanismo es una importante
propiedad de diseño.

Los sistemas reales están mucho más limitados que el modelo general y tienden a
proporcionar protección exclusivamente para los archivos.

La protección basada en lenguaje proporciona una capacidad de arbitraje de

solicitudes y privilegios con una granularidad más fina de la que el sistema
operativo es capaz de proporcionar.

11. Referencias bibliográficas

[SGGZ06] SILBERSHATZ, Abraham; GALVIN, Peter Baer; GAGNE, Greg.

Fundamentos De Sistemas Operativos. McGraw-Hill, 2006.