internet futuro

Artículo
Un modelo de control de acceso para prevenir el
ataque de salto de máquina virtual
Ying Dong * y Zhou Lei
Escuela de Ingeniería Informática y Ciencia, Universidad de Shanghai, Shanghai 200444, China;
leiz@shu.edu.cn
* * Correspondencia: Cyvil@shu.edu.cn ; Tel .: + 86-1316-711-5161
comprobar
Recibido: 27 de febrero de 2019; Aceptado: 23 de marzo de 2019; Publicado: 26 Eor
de marzo de 2019 actualizaci
ones

Resumen: Como un nuevo tipo de modelo de computación de servicios, la computación en la nube

proporciona varios servicios a través de Internet. El salto de máquina virtual (VM) es un problema
de seguridad que a menudo se encuentra en la capa de virtualización. Una vez que ocurre, afecta
directamente la confiabilidad de toda la plataforma informática. Por lo tanto, hemos estudiado a
fondo el ataque de salto de máquina virtual. Además, diseñamos el modelo de control de acceso
PVMH (Prevención de salto de VM) para evitar ataques de salto de VM basados en el modelo BLP
y el modelo Biba. Finalmente, implementamos el modelo en la plataforma Xen. Los experimentos
demuestran que nuestro módulo PVMH logra prevenir el ataque de salto de VM con una pérdida
aceptable en el rendimiento de la máquina virtual.

Palabras clave: seguridad en la nube; salto de máquina virtual; Modelo BLP; Modelo Biba; Modelo
PVMH

1. Introducción
La computación en la nube es un modelo de computación de red emergente basado en Internet.
Es otro nuevo concepto de computación después de la computación paralela, la computación en
cuadrícula y la informática de servicios públicos [1] Es considerado como otra revolución en el
campo de la informática. Con el desarrollo gradual y las ventajas de la computación en la nube, los
gobiernos, las empresas y las instituciones de investigación científica han valorado enormemente las
principales tecnologías y aplicaciones de la computación en la nube. Muchas empresas de TI como
Google [2], Amazon [3], Azure y Alibaba han tomado la computación en la nube como una dirección
importante para la innovación tecnológica futura y han invertido mucho en investigación y
desarrollo. Muchos países incluso consideran la computación en la nube como una oportunidad
importante para desarrollar y actualizar la industria de la información y promover el desarrollo de
la sociedad de la información. En el informe de investigación del estado de RightScale 2018, el 96%
de los profesionales de TI encuestados dijeron que su compañía estaba adoptando servicios de
computación en la nube, y el 92% dijeron que usaban nubes públicas. A medida que las empresas
mueven más aplicaciones a la nube, el mercado de computación en la nube está en auge. Según la
firma de investigación Gartner, el valor del mercado de la nube pública alcanzará los 186.400
millones de dólares en 2018, un aumento del 21,4% respecto al año pasado.
El ataque de salto de máquina virtual (VM) [4 4,5 5] estudiado en este documento implica
principalmente la seguridad entre diferentes máquinas virtuales en el mismo host y la seguridad
entre la máquina virtual y el host. En una plataforma en la nube, varias máquinas virtuales se
distribuyen juntas en la misma máquina física. Si una máquina virtual se ve comprometida o un
intruso ilegal obtiene la máxima autoridad de una máquina virtual por algún medio, existe un
riesgo de seguridad de que un usuario ilegal use la máquina virtual como trampolín para atacar
otras máquinas virtuales e incluso atacar al administrador de la máquina virtual para obtener
ilegalmente archivos de datos en la máquina virtual. Existen diversas vulnerabilidades en diferentes
plataformas de virtualización. Un funcionario de Xen anunció una importante vulnerabilidad de
seguridad, con el nombre en código "Dome Breaking" (XSA-148 / CVE-2015-7835).
Internet futuro 201911, 82; doi:10.3390 / fi11030082 www.mdpi.com/journal/futureinternet
Internet futuro 201911, 82 2 de 21

ataques de salto y ataques de escape de máquinas virtuales. Jason Geffner de CrowdStrike encontró
una vulnerabilidad de seguridad relacionada con el controlador de disquete virtual en el emulador
de computadora de código abierto QEMU, con nombre en código "VENOM" (CVE-2015-3456).
Existía en muchas plataformas de virtualización de computadoras (especialmente Xen, KVM,
VirtualBox y el cliente nativo QEMU). Esta vulnerabilidad podría permitir a un atacante deshacerse
de las restricciones de identidad de invitado de una máquina virtual infectada y probablemente
obtener derechos de ejecución de código del host. Además, un atacante puede usarlo para acceder al
sistema host y a todas las máquinas virtuales que se ejecutan en el host, y puede elevar los permisos
de acceso para que los atacantes puedan acceder a la red local del host y a los sistemas vecinos. Otra
vulnerabilidad (CVE-2018-10853) indicó que KVM
4.10 y versiones posteriores en el kernel de Linux tienen fallas de seguridad en la implementación
debido a la falla al detectar el CPL (el nivel de privilegio de la tarea o programa actualmente en
ejecución). Un atacante podría aprovechar esta vulnerabilidad para elevar los privilegios y causar
ataques de salto de máquina virtual. Dado que el ataque de salto de máquina virtual es un riesgo de
seguridad de la capa de virtualización, los riesgos de seguridad en la capa de virtualización pueden
causar el colapso del sistema de seguridad de toda la plataforma de computación en la nube. Por lo
tanto, si se produce un ataque de salto de máquina virtual en la plataforma de la nube, se produce
un daño enorme en toda la plataforma de la nube.
En resumen, la investigación sobre cómo mejorar la seguridad de la plataforma de
computación en la nube y prevenir ataques maliciosos en el entorno de computación en la nube
tiene un significado teórico y práctico para promover el desarrollo saludable de las plataformas de
computación en la nube y sus aplicaciones. El ataque de salto de VM es un método de ataque muy
dañino. Los investigadores deben prestar suficiente atención a la prevención de ataques de salto de
VM para hacer que la plataforma en la nube sea más estable y confiable.
En este artículo, estudiamos el contenido relacionado de los ataques de salto de máquinas
virtuales. De acuerdo con el modelo BLP y el modelo Biba, el modelo de prevención de salto de VM
(PVMH) se propone combinando la integridad y confidencialidad de la seguridad informática, y se
esfuerza por evitar ataques de salto de máquina virtual.
El resto de este documento está organizado de la siguiente manera: Sección 2 describe varios
estudios que están estrechamente relacionados con nuestra investigación; Sección3 introduce
algunos conocimientos básicos, incluidos ataques de salto de máquinas virtuales y técnicas de
control de acceso; Sección4 4 detalla el diseño e implementación de nuestro modelo PVMH
propuesto; por varios experimentos en la sección5 5, demostramos la efectividad de nuestro modelo
PVMH; y, finalmente, concluimos el documento y discutimos el trabajo futuro en la Sección6 6.

2. Obras relacionadas
La computación en la nube y las tecnologías de TI tradicionales tienen diferentes modelos de
servicio, modos operativos, formas de intercambio de información y tecnologías que brindan
servicios en la nube, lo que hace que la computación en la nube enfrente diferentes amenazas y
riesgos de las tecnologías de TI tradicionales. La virtualización juega un papel importante en la
construcción de la computación en la nube. Sin embargo, hay varias vulnerabilidades en las
implementaciones de virtualización actuales, y la capa de virtualización [6 6] enfrenta varios
desafíos de seguridad. Con la ayuda de la virtualización de la red, una única infraestructura de red
se puede dividir en varias arquitecturas virtuales. Esto beneficia a una amplia gama de aplicaciones,
incluidas las infraestructuras de computación en la nube. En [7 7], Bays y col. discutió varios
desafíos y amenazas principales relacionados con la seguridad de la red virtual, y presentó las
soluciones correspondientes, así como los aspectos de seguridad que aún no se habían abordado. En
un entorno de nube, la seguridad es vital para detectar intrusiones en la capa de red virtual. Nathiya
y col. [8] propuso un sistema híbrido de detección de intrusos (H-IDS) para monitorear la seguridad
en una capa de red virtual, pero no implementaron ni verificaron el experimento.
Los problemas de seguridad en la virtualización se pueden dividir en dos categorías: riesgos de
seguridad de virtualización y ataques de seguridad de virtualización. Ataques de virtualización
comunes [9] incluyen robo y manipulación de máquinas virtuales, salto de máquinas virtuales,
escape de máquinas virtuales, ataques de rootkit basados en máquinas virtuales (VMBR) y ataques
de denegación de servicio. Basado en el modelo BLP, Jiang et al. [10] propuso PVME para evitar que
la máquina virtual escape de los aspectos del control de acceso. Agregaron dos nuevas propiedades
Internet futuro 201911, 82 3 de 21
de acceso (ejecutar (e *) y control (c *)) al modelo PVME y formularon varias reglas para diferentes
estados de VM. Nguyen y col. [11] demostró que el conmutador virtual en sí mismo puede
retransmitir TCP
paquetes, que pueden ser abusados para ataques de amplificación por atacantes internos.
Rakotondravony y col. [12] presentó una nueva clasificación de ataques de malware en entornos de
nube IaaS, que ayuda a los profesionales en las primeras etapas del diseño de mecanismos de
mitigación basados en introspección de máquinas virtuales mediante la identificación de ataques
relevantes.
Central para el entorno de la nube es la tecnología de virtualización, cuyo núcleo es la máquina
virtual (VM). Por lo tanto, las capacidades de comunicación entre máquinas virtuales son
primordiales. Para los usuarios de la nube, la mala comunicación de la VM extiende las tareas de los
inquilinos y el tiempo de arrendamiento de la VM, lo que eventualmente aumenta sus costos. Por
otro lado, la mala comunicación entre las máquinas virtuales también introduce vulnerabilidades de
seguridad [13] Al-Said y col. [14] describió los desafíos de seguridad que existen en las técnicas de
virtualización y que se utilizan para admitir a varios clientes en una infraestructura física
compartida. Ren y col. [15] analizó las amenazas y desafíos de seguridad que enfrentaban las
máquinas virtuales y presentó varios ataques típicos a la máquina virtual en la plataforma Xen.
Elmrabet y col. [dieciséis] propuso una nueva arquitectura de seguridad de tres capas, que se
compone de conmutador virtual, firewall virtual y VLAN, para evitar ataques a máquinas virtuales,
como inhalación, suplantación e inundación de mac. Sathya y col. [17] introdujo un modelo
confiable para la seguridad de VM en la computación en la nube. Encriptaron las imágenes de VM y
utilizaron la técnica de instantánea y un monitor de terceros, todo lo cual mejora la
confidencialidad, integridad y disponibilidad de VM en la nube. Mohammad-Mahdi y col. [18 años]
presentó un enfoque para detectar de manera eficiente los ataques de canal lateral basados en la
memoria caché entre máquinas virtuales, utilizando información detallada del hardware
proporcionada por la Tecnología de monitorización de caché de Intel (CMT) y los Contadores de
rendimiento de hardware (HPC).
Estos estudios sobre seguridad de virtualización han logrado resultados relativamente
satisfactorios en la prevención de seguridad de virtualización. Sin embargo, al centrarse en el
problema del ataque de salto de máquina virtual, estos estudios son relativamente unilaterales y no
resuelven bien este problema. Una vez que ocurren los ataques de salto de máquina virtual, los
archivos en la máquina virtual atacada quedan completamente expuestos al atacante, e incluso toda
la capa de virtualización está implicada, lo que resulta en una fuga a mayor escala. Por lo tanto, la
prevención de ataques de salto de máquinas virtuales tiene un valor de investigación muy alto.

3. Preliminares

3.1. VM Hopping

3.1.1. Análisis de salto de VM

El salto de VM es un modo de ataque común en los ataques de seguridad de virtualización.
Significa que un atacante intenta obtener acceso a otros dispositivos virtuales en el mismo
hipervisor basado en una máquina virtual, y luego lo ataca. Según la implementación de la
virtualización, las máquinas virtuales en el mismo hipervisor pueden comunicarse entre sí mediante
conexiones de red, memoria compartida u otros recursos compartidos. Sin embargo, es la
implementación de la virtualización lo que da como resultado el salto de VM. El salto de VM se
puede dividir en las siguientes dos situaciones:
En un caso, un atacante podría usar una máquina virtual maliciosa para acceder
silenciosamente o controlar otras máquinas virtuales en el hipervisor mediante esas comunicaciones
entre máquinas virtuales.
Otra situación es que si un atacante de la máquina virtual VM1 sobrepasa ilegalmente la capa
de hipervisor y obtiene acceso al sistema operativo host, incluso puede destruir la máquina virtual
VM2.

3.1.2. Peligro de salto de VM

Las dos situaciones de ataques de salto de VM representan una gran amenaza para la capa de
virtualización e incluso para toda la plataforma de la nube desde diferentes aspectos.
En la primera situación, un atacante usa una máquina virtual maliciosa y accede o controla
silenciosamente otras máquinas virtuales en el mismo host mediante la comunicación de la
máquina virtual. Por un lado, dado que el atacante puede monitorear el flujo a través de la máquina
virtual atacada, puede atacar la máquina virtual controlando o cambiando el flujo. Por otro lado, el
atacante puede modificar la configuración de
la máquina virtual controlada, de modo que la máquina virtual en ejecución se ve obligada a
apagarse, lo que provoca la interrupción de la comunicación y la comunicación incompleta. Toda la
máquina virtual atacada está expuesta al atacante, y todos los archivos almacenados en él están
desprotegidos, causando pérdidas inmensurables a los usuarios de esta máquina virtual.
Cuando el ataque de salto de VM tiene éxito, el atacante aterriza directamente en el host al
sobrepasar la capa del hipervisor. Inevitablemente, el atacante puede interceptar el flujo de datos de
E / S de otras máquinas virtuales en esta máquina host, analizar y obtener datos relevantes de otros
usuarios, y luego llevar a cabo más ataques a la información confidencial. Si se modifica el usuario
predeterminado, o incluso la información básica del administrador, la máquina host también
quedará desprotegida. Además, si una máquina virtual en el host se ejecuta como un servicio
básico, el atacante puede apagar o eliminar la máquina virtual a través de los privilegios del
hipervisor, lo que provoca la interrupción de los servicios básicos y un desastre irrecuperable para
toda la plataforma de virtualización.

3.1.3. VM Hopping Defense

En la actualidad, la defensa de salto VM se resuelve principalmente mediante la construcción
de hipervisores más saludables y el diseño de políticas de control de acceso más robustas.
(1) Construir hipervisor ligero. En la mayoría de los sistemas informáticos, TCB (base
informática confiable) es una combinación de todos los dispositivos de seguridad que constituyen
un sistema seguro. TCB, que proporciona seguridad para todo el sistema, es altamente confiable y es
la base para garantizar la seguridad de las operaciones de aplicaciones de alto nivel. Sin embargo,
cuanto mayor es el TCB, más código, mayor probabilidad de vulnerabilidad y más difícil es
garantizar su propia credibilidad. Por lo tanto, el diseño de hipervisores ligeros debe ser lo más
simple posible. Un hipervisor ligero, como Trustvisor, Secvisor y Cloudvisor, solo conserva la
característica clave e implementa las otras características en otras capas de virtualización. Hasta
donde sabemos, ARCN, el último hipervisor liviano, solo tiene 25,000 líneas de código.
(2) Diseño de política de control de acceso [19] El control de acceso es un medio técnico común
para la seguridad del sistema y la seguridad de la información, que garantiza la confidencialidad e
integridad de los datos desde todos los aspectos. En el campo de la virtualización, los riesgos de
seguridad son causados principalmente por el acceso ilegal a los recursos, y el diseño del control de
acceso está dirigido a los derechos de acceso de los recursos entre el sujeto y el objeto. Por lo tanto,
la política de control de acceso se utiliza para resolver los problemas relacionados en el dominio
virtualizado. Debido a las transiciones de estado más complejas y los riesgos de los ataques de salto
de máquinas virtuales, se debe diseñar específicamente un conjunto de políticas de control de
acceso.
En este documento, asumimos que el sistema host es confiable y solo nos concentramos en la
política de control de acceso de las máquinas invitadas.

3.2. Control de acceso

El control de acceso consta de tres entidades: el sujeto (que envía la solicitud de acceso), el
objeto (al que se accede) y la política de acceso de seguridad (las reglas de acceso del sujeto que
accede al objeto).
El control de acceso tradicional tiene tres políticas de acceso: (1) Control de acceso discrecional
[20] (DAC), que permite a un sujeto imponer restricciones específicas sobre el control de acceso. (2)
Control de acceso obligatorio [21] (MAC), que no permite la interferencia del sujeto hasta cierto
punto. (3) Política de control de acceso basada en roles [22] (RBAC), que asigna derechos de acceso
según los roles de los usuarios. Con el rápido desarrollo de la computación en la nube, la
computación móvil y otros escenarios de aplicaciones, también existe un control de acceso basado
en atributos [23] (ABAC).

3.2.1. Modelo BLP

El modelo de seguridad Bell-LaPadula [24] (Modelo BLP), propuesto por DE Bell y LJ
LaPadula en 1973, es un modelo de seguridad multinivel que simula una estrategia de seguridad
militar y es el modelo de seguridad multinivel más famoso. El modelo BLP se usa para controlar el
acceso a la información clasificada. Como el primer modelo matemático que formaliza la política de
seguridad, es una máquina de estado que utiliza el estado
variables para representar el estado de seguridad del sistema y reglas de transición de estado para
describir el proceso de cambio del sistema.
El modelo BLP tiene muchas ventajas: (1) El modelo BLP es uno de los primeros modelos para
describir la política de seguridad de niveles múltiples. (2) El modelo BLP es un modelo
estrictamente formalizado y tiene la prueba formalizada. (3) El modelo BLP es un modelo seguro
con control de acceso discrecional y control de acceso obligatorio. (4) La información de control solo
puede pasar de baja seguridad a alta seguridad, que cumple con el departamento militar y otras
instituciones con alta demanda de confidencialidad de datos.
Sin embargo, también tiene algunas desventajas: (1) La información de baja seguridad fluye
hacia objetos de alta seguridad, lo que puede dañar la integridad de los datos de los objetos de alta
seguridad y ser utilizado por virus o piratas informáticos.
(2) Mientras sea legal que la información fluya de baja seguridad a alta seguridad, no se ajusta al
principio de privilegio mínimo, sin importar si hay demanda de trabajo. (3) El modelo BLP se centra
en el control de confidencialidad, pero carece de control de integridad, por lo que no puede resolver
el problema de los canales ocultos, lo que significa que los procesos de alto nivel pueden transmitir
información a los procesos de bajo nivel al compartir recursos.

3.2.2. Modelo Biba

El modelo Biba [25], propuesto por KJ Biba en 1977, es el primer modelo que involucra la
integridad de los sistemas informáticos. El modelo Biba se desarrolló después del modelo BLP y se
utilizó para abordar problemas de integridad de datos de la aplicación.
El modelo Biba admite cinco tipos de políticas de control: (1) Política de control de acceso
obligatorio con bajo nivel de agua (LOMAC), (2) Política de control de acceso obligatorio con bajo
nivel de agua para objeto (LOMAC-O),
(3) política de auditoría de integridad de bajo nivel de agua (LO-IA), (4) política de anillo (RP) y (5)
política de integridad estricta (SIP). Entre estas políticas de seguridad, la integridad más estricta es
la más famosa, que es matemáticamente dual con el modelo de política de seguridad BLP. Dado que
la política de integridad estricta se usa con mayor frecuencia, el modelo de Biba se refiere a esta
política específica en la mayoría de los casos.
La política de integridad estricta es un doble matemático de la estrategia de confidencialidad
basada en los Criterios de evaluación del sistema informático de confianza (TCSEC). La estricta
política de integridad proporciona las características Sin lectura hacia abajo (NRD) y Sin escritura
hacia arriba (NWU). De estas dos características, los modelos Biba y BLP tienen características
exactamente opuestas. El modelo BLP proporciona confidencialidad, mientras que el modelo Biba
garantiza la integridad de los datos.

4. Métodos
El modelo BLP permite que la información fluya de baja seguridad a alta seguridad y prohíbe
el flujo de información en la dirección opuesta. El modelo Biba permite que la información fluya de
alta integridad a baja integridad, y prohíbe el flujo de información en la dirección opuesta. Si el
modelo BLP se combina directamente con el modelo Biba, que implementa una política de
integridad estricta, las entidades en diferentes niveles no pueden comunicarse entre sí, lo que
resulta en "islas de información" en el sistema. Por lo tanto, en la aplicación práctica, estos dos
modelos no pueden aplicarse directamente, un modelo tiene que hacerse con las modificaciones
correspondientes al otro modelo.

4.1. Diseño de modelo PVMH

El fondo de la aplicación de los modelos BLP y Biba estaba dirigido al entorno del sistema
operativo tradicional. Teniendo en cuenta que el escenario estudiado en este documento es un
entorno de virtualización, el modelo de control de acceso PVMH está diseñado en función de las
características de los entornos de virtualización y las diferencias entre los entornos de virtualización
y los sistemas operativos tradicionales. En gran medida, el modelo PVMH toma prestado del
modelo BLP. Como modelo para evitar ataques de salto de máquina virtual, también integra las
características del modelo Biba en el modelo BLP.
4.1.1. Elementos del modelo
Básicamente, el modelo PVMH hereda la mayoría de las notaciones del modelo BLP; Sus
elementos principales del modelo incluyen: Sujeto, objeto, atributo de acceso, matriz de control de
acceso, nivel de seguridad, etc., de la siguiente manera:

1. Asunto: La S mayúscula representa el conjunto de sujetos, mientras que la s minúscula es un

sujeto único, es decir, S = {s1, s2,. . . , sn}.
2. Objeto: la O mayúscula representa el conjunto de objetos, mientras que la minúscula o
representa un solo objeto, es decir, O = {o1, o2,. . . , en}.
3. Conjunto de atributos de acceso A = {r, a, w, e}: El modelo PVMH tiene diferentes atributos:
solo lectura (r), solo escritura (a), lectura-escritura (w) y ejecución (e).
4. Matriz de acceso M: cada elemento mij en M representa el permiso de acceso del sujeto Si al
objeto
Oj en estado actual
5. Nivel de seguridad R = (C, I, K): la C mayúscula indica el nivel de confidencialidad, la I
mayúscula indica el nivel de integridad y la K mayúscula indica la categoría de seguridad. El
modelo PVMH tiene varias funciones asociadas con el nivel de seguridad: fsc para la
confidencialidad del sujeto, fsi para la integridad del sujeto, fsk para la categoría de seguridad
del sujeto, foc para la confidencialidad del objeto, foi para la integridad del objeto, fok para la
categoría de seguridad del objeto, fht para la redacción más alta nivel y flt
para el nivel más bajo de redacción. La función frole representa la identidad del usuario, es
decir, si el usuario es un sujeto de confianza (hipervisor o la máquina virtual privilegiada) o un
sujeto general. Las notaciones ≥ y> representan la relación de confidencialidad parcialmente
ordenada entre
sujeto y objeto, mientras que la notación ⊇ representa la relación . de inclusión de la seguridad
categoría Entre tema y objeto.
. los seguridad nivel conjunto R =R, R,. . . , R es un conjunto de
orden parcial, y cada elemento y
Ri = Ci, Ii, Kj en el conjunto representa un nivel de
seguridad, donde Ci ∈ C, Ii ∈ I, Kj ⊆ K, 1 ≤ i ≤ p. Ri Σ
domina a Rj, denotado como Ri ≥
y Σ o
y j
pags21
Rj,
o si y solo si Ci ≥ Cj ∪ Ii ≥ Ij ∪ Kj ⊇ Kj. o
Las funciones fsr representan los niveles de seguridad del sujeto y representan los niveles de
seguridad del objeto.
6. Etiqueta de seguridad sujeto-objeto: la etiqueta de seguridad del sujeto incluye el nivel de
seguridad, la categoría de información (opcional) y el nivel más alto de redacción. El nivel de
escritura más alto del sujeto indica el nivel de seguridad más alto del objeto que le permite al
sujeto realizar el acceso de agregar o escribir solamente. La etiqueta de seguridad del objeto
incluye el nivel de seguridad, la categoría de información (opcional) y el nivel de escritura más
bajo. El nivel de escritura más bajo del objeto representa el nivel de seguridad más bajo del
sujeto que permite agregar o solo acceso de escritura al objeto.
7. Elemento de solicitud RA = {g, r}: la g minúscula representa una solicitud de obtención o
entrega, mientras que la r minúscula representa una solicitud de liberación o rescisión.
8. El conjunto de estados del sistema V está representado por un cuaternión V = {B × M × F × H},
donde B = P (S × O × A) es el conjunto de acceso actual, b representa el conjunto de acceso
actual, M es el acceso matriz de control, F es la función de acceso y H es la estructura
jerárquica entre objetos, que representa la relación subordinada entre objetos. En la jerarquía
de objetos, hay como máximo un nodo y solo un nodo primario, y no hay ningún anillo en la
estructura.

4.1.2. Axiomas de seguridad

Todos los axiomas de seguridad del modelo PVMH se nombran con PVME- como prefijo.
Axioma 1 (PVMH-ds Axiom). El axioma PVMH-ds se ha mejorado del axioma de seguridad
ds característico de BLP. El estado v = (b × M × f × H) satisface el axioma de seguridad discrecional,
si y solo si
∀ (s, o, x) ∈ b, x ∈ Mij siempre es cierto, donde x es uno de los cuatro atributos de acceso:
solo lectura (r), solo escritura
(a), lectura-escritura (w) o ejecución (e).
 Axioma 2 (PVMH- * Axioma).S ' es un subconjunto de S. Un estado v = (b × M × f × H) satisface
el PVMH- *
axioma, si y solo si para todos (s, o, x) ∈ b, existe:

 (O ∈ b (s: r)) ⇒ ( fsr(S)>para(O))
s ∈ sJ ⇒  (O ∈ b (s: a)) ⇒ ( fsr (S) <para (O) y fht (S) ≥ para (O) y fsr (S) ≥ flt
(O)) (O ∈ b (s: w)) ⇒ ( fsr (S) = para (O))
 (O ∈ b (s: e)) ⇒ ( Si ∈ ST)


De acuerdo con la característica ss de BLP, la característica PVMH-ss debería existir en el

modelo PVMH. Sin embargo, el hipervisor necesita comunicarse con las máquinas virtuales
invitadas, y tiene permiso de acceso total a todas las máquinas virtuales invitadas, es decir, solo
lectura (r), solo escritura (a), lectura-escritura (w) o ejecutar (e). Por lo tanto, cuando el hipervisor
desempeña el papel de sujeto, está en el conjunto de temas de confianza ST, que obviamente viola la
característica PVMH-ss; pero, para todas las máquinas virtuales invitadas, satisfacen la característica
PVMH - *, y es fácil deducir que también satisfacen la característica PVMH-ss. Por lo tanto, debido a
la existencia del hipervisor, la llamada característica PVMH-ss debe eliminarse del modelo PVME.

4.1.3. Reglas estatales de transición

Basado en el criterio de seguridad BLP y el modelo Biba, el modelo PVMH mejora la
integridad y confidencialidad del modelo BLP en cierta medida. El modelo PVMH incluye 11 reglas
de transición de estado, que se expresan como PVMH - Ri, donde 1 ≤ i ≤ 11. El dominio de la regla
se denota como dom (PVMH - Ri). El resultado de salida se define como el conjunto D = {sí, no,?},
Donde "sí" acepta el
solicitud, "no" rechaza la solicitud y "?" significa que la solicitud es ilegal, que no pertenece a ninguna
Solicitar dominio.
Regla 1 (PVMH - R1 (get-read)). La máquina virtual del sujeto Si accede a la máquina
, . ,
virtual del objeto Oj en modo de solo lectura (r). La definiciónΣ es dom (PVMH - R1) = Rk |
g, Si, Oj, r ∈ R (1). Este pseudocódigo es el siguiente:
 . (?, v) yo F Rk ∈/ / dom (PVMH
. ΣΣ
si, si .. - R1 ) Si [RkΣ∈ dom (PVMH
Syo , Oj , r , METRO,
f, HΣΣ - R1)]
∪ Σ ij
PVMH - R1 (Rk , v) = y rM ∈
Σ . Σ Σ
 y Fsr (Syo )> fo Oj o Syo ∈ ST
(No, v) de otra manera

Si la decisión es "sí", agregue una nueva regla que indique que Si puede acceder a Oj en modo de
solo lectura (r) en el conjunto de acceso actual.
Regla2 (PVMH - R2 (get-append)). Materia virtual Si
accesos
objeto de máquina virtual Oj en solo escritura o anexar (a) modo La definición es
.
dom(PVMH - R2) = ,Rk El | gramo,Si, Oj, aΣ ∈ R (1) ,. El pseudocódigo es el siguiente:
 (?, v)
. . ΣΣ Σ yo F RΣk ∈/ / dom (PVMH - R2 )
si, si
..
, METRO, Si [R ∈
dom(PVMH R- )] y una
Syo , Oj , Σ .Σ
 f, HΣΣ M y F (S). < fO
∪ una ∈2 ijk ΣΣ ΣΣ
PVMH - R2 (Rk , v) = unre ΣF ht (S yo ) ≥ F oC O j
sr oyo
y FCarolina del Sur . (S
Σyo ) ≥ flt Oj
 o [Syo ∈ ST ] Σ

(No, v) de otra manera

Si la decisión es "sí", agregue una nueva regla que indique que Si tiene acceso a Oj en modo de
solo escritura o anexe (a) al conjunto de acceso actual.
 Regla 3 (PVMH - R3 (get-write)). La máquina virtual del sujeto Si accede a la máquina
virtual del objeto Oj
o ST (sujeto de confianza) accedió a la máquina virtual de objetos Oj en modo lectura-escritura (w).
La definición es
.
dom(PVMH - R3) = ,Rk El | gramo,Si, Oj, wΣ ∈ R (1) ,. Este pseudocódigo es el siguiente:
PVMH - R (R , v) = .
(?, v) yo F Rk ∈/ / dom (PVMH
 . .. ΣΣ
si, si - R3 )
Syo , Oj , w , METRO, Σ Σ
3 ∪ f, HΣΣ Si [R ∈
dom(PVMH R- )] y w
Σ .
∈3 ijkΣΣ M y fsr (Syo ) = fo
Oj
o [Syo ∈ ST ]
(No, v) de otra manera

Si la decisión es "sí", agregue una nueva regla que indique que Si tiene acceso a Oj en modo
lectura-escritura (w) en el conjunto de acceso actual.
Regla 4 (PVMH - R4 (dar-leer / agregar / escribir)).
Hipervisor (Sλ) necesita
setpermissionforsubjectvirtualmachine Si
accessingobjectvirtualmachine Oj
en cierto modo, incluido, solo lectura, solo escritura
, o lectura-escritura. La definición es
.
dom(PVMH - R4) = Rk El | Sλ,
gramo, Si, Oj, xΣ ∈ R (2), x ∈ A. Este pseudocódigo es el siguiente:

(?, v) yo F Rk ∈/ / dom (PVMH
 .
. - R4) Si [Rk ∈ dom (PVMH
PVMH - R4 (Rk, v) =  si, si, M \ Mij ← {x}, f,
HΣΣ - R4)] y [Sλ ∈ ST ] unre Oj
 ∈/ / O R Σ

(nov) Σ
de otra manera

Si la decisión es "sí", agregue un nuevo elemento al que Si puede acceder a Oj en modo x en la

matriz de acceso.
Regla5 (PVMH - R5 (Crear objeto)). Tema Si (Hipervisor privilegiado

máquina virtual) necesita crear un objeto virtual máquina virtual

Oj. La definición es
.
dom(PVMH - R5) = ,Rk El | gramo,Si, Oj, LuΣ ∈ R (3) ,. El pseudocódigo es el siguiente:

 . (?, v) yo F Rk ∈/ / dom (PVMH
. . ΣΣΣ
- R5) Si [Rk ∈ dom
PVMH - R5 (Rk, v) =  si, si, M, f \ fo ← fo OjLu
∪ (PVMH - R5)]
 y [Sλ ∈ ST]

(nov) de otra manera
. Σ . Σ
La notación es asignación,
. Σ ←∪
lo que significa .asignar
o Σf O, L atuf. El par O, L seo refiere a la relación
de mapeo f O = L mientras que el par O, O se refiere a otra o relación H (O) = O. La notación f \ fo ←
.
fo ∪ Oj, Lu significa establecer
tuj el nivel de seguridad
j de Oj en Lu en el vector de nivel de seguridad
(consulte la Sección4.1.3) Esta
tu expresión también R se usa Rj
en las siguientes reglas.
Σ
Si la decisión es "sí", se crea Oj y, mientras tanto, el elemento relacionado se agrega al nivel de
seguridad y al nivel de objeto.
Regla 6 (PVMH - R6 (eliminar objeto)). El sujeto Si (hipervisor o máquina virtual
privilegiada) necesita eliminar la máquina virtual objeto Oj (1 ≤ j ≤ n), n máquinas
, , .
virtuales en total). La definición es dom (PVMH - R6) = Rk | Si, OjΣ ∈ R (4). El pseudocódigo
es el siguiente:

 (?,. v) Σ
. . ΣΣ yo F Rk ∈/ / dom (PVMH - R6 6 )
si - ACC O j - AIRE LIBRE S j ,
.
PVMH - R6 6 (R k , v) =   sí,  Σ tuj ← ∅, METROjtu
METRO Si [Rk ∈ dom (PVMH - R6 6)] y [Sλ ∈ ST ]
M\ ← ∅ , F , 
. Σ
H - OR, Ohj Σ Σ
Σ Σ
 y S j ∈/ / y O j ∈/ / O R
 ST
(No, v) de otra manera

Inthisfunction, 1 ≤ ≤ Naciones Unidas, con

norte virtualmachinesin total. Notación ACC.OjΣ = .S × .OjΣ × AΣ
∩ b se refiere a todos los accesos asociados con Oj en la corriente
 .
conjunto de acceso b mientras la notación OPE (Si) = {S} × Oj × A ∩ b se refiere a todo el acceso de Si a
la máquina virtual eliminada en el conjunto Σ de acceso actual b.
Si la decisión es "sí", Oj se elimina y, mientras tanto, el elemento relacionado se elimina del
acceso actual b, la matriz de acceso M y el nivel de objeto H.
Regla7 (PVMH - R7 (rescindir-leer / agregar / escribir)). TheHypervisor
(Sλ)
necesita revocar el permiso para la máquina virtual sujeto Si acceder al objeto virtual máquina
Oj, incluso solo lectura, solo escritura, orread – write. La definición
es
.
dom(PVMH - R7) = ,Rk El | Sλ, r, Si, Oj, xΣ ∈ R (2) ,, x ∈ A. El pseudocódigo es el siguiente:
PVMH - R7 (Rk, v) =
 (?, v) yo F Rk ∈/ / dom (PVMH
- R7) si, bS , O, x, M Mx f Hola F
 . . . Σ ΣΣ
[R dom(PVMH R )] -
Σ
unre [Sλ ∈ ST ] unre Oj ∈/ /
\ - ∈-{ } 7
OR Σ
(No, v) de otra manera

Si la decisión es "sí", elimine el elemento de que Si puede acceder a Oj en modo x desde la

matriz de acceso y, mientras tanto, elimine la regla de que Si puede acceder a Oj en modo x del
conjunto de acceso actual.
Regla 8 (PVMH - R8 (modificar-objeto-l)). El hipervisor necesita modificar Lu, el nivel de
seguridad
de objeto máquina virtual.
A continuación, PVMH - ∗ (Rk, v) es la función característica, que garantiza que si genera
"verdadero" y el estado v satisface la característica PVMH- * con respecto a S ∗ (S ∗ ⊆ S), el estado
v después de esta transición también satisface la característica PVMH- *. La estricta definición
matemática es
como sigue:
PVMH - ∗ Σ(Rk, v) = verdadero ⇔
Σ. Σ
S J
S , S , Oh si L F (S ) Y F (S )∀ ∈ F
& Σ.Sλ , Oj, w Σ ∈ b ⇒ Lu = fsr (Sλ)
Σ Sλ, Oj,∈r Σ⇒
& ∈ b ⇒ Lu fsr (Sλ) Σ ≥tu sr Carolina del
OO , Σ. S Oh abfΣ (O) L & f (O ) Σ
∀ ∈ λΣ ∈ sij ⇒ p∈a r a⇒( O
or λ tu oC λ ≥ ht
& λΣ.Sλ , Oj, w
Σ )
λ Σ
& Sλ,Σ Oj, r ∈ b ⇒ para (Oλ) Lu
, . Σ ,
=
La Lu
definición isdom(PVMH - R8) = Rk rSi, Oj, Lu El pseudocódigo
∈(3)
como sigue: El | R es
PVMH - R (R , v) = .
(?, v) yo F Rk ∈/ / dom (PVMH

si, - R8 ) b,
. M, Σf ffO . ΣΣΣ L HO , Oi F [R
. \R
←)] ∪ ∪
8 dom(PVMH
Σ
∈ -o y [Syo ∈ ST ] y Oj ƒ = OR y
o tu
[PVMH - ∗ (Rk , v) Σ=
verdadero]
(No, v) de otra manera

Si la decisión es "sí", establezca el nivel de seguridad de Oj en Lu.

Regla 9 (PVMH - R9 (modificar- fsc)). El sujeto de confianza necesita modificar el
nivel de escritura más alto para un determinado sujeto virtual máquina La definición es
, ,
.
dom(PVMH - R9) = Rk El | r, Si, Oj, fhtΣ ∈ R (5). El pseudocódigo es el siguiente:
PVMH - R (R, v) =
(?, v) yo F Rk ∈/ / dom (PVMH

- R9) (si, (fht = más alto)) Si [Rk ∈ dom (PVMH -
9
 R9)]
Σ. Σ Σ
unre [ frole (Si) = admin] y Sm, Oj, a ∈ /
by [fsc (Si) ≤ Máximo]
(No, v)
 La notación fht se refiere al nivel más alto de redacción de la asignatura, mientras que "Más
alto" se refiere al nivel más alto de redacción de la asignatura otorgado por la administración. Si la
decisión es "sí", el nivel más alto de redacción del tema se actualiza a "Más alto".
Regla 10 (PVMH - R 10 (modificar-foc)). los sujeto de confianza necesita modificar el
nivel de escritura más bajo para una determinada materia virtual máquina La definición es
, ,
.
dom(PVMH - R10) = Rk El | r, Si, Oj, fltΣ ∈ R (5). El pseudocódigo es el siguiente:

 (?, v) yo F Rk ∈/ / dom (PVMH
 - R10) (si, (fht = más bajo)) Si [Rk ∈ dom (PVMH -
PVMH - R10 (Rk, v) = R10)] Σ. Σ Σ
[ (S) = ∈metroyo
y F Σ . Σ y S, O, a / by foc
admin] jrolmi

Oj ≤ MásΣ bajo

(No, v) de otra manera

La notación flt se refiere al nivel más bajo de redacción de la asignatura, mientras que "Más
bajo" se refiere al nivel más bajo de redacción de la asignatura otorgado por la administración. Si la
decisión es "sí", el nivel más bajo de redacción del tema se actualiza a "Más bajo".
Regla 11 (control de acceso discrecional). La matriz de acceso permite que la máquina virtual
de sujeto Si acceda a la máquina virtual de objeto Oj en modo x solo si x está contenido tanto en el
elemento de fila de Si como en el elemento de columna de Oj en la matriz de control de acceso. El
.
estado v satisface la característica de seguridad discrecional si y solo si Si, Oj, x ∈ b ⇒ x ∈ Mij.
Al establecer el nivel deΣ redacción más alto y el nivel de redacción más bajo que cada sujeto
puede
escriba en, el modelo PVMH implementa restricciones de integridad más estrictas, manteniendo la
mayoría de las características de seguridad del modelo BLP, por lo que también tiene una mayor
seguridad.

4.2. Mapeo del modelo PVMH

4.2.1. Asignación de sujeto a objeto

Este artículo toma a Xen como la plataforma de virtualización. En Xen, la máquina virtual
privilegiada se denota como Domain0, la máquina virtual ordinaria se denota como DomainU y el
administrador de la máquina virtual se denota como Hypervisor. Domain0 e Hypervisor son los
sujetos de confianza, que administran todas las máquinas virtuales en el mismo host. En el modelo
BLP, tanto el sujeto como el objeto son palabras abstractas, mientras que en el sistema de plataforma
en la nube, el sujeto puede ser Hypervisor, Domain0 o DomainU, y el objeto puede ser Hypervisor,
DomainU, o un archivo específico, fragmento de memoria, unidad de datos , etc. Cuando el control
de acceso está relacionado con el hipervisor, el hipervisor se encuentra en el nivel más alto de
confidencialidad e integridad.

4.2.2. Asignación de atributos de acceso

En Xen, las operaciones de lectura y escritura entre máquinas virtuales invitadas se realizan a
través de mecanismos de comunicación. La interacción entre las máquinas virtuales invitadas
corresponde a las propiedades de acceso del modelo PVMH. En el modelo PVMH, se pueden
establecer canales de eventos y enviar notificaciones de eventos siempre que una máquina virtual
invitada tenga algún acceso para atribuir a otra máquina virtual invitada. La operación
correspondiente se puede encontrar en las transiciones de estado del modelo PVMH, como se
muestra en la Tabla1.
 Tabla 1. Reglas de transición del estado.
Correspondiente
Máquina virtual Estado correspondiente Función Efecto
Reglas de
gestión de Transición
El hipervisor modifica el permiso de
modificando el acceso permiso Regla 8
máquinas
acceso para
virtuales cierta máquina virtual
Regla 10
El hipervisor modifica el nivel de
modificar el nivel de
seguridad de una determinada
seguridad del objeto Regla 9
máquina virtual sujeta. El hipervisor
modificar el nivel de seguridad
modifica el nivel de seguridad de
del sujeto Regla 4
una determinada máquina virtual de
objetos.
Regla 7
El hipervisor otorga algún atributo de
autorizando el atributo de
acceso a una determinada máquina
acceso
virtual sujeta. Regla 5
crear una El hipervisor revoca algunos atributos de
liberar el atributo de Regla 5
máquina acceso de una determinada máquina
acceso
virtual invitada virtual sujeta.
El hipervisor crea una máquina Regla 6
creando un tema
virtual en cuestión y establece su
eliminar una nivel de seguridad. El hipervisor Regla 6
máquina creando un
crea una máquina virtual de
objeto
virtual invitada objetos y establece su nivel de Regla 2
seguridad.
El hipervisor elimina una máquina Regla 1
comunicación de borrar un tema
virtual en cuestión y sus datos
máquina virtual relacionados. Regla 3
(acceso a datos El hipervisor elimina una máquina
compartidos, etc.) eliminar un
virtual de objetos y sus datos
objeto
relacionados.
La máquina virtual del sujeto escribe
escribir un
datos y lee datos de la máquina virtual del
objeto
objeto. La máquina virtual del sujeto solo
leyendo un
lee datos de la máquina virtual del objeto.
objeto
La máquina virtual del sujeto solo escribe
anexar un objeto
datos en la máquina virtual del objeto.

4.2.3. Mapeo de matriz de acceso

En nuestro marco diseñado con el modelo PVMH, la matriz de acceso se almacena como un
archivo binario en el administrador de la máquina virtual, mientras que un archivo de copia de
seguridad también se almacena en la máquina virtual privilegiada. Cada elemento de la matriz de
acceso es una tupla ordenada unidimensional (SID, OID, R, A, W, Flag) donde SID es el número de
ID de seguridad del sujeto, OID es el número de ID de seguridad del objeto, R es un atributo de
acceso de solo lectura , A es un atributo de acceso de solo escritura, W es un atributo de acceso de
lectura-escritura y Flag se usa para indicar si la regla es válida; "1" es válido y "0" no es válido. El
administrador del sistema establece el número de ID de seguridad, y el sistema de nube asigna el
número de ID de la máquina virtual en la plataforma en la nube cuando se inicia la máquina virtual.
Para una máquina virtual, tanto el SID como el OID son iguales a su número de ID de seguridad, es
decir, SID = OID = ID. En la plataforma en la nube, el número de ID es un número binario de 13 bits,
y R, A y W están representados por números binarios de 1 bit. Cuando R (o A o W) se establece en 1,
el sujeto tiene el atributo de acceso para el objeto, y cuando el valor se establece en 0, el sujeto no
tiene el atributo de acceso para el objeto. Se puede ver que la tupla de seis elementos tiene un total
de 30 dígitos binarios (13 bits para SID y OID, 1 bit para R, A y W, y 1 bit para Flag), y la matriz de
acceso predeterminada se ordena por par (SID, OID) en orden ascendente, lo cual es muy eficiente
para buscar más tarde. el sujeto no tiene el atributo de acceso para el objeto. Se puede ver que la
tupla de seis elementos tiene un total de 30 dígitos binarios (13 bits para SID y OID, 1 bit para R, A y
W, y 1 bit para Flag), y la matriz de acceso predeterminada se ordena por par (SID, OID) en orden
ascendente, lo cual es muy eficiente para buscar más tarde. el sujeto no tiene el atributo de acceso
para el objeto. Se puede ver que la tupla de seis elementos tiene un total de 30 dígitos binarios (13
bits para SID y OID, 1 bit para R, A y W, y 1 bit para Flag), y la matriz de acceso predeterminada se
ordena por par (SID, OID) en orden ascendente, lo cual es muy eficiente para buscar más tarde.

4.2.4. Conjunto de acceso actual

El conjunto de acceso actual b (b ⊆ S × O × A) incluye todo el acceso que el sujeto tiene para el
objeto en algunos modos determinados. El conjunto de acceso actual se puede usar para determinar
si el estado del sistema es seguro. En el modelo PVMH, cada sujeto tiene su propio conjunto de
acceso actual b, denotado como b (S) ⊆ O × A. Los elementos en el conjunto de objetos O están
representados por OID, y el conjunto de atributos de acceso A incluye tres elementos: solo (r), solo
escritura (a) y lectura-escritura (w).
4.2.5. Nivel de seguridad
El modelo PVMH tiene 8 niveles de confidencialidad y 8 niveles de integridad. El conjunto de
confidencialidad se define como C = {C1, C2,. . . , C8}, donde C1> C2>. . . > C8, mientras que el
conjunto de integridad se define como I = {I1, I2,. . . , I8}, donde I1> I2>. . . > I8. Tanto el nivel de
confidencialidad como el nivel de integridad son números binarios de 3 bits, como se muestra en la
Tabla2.
 Tabla 2. Nivel secreto

Nivel de Nivel de Binari Nivel

confidencialidad integridad o secreto
C1 yo1 111 Nivel 1
C2 yo2 110 Nivel 2
C3 yo3 101 Nivel 3
C4 4 yo4 4 100 Nivel 4
C5 5 yo5 5 011 Nivel 5
C6 6 yo6 6 010 Nivel 6
C7 7 yo7 7 001 Nivel-7
C8 yo8 000 Nivel 8

PVMH tiene 16 categorías de seguridad o permisos de acceso. El conjunto de categorías de

seguridad se define como K = {K1, K2,. . . , K16}. La categoría de seguridad es un número binario de
16 bits, donde cada bit es un permiso de acceso específico. Cuando el bit i-ésimo de la izquierda se
establece en 1, el sujeto obtiene acceso al objeto en Ki
modo. Cuando se establece en 0, el sujeto pierde este acceso.

4.3. Implementación del modelo PVMH

Diseñamos la arquitectura PVMH de acuerdo con el módulo de control de seguridad de la
plataforma de computación en la nube, como se muestra en la Figura 1.

Figura 1. La arquitectura PVMH.

El sistema prototipo de marco PVMH se divide en dos partes, con la parte central en el
hipervisor y la otra parte en el sistema operativo host. El sistema operativo host tiene un módulo de
gestión de acceso. El hipervisor incluye un módulo de matriz de acceso, un módulo de control de
acceso (PVMH-ACM), un módulo de información PVMH y un módulo de decisión de acceso.

1. Módulo de administración de acceso: el módulo de administración de acceso se encuentra en el

sistema operativo host, que es la entrada para el administrador del sistema que administra
todo el módulo PVMH. Al crear una máquina virtual, el administrador puede establecer el
nivel de confidencialidad y el nivel de integridad de acuerdo con los requisitos específicos, y
administrar tanto la matriz de acceso como la estructura de información, de acuerdo con la
situación real.
2. Módulo de decisión de acceso: La tarea principal del módulo de decisión de acceso es verificar
la solicitud de acceso enviada por la máquina virtual, para determinar si el atributo de acceso
del PVMH
 el módulo está satisfecho y filtra las solicitudes que son ilegales o tienen datos maliciosos. Solo
se envían solicitudes legítimas al módulo PVMH-ACM.
3. Módulo de matriz de acceso: el módulo de matriz de acceso se encuentra en el administrador
de máquina virtual y almacena todas las matrices de acceso necesarias.
4. Módulo PVMH-ACM: El módulo PVMH-ACM es una implementación concreta de la interfaz
de función de enlace de seguridad proporcionada por el módulo de seguridad de Linux
(LSM). Además, este módulo implementa las funciones específicas del modelo PVMH.
5. Módulo de información PVMH: cada máquina virtual tiene su propia estructura de
información (información PVMH), que es responsable de registrar la información sobre la
ejecución de máquinas virtuales. La información incluye el número de identificación de la
máquina virtual, el nivel de confidencialidad, el nivel de integridad y la categoría de
seguridad, y el puntero a la entrada de la entrada de la lista de matriz de acceso y el conjunto
de acceso actual b (s), que se estableció gradualmente en El proceso desde el inicio de la
máquina virtual hasta su ejecución.
6. Módulo de seguridad de Linux (LSM): LSM es la base para implementar el módulo PVMH-
ACM. Cuando se inicia el sistema operativo subyacente, el LSM comienza a funcionar. Cuando
se llama a la función de enlace de seguridad correspondiente, se llama inmediatamente al
módulo de seguridad implementado por el usuario.

Cuando la máquina virtual emite una solicitud de acceso, el módulo PVMH-ACM determina si se
debe permitir el acceso al recurso de acuerdo con las reglas de control de acceso correspondientes.
El diagrama de flujo de control de acceso se muestra en la Figura2:

Figura 2. Diagrama de flujo de acceso. figura de alta resolución

De acuerdo con la arquitectura PVMH, el proceso de implementación específico es el siguiente:

 Paso 1: La máquina virtual en cuestión envía una solicitud para acceder a la máquina virtual
del objeto en un modo determinado. El módulo de Decisión de acceso intercepta estas solicitudes,
verifica si se ajustan a los atributos de acceso del módulo PVMH, filtra directamente las solicitudes
de datos ilegales o maliciosas, devuelve "Error" y envía las solicitudes que se ajustan a los atributos
de acceso al módulo PVMH-ACM en hipervisor.
Paso 2: El módulo PVMH-ACM consulta en la matriz de acceso y la información PVMH
resolviendo el mensaje entrante y toma decisiones de acuerdo con las reglas de transición de estado.
Específicamente, toma como ejemplo que la máquina virtual (SID) del sujeto accede a la
máquina virtual (OID) del objeto en modo de solo lectura (R).

(1) El módulo PVMH-ACM consulta el conjunto de acceso actual b (S) de la máquina virtual en
cuestión desde el módulo de información PVMH. Si encuentra el par de destino (OID, R), el
módulo PVMH-ACM acepta la solicitud y devuelve "sí" directamente; de lo contrario, salta a
(2) para continuar.
(2) Todos los elementos de la matriz de acceso asociados con SID y OID se almacenan en una lista
vinculada. El módulo PVMH-ACM busca en la lista vinculada desde el nodo principal. Si
encuentra la tupla objetivo (SID, OID, 1XXX) (X es 0 o 1), salta a (3) para una decisión adicional;
de lo contrario, rechaza la solicitud y devuelve "no" directamente.
(3) El módulo PVMH-ACM encuentra la información de la máquina virtual del objeto en el
módulo de información PVMH y compara el nivel de confidencialidad de la máquina virtual
del sujeto con el de la máquina virtual del objeto. Si se cumple la regla PVMH - R1, el PVMH-
ACM devuelve "sí"
como resultado de una decisión y agrega el par de valores (OID, R) en el conjunto de acceso
actual b (S); de otra manera,
rechaza la solicitud y devuelve "no".

Todo el proceso de acceso se almacena en el módulo de información PVMH, y cuando se repita el

mismo acceso en el futuro, el módulo de control de acceso PVMH-ACM generará directamente el
resultado, en lugar de hacer coincidir el nivel de seguridad del sujeto y el objeto y otra información.
Paso 3: El módulo PVMH-ACM envía el resultado de la decisión al módulo LSM. Si el módulo
PVMH-ACM emite “sí”, el módulo LSM permite que la máquina virtual en cuestión acceda a la
máquina virtual del objeto y realiza el control de acceso de seguridad de acuerdo con la función de
enlace específica; de lo contrario, se rechaza el acceso.

5. Los experimentos

5.1. Ambiente Básico

El experimento se realiza en una PC Dell con la siguiente configuración, como se muestra en la
Tabla 3.

Tabla 3. Parámetros de hardware.

HardwareParameter
CPU Intel Core i7-6700, 3.4 GHz Memoria
8GB
Difícil disco1TB

En este experimento, Xen se usa como la plataforma de nube privada impulsada por el entorno
de virtualización, y la herramienta "virt-manager" se usa para administrar máquinas virtuales. Por
conveniencia, el sistema operativo host está configurado con la interfaz gráfica, y dado que la
máquina virtual solo requiere un entorno básico, la interfaz gráfica se elimina del sistema operativo
invitado. Los detalles se muestran en la tabla4 4.
 Tabla 4. Entorno del sistema operativo.

Máquina Versión del Versión del núcleo Interfaz gráfica

sistema
Máquina host Ubuntu 16.04.5 4.15.0-42-genérico si
Máquina virtual CentOS-6.10 4.4.163-1.el6.elrepo.i686 No
Hipervisor Xen N/A xen-hypervisor-4.6-amd64 N/A

5.2. La inicialización del módulo PVMH

El módulo PVMH debe inicializarse antes de que pueda ejecutarse. Después de la
inicialización, los atributos de acceso legal se almacenan en el módulo de Decisión de acceso, y la
matriz de acceso inicial se almacena en el módulo de Matriz de acceso. El administrador del sistema
puede modificar la matriz de acceso de acuerdo con la solicitud de acceso en cualquier momento.
El módulo PVMH-ACM registra su función de inicialización a través de la interfaz
proporcionada por el módulo de seguridad de Linux LSM, que se llama durante la inicialización de
LSM. La función de inicialización carga la matriz de acceso en el espacio de direcciones de memoria
del hipervisor. En función de la consideración de uso eficiente de la memoria, como buscar, agregar
o eliminar elementos, se utiliza una lista enlazada bidireccional ordenada. Además, la función de
inicialización PVMH-ACM proporciona al LSM información sobre las funciones de enlace de
seguridad. El módulo PVMH-ACM se ejecuta en uno de estos dos modos: control de acceso
obligatorio o control de acceso discrecional, que depende de la información de acceso devuelta
desde el módulo de decisión de acceso. El módulo de información PVMH registra la información de
cada máquina virtual. La información PVMH es una lista enlazada bidireccional en Hypervisor, y
cada nodo contiene la información relevante de una máquina virtual en ejecución específica, que
incluye el número de ID de seguridad, el nivel de confidencialidad, el nivel de integridad, la
categoría de seguridad y los punteros a la entrada de la lista vinculada a la matriz de acceso y el
conjunto de acceso actual b (s). Después de la inicialización, solo existe una tabla vacía en el módulo
de información PVMH. Cuando se inicia una determinada máquina virtual, se asignan el número de
identificación de seguridad correspondiente, el nivel de confidencialidad, el nivel de integridad y la
categoría de seguridad. El módulo de información PVMH lee estos cuatro elementos y se guardan
en la lista enlazada bidireccional, que forma los primeros cuatro elementos de esta máquina virtual.
y los punteros a la entrada de la lista vinculada a la matriz de acceso y al conjunto de acceso actual b
(s). Después de la inicialización, solo existe una tabla vacía en el módulo de información PVMH.
Cuando se inicia una determinada máquina virtual, se asignan el número de identificación de
seguridad correspondiente, el nivel de confidencialidad, el nivel de integridad y la categoría de
seguridad. El módulo de información PVMH lee estos cuatro elementos y se guardan en la lista
enlazada bidireccional, que forma los primeros cuatro elementos de esta máquina virtual. y los
punteros a la entrada de la lista vinculada a la matriz de acceso y al conjunto de acceso actual b (s).
Después de la inicialización, solo existe una tabla vacía en el módulo de información PVMH.
Cuando se inicia una determinada máquina virtual, se asignan el número de identificación de
seguridad correspondiente, el nivel de confidencialidad, el nivel de integridad y la categoría de
seguridad. El módulo de información PVMH lee estos cuatro elementos y se guardan en la lista
enlazada bidireccional, que forma los primeros cuatro elementos de esta máquina virtual.

5.3. Experimentos y resultados

Hay muchos casos de ataques de salto de máquina virtual. Aquí se seleccionaron dos de los
posibles escenarios de ataques de salto de máquina virtual para verificar el papel del módulo
PVMH.
Escenario de ataque 1: Ataques de salto de máquinas virtuales entre máquinas virtuales debido
a la comunicación de memoria compartida. La comunicación típica a través de la memoria
compartida es la siguiente: VM1 crea memoria compartida y transfiere su referencia de concesión a
las máquinas virtuales VM2 y VM3; VM2 y VM3 asignan respectivamente las páginas de memoria
autorizadas a sus respectivos espacios de direcciones; Mediante la asignación de direcciones, VM2 y
VM3 pueden leer o escribir la página compartida, ya que está exactamente en su propia dirección de
memoria. Cuando VM2 y VM3 han terminado de acceder a esta memoria compartida, revocan la
dirección de la página de memoria. Por fin, VM1 revoca la autorización y reclama la referencia de
concesión. En el experimento, la comunicación de memoria compartida se implementa mediante un
núcleo dinámico.
Resultado esperado: después de que se inicia el módulo PVMH, si VM2 y VM3 no satisfacen
las reglas de control de acceso, la memoria compartida no se puede usar, por lo tanto, el núcleo
dinámico falla y no se puede insertar en VM2 y VM3.
Cree máquinas virtuales con la herramienta virt-manager, como se muestra en la Figura 3.

Figura 3. Crea VM1.

Después de la creación, enumere todas las máquinas virtuales en ejecución, como se muestra en
la Figura 4 4.
 Figura 4. Comando que enumera todas las máquinas virtuales en ejecución.

El nivel de seguridad y la categoría de las máquinas virtuales se dan en la

Tabla 5 5.

Tabla 5. Configuración de seguridad de VM1, VM2 y VM3.

Sujeto objeto SID = OID = ID Nivel de Nivel de Categoría de

confidencialidad integridad seguridad
VM1 0000 0000 0000 1 C1(111) yo2(110) 0011 0100 1000 1010
VM2 0000 0000 0001 0 C3(101) yo5 5(011) 0000 1011 1001 0110
VM3 0000 0000 0001 1 C5 5(100) yo5 5(011) 0010 1011 1010 0011

Obviamente, VM1> VM2> VM3 cuando se compara la confidencialidad y VM1> VM2 = VM3
cuando se trata de integridad. Sin PVMH, VM1, VM2 y VM3 pueden acceder entre sí. Sin embargo,
después de configurar PVMH, VM1 puede acceder a VM2 y VM3, mientras que VM2 y VM3 no
pueden acceder a VM1.
La matriz de acceso se da en la tabla 6 6.

Tabla 6. Matriz de acceso de VM1, VM2 y VM3.

Acceso Atributo
Sujeto objeto SID = OID Bandera
R UNA W
VM1 0000 0000 0000 1 1 1 1 1
VM2 0000 0000 0001 0 00 00 00 1
VM3 0000 0000 0001 1 00 00 00 00

La memoria compartida se crea en VM1 y se imprime el registro de claves, como se muestra en

la Figura 5 5.

Figura 5. Crear memoria compartida en VM1.

La función del núcleo en VM1: Primero tome una página física de tamaño 4K; luego escriba
"Hola, por DY en DOM # 1" en esta página; la dirección de memoria inicial es 0xdb566000 en el
espacio de direcciones de VM1; luego autorice de acuerdo con el número de identificación de VM2 y
VM3 y devuelva el identificador de referencia de concesión correspondiente, que es 797 para VM2 y
798 para VM3.
Según el número de identificación de VM1 y el identificador de referencia de concesión
mencionado anteriormente, la memoria compartida se referencia en la VM2 a través del núcleo
dinámico. Sin PVMH, VM2 lee con éxito la información compartida escrita por VM1, como se
muestra en la Figura6 6.
Figura 6 Consulte la memoria compartida en VM2, sin el módulo PVMH.
 La función del núcleo en VM2: Primero, el tamaño de 4K se divide del espacio de direcciones
para mapear la página compartida. Luego, VM2 asigna la página compartida a su propio espacio de
direcciones de acuerdo con el número de ID de VM1 y el identificador de referencia de concesión;
en VM2, la dirección inicial de esta página asignada es 0xe19c0000; después de eso, la información
"Hola, por DY en DOM # 1" escrita por VM1 se puede leer y se completa el acceso.
Para verificar la función del módulo PVMH, el núcleo dinámico debe ser eliminado de VM2 al
principio, luego el módulo PVMH habilitado y el núcleo dinámico reinsertado en VM2, como se
muestra en las Figuras 7 7 y 8 respectivamente.

Figura 7 Habilite el módulo PVMH.

Figura 8. Consulte la memoria compartida en VM2, con PVMH habilitado.

Después de iniciar el módulo PVMH, VM2 pierde su permiso para acceder a la memoria
compartida, lo que resulta en la falla de la inserción dinámica del núcleo. Se pueden observar
resultados similares en VM3 con y sin el módulo PVMH. Esto es consistente con las reglas PVMH,
porque VM2 tiene una confidencialidad y una integridad más bajas que VM1.
Escenario de ataque 2: El atacante usa el VM4 para montar y modificar la partición / boot de
VM5 a través del hipervisor. Como resultado, VM5 no se puede iniciar, lo que provoca el ataque de
salto de máquina virtual. Resultado esperado: después de iniciar el módulo PVMH, si no se cumple
la regla de control de acceso,
VM4 no puede acceder a la partición / boot de VM5, incluso utilizando la máquina virtual
privilegiada Dom0.
Establezca el nivel de seguridad y la categoría de VM4 y VM5, como se muestra en la Tabla 7 7.

Tabla 7. Configuración de seguridad de VM4 y VM5.

Sujeto objeto SID = OID = ID Nivel de Nivel de Categoría de

confidencialidad integridad seguridad
VM4 0000 0000 0010 0 C4 4(100) yo6 6(010) 0011 0000 1010 1000
VM5 0000 0000 0010 1 C3(101) yo5 5(011) 0000 0011 1001 1000

Obviamente, VM4 <VM5 al comparar tanto la confidencialidad como la integridad. Sin PVMH,
VM4 puede montar la partición / boot de VM5 a través de Dom0. Sin embargo, después de que se
inicia PVMH, VM4 ya no puede acceder a VM5.
La matriz de acceso se da en la tabla 8.

Tabla 8. Matriz de acceso de VM4 y VM5.

Acceso Atributo
Sujeto objeto SID = OID Bandera
R UNA W
VM4 0000 0000 0010 0 1 00 1 1
VM5 0000 0000 0010 1 1 00 00 1
 VM4 usa la máquina virtual privilegiada Dom0 para ver la partición de VM5, como se muestra
en la Figura 9.

Figura 9 Partición de VM5.

El disco de VM5 se divide en dos particiones: / y / boot. Antes de habilitar el módulo PVMH,
VM4 monta y accede a la partición / boot de VM5 a través de Dom0. El valor "Inicio" de la
partición / arranque, 2048, se utiliza para calcular el desplazamiento en el montaje del comando,
como se muestra en la Figura10:

Figura 10 Monte y vea la partición / boot de VM5, sin PVMH.

Dado que VM4 puede modificar la partición / boot de VM5, puede atacar VM5 fácilmente.
Desmonte la partición, habilite el módulo PVMH y vuelva a montar la partición / boot de VM5. Los
resultados son como se muestran en la Figura11.

Figura 11 Monte y vea la partición / boot de VM5, con PVMH habilitado.

Después de habilitar el módulo PVMH, VM4 no puede montar la partición / boot de VM5.
Cabe señalar que la operación de montaje corresponde a una serie de llamadas al sistema Linux. En
nuestra implementación, después de la intercepción del módulo PVMH, afecta la entrada de
llamadas posteriores del sistema, por lo que el mensaje de error es "No existe tal archivo o
directorio".
A través de estos dos experimentos de escenarios específicos, se puede ver que el módulo
PVMH ha desempeñado un papel en la prevención de ataques de salto de máquina virtual. Además
de los resultados experimentales anteriores, se requieren pruebas de costo de rendimiento de
PVMH para comprender el impacto de integrar PVMH en la plataforma de virtualización original.
Experimento de gastos generales de rendimiento: tomando el escenario de ataque 1 como
ejemplo, el paso más crítico y lento en la comunicación de memoria compartida es generar una
interrupción del sistema a través de la función HYPERVISOR_grant_table_op, y luego llamar a un
conjunto de hipercalls. Antes y después de
El módulo PVMH está habilitado, el tiempo real de la llamada de función se prueba por separado
para medir el impacto en el rendimiento del módulo PVMH en la plataforma de virtualización
original.
Como se muestra en la figura 12, sin el módulo PVMH, se necesitan 853 microsegundos para
llamar a un conjunto de hipercalls a través de HYPERVISOR_grant_table_op. Después de cargar el
módulo PVMH, el tiempo promedio es de 932 microsegundos, lo que resulta en una pérdida de
tiempo adicional del 9%.
1,000

900 932
800 853
Tiempo (Unidad: ms)

700

600
sin PVMH
500 con PVMH

400

300

200

100

00
Figura 12 Rendimiento con y sin el módulo PVMH.

Del análisis anterior se puede ver que el módulo PVMH puede prevenir efectivamente el
problema de salto de máquina virtual en el entorno de computación en la nube sin reducir
significativamente el rendimiento del sistema.

6. Conclusiones
Al analizar los resultados experimentales anteriores, queda claro que PVMH puede prevenir
eficazmente los ataques de salto de máquinas virtuales y garantizar la seguridad entre diferentes
máquinas virtuales en el mismo host. Como el módulo PVMH necesita llamar a la función del
sistema cuando se está ejecutando, consume una cierta cantidad de rendimiento del sistema, pero
para el efecto general, la pérdida adicional está dentro de un rango aceptable.
En futuras investigaciones, las reglas de seguridad de PVMH podrían simplificarse aún más,
haciendo que el modelo PVMH sea más adecuado para prevenir ataques de salto de máquinas
virtuales. Además, necesitamos fortalecer la conexión entre el módulo PVMH y el módulo LSM, lo
que podría reducir la carga de trabajo y lograr mejores efectos preventivos.

Contribuciones de autor: Ying Dong y Zhou Lei concibieron y diseñaron el modelo PVMH; Ying Dong realizó
los experimentos y escribió el artículo; Zhou Lei revisó el documento.
Fondos: Esta investigación no recibió fondos externos.
Conflictos de interés: Los autores declaran no tener ningún conflicto de intereses.

Referencias
1. GRAMOulati, GRAMO. Multiinquilino Arquitectura. En UNA Nube privada ;
REGAZO Lambert Académico Editorial: Saarbrücken, Alemania, 2012.
2. Dean, J .; Ghemawat, S. MapReduce: una herramienta de procesamiento de datos flexible. Commun. ACM
2010, 53, 72–77. [CrossRef]
3. DeCandia, G .; Hastorun, D .; Jampani, M .; Kakulapati, G .; Lakshman, A .; Pilchin, A .; Sivasubramanian,
S .; Vosshall, P .; Vogels, W. Dynamo: la tienda de valor-clave altamente disponible de Amazon. En las
actas del vigésimo primer simposio SIGOPS de ACM sobre principios de sistemas operativos (SOSP'07),
Stevenson, WA, EE. UU.,14-17 de octubre de 2007; ACM: Nueva York, NY, EE. UU., 2007; pp. 205–220.
4. Catteddu, D .; Hogben, G. Cloud Computing: beneficios, riesgos y recomendaciones para la seguridad de
la información. En Actas de la Conferencia de Seguridad de Aplicaciones Web Ibéricas 2009, Madrid,
España, 10-11 de diciembre de 2009; Springer: Berlín Heidelberg, 2010.
5. Ormandy, T. Un estudio empírico sobre la exposición de seguridad a hosts de entornos hostiles
virtualizados. En Actas de la Conferencia de Seguridad Aplicada CanSecWest, Vancouver, Canadá, 18 de
marzo de 2007; pp. 1-18.
6. Modi, CN; Acha, K. Retos de seguridad de la capa de virtualización y sistemas de detección / prevención
de intrusos en computación en la nube: una revisión exhaustiva. J. Supercomput. 2017, 73, 1192–1234.
[CrossRef]
7. Bahías, LR; Oliveira, RR; Barcellos, MP; Gaspary, LP; Madeira, ER Seguridad de red virtual:
amenazas,contramedidas y desafíos. J. Internet Serv. Appl. 2015, 6, 1. [CrossRef]
8. Nathiya, T .; Suseendran, G. Un sistema de detección de intrusiones híbrido eficaz para su uso en el
monitoreo de seguridad en la capa de red virtual de la tecnología de computación en la nube. En Gestión
de Datos, Análisis e Innovación. Avances en Sistemas Inteligentes y Computación; Balas, V., Sharma, N.,
Chakrabarti, A., Eds .; Saltador:Singapur, 2019; Volumen 839.
9. Pan, W .; Zhang, Y .; Yu, M .; Jing, J. Mejora de la seguridad de virtualización al dividir el hipervisor en
componentes más pequeños. En la Conferencia Anual IFIP sobre Seguridad y Privacidad de Datos y
Aplicaciones, París, Francia, del 11 al 13 de julio de 2012. Notas de la conferencia en Ciencias de la
Computación (incluidas las Notas de la Subserie en Inteligencia artificial y Conferencia Notas en
bioinformática); Springer Nature: Basilea, Suiza, 2012; Volumen 7371, págs. 298-313.
10. Wu, J .; Lei, Z .; Chen, S .; Shen, W. Un modelo de control de acceso para prevenir el ataque de escape de
máquina virtual.
Internet futuro 2017, 9, 20. [CrossRef]
11. Nguyen, SD; Mimura, M .; Tanaka, H. Abusando de la retransmisión TCP para el ataque DoS dentro de la
red virtual. En aplicaciones de seguridad de la información. WISA 2017; Apuntes de Lectura en
Informática; Kang, B., Kim, T., Eds .;Springer: Cham, Suiza, 2018; Volumen 10763.
12. Rakotondravony, N .; Taubmann, B .; Mandarawi, W .; Weishäupl, E .; Xu, P .; Kolosnjaji, B .; Protsenko, M .; De Meer,
H .;Reiser, HP Clasificando ataques de malware en entornos de nube IaaS. J. Cloud Comput. 2017, 6, 26.
[CrossRef]
13. Mthunzi, SN; Benkhelifa, E .; Alsmirat, MA; Jararweh, Y. Análisis de la comunicación VM para sistemas
de seguridad en la nube basados en VM. En Actas de la Quinta Conferencia Internacional de 2018 sobre
software definidoSystems (SDS), Barcelona, España, 23–26 de abril de 2018; pp. 182-188.
14. Dicho, TA; Rana, OF Análisis de seguridad de máquinas virtuales en sistemas en la nube. En actas de la
Conferencia internacional sobre computación inteligente en la nube, Muscat, Omán, 24–26 de febrero de
2014.
15. Ren, X .; Zhou, Y. Una revisión del ataque de máquina virtual basada en Xen. En Actas de la Internacional
Seminario sobre física aplicada, optoelectrónica y fotónica (APOP 2016), Shanghai, China, 28-29 de mayo
de 2016.
16. Elmrabet, Z .; Elghazi, H .; Sadiki, T .; Elghazi, H. Una nueva arquitectura de red segura para aumentar la
seguridad entre máquinas virtuales en la computación en la nube. En avances en redes ubicuas; Notas de
clase enIngenieria Eléctrica; Sabir, E., Medromi, H., Sadik, M., Eds .; Springer: Singapur, 2016; Tomo 366.
17. Sathya Narayana, K .; Pasupuleti, SK Modelo de confianza para la seguridad de máquinas virtuales en
Cloud Computing. En curso en informática, análisis y redes. Avances en Sistemas Inteligentes y
Computación; Pattnaik, P., Rautaray S., Das, H., Nayak, J., Eds .; Springer: Singapur, 2018; Volumen 710.
18. Bazm, M.-M .; Sautereau, T .; Lacoste, M .; Südholt, M .; Menaud, J.-M. Detección de ataques de canal
lateral basados en caché a través de la tecnología de monitoreo de caché Intel y contadores de
rendimiento de hardware. En las Actas de la Tercera Conferencia Internacional IEEE sobre Niebla y
Mobile Edge Computing (FMEC 2018), Barcelona,España, 23–26 de abril de 2018; pp. 1-6.
19. Silva, EF; Muchaluat-Saade, DC; Fernandes, NC ACROSS: un marco genérico para el control de acceso
basado en atributos con políticas distribuidas para organizaciones virtuales. Futuro Gener. Comput Syst.
2017, 78, 1–7. [CrossRef]
20. Graham, GS; Denning, Protección PJ: Principios y práctica. En las actas de la computadora conjunta
SpringConferencia (AFIPS '72), Atlantic City, NJ, EE. UU., 16-18 de mayo de 1972; ACM: Nueva York, NY, EE. UU.,
1972; págs. 417–429.
21. Bell, DE; La Padula, LJ Secure Computer System: Exposición unificada e interpretación de multics;
 Documento DTIC; Mitre Corp .: Bedford, MA, EE. UU., 1976.
22. Sandhu, RS Modelos de control de acceso basados en roles. Computer 1996, 29, 38–47. [CrossRef]
23. Jha, S .; Sural, S .; Atluri, V .; Vaidya, J. Especificación y verificación de separación de restricciones de
servicio enControl de acceso basado en atributos. IEEE Trans. Inf. Forense Secur. 2018, 13, 897–911.
[CrossRef]
24. Bell, DE; La Padula, LJ Sistemas informáticos seguros: fundamentos matemáticos; Informe técnico MTR-
2457; Mitre Corporation: McLean, VA, EE. UU., 1973.
25. Biba, KJ Consideraciones de integridad para un sistema informático seguro; ESD-76-372; División de
Sistema Electrónico PSAF, Base de la Fuerza Aérea Hanscom: Bedford, MA, EE. UU., 1977.

© 2019 por los autores. Licenciatario MDPI, Basilea, Suiza. Este artículo es un artículo
de acceso abierto distribuido bajo los términos y condiciones de la licencia Creative
Commons Attribution (CC BY)(http://creativecommons.org/licenses/by/4.0/)