Control Acceso

Seguridad Inform atica
Control de acceso
Ram on Hermoso y Matteo Vasirani
Grado en Ingeniera Inform atica
Identicaci on y autenticaci on Control de acceso Autenticaci on y control de acceso en Unix Control de acceso en Java Aislamiento de c odigo
1
Identicaci on y autenticaci on
2
Control de acceso
3
Autenticaci on y control de acceso en Unix
4
Control de acceso en Java
5
Aislamiento de c odigo
1
2
Control de acceso
3
4
5
En un sistema seguro se necesita trazar la identidad de
los usuarios que necesitan servicios y acceso a datos
La autenticaci on es el proceso de vericar la identidad
de un usuario
Dos razones para autenticar un usuarios:
La identidad de un usuario es necesaria para las
decisiones de control de acceso
La identidad de un usuario se almacena en los logs para
tener traza de los eventos relevantes
Identicaci on y Autenticaci on
Todos hemos interactuado con un sistema software (SO,
cuenta email, etc.) que nos pide digitar usuario y
contrase na
El primer paso se llama identicaci on: anunciamos
qui enes somos
El segundo paso se llama autenticaci on: damos prueba
que de verdad somos qui en decimos que somos
El sistema compara nuestro input con los datos
contenidos en una base de datos o en un chero
(password le), y si usuario y contrase na son correctos el
sistema nos permite acceder a el
El autenticaci on puede ocurrir de manera repetida a lo
largo de la sesi on, para evitar que un atacante se
aproveche de una sesi on huerfana
TOCTTOU:Time of Check to Time of Use
La autenticaci on repetida sirve para tratar el problema conocido
como TOCTTOU. El sistema comprueba (check) la identidad al
principio de la sesi on pero utiliza (use) esta informaci on m as
tarde para tomar decisiones de control de acceso.
La identicaci on y autenticaci on es la primera lnea de
defensa de un sistema software, y ya es parte de la rutina
de cualquier usuario
Sin embargo, mantener la seguridad de la contrase na es
un serio problema de seguridad
1
El administrador del sistema tiene que asegurarse que
nadie pueda tener acceso no autorizado a los datos
relativos a las contrase nas
2
El usuario tiene que colaborar, eligiendo una contrase na
robusta
Hay varios problemas de seguridad relacionados con las
contrase nas, ya que un atacante podra:
1
Interceptar la contrase na cuando se crea una cuenta
nueva (p.e. keylogger )
2
Adivinar la contrase na
3
Robar la contrase na (phishing, ingeniera social...)
4
Obtener la contrase na comprometiendo el chero de
contrase nas
Tipos de ataques
1
Fuerza bruta: intentar todas las posibles combinaciones de
caracteres, hasta una cierta longitud
2
B usqueda inteligente: intentar contrase nas asociadas con
el usuario (p.e., fecha de nacimiento, nombre del perro etc.)
3
Diccionario: usar un conjunto de palabras comunes
Las defensas
1
Cambiar la contrase na por defecto
2
Usar contrase nas de 8 dgitos (como mnimo)
Un supercomputer tarda m as de 600.000 millones de a nos
en romper una contrase na de 20 dgitos
Si el sistema es accesible s olo fsicamente, una contrase na
en blanco es m as ecaz que 12345 o abc123
3
Mezclar may usculas, min usculas, caracteres especiales
La realidad (seg un un estudio de Imperva
1
):
Las contrase nas m as usadas son 123456, 12345,
123456789 y Password
Casi el 50% de los usuarios usa como contrase na
nombres, palabras de diccionario o combinaciones triviales
de caracteres
El 20% de las cuentas se pueden crackear en menos de
5000 intentos
Casi el 50% de las contrase nas tienen 7 caracteres o
menos, y m as del 30% tienen 6 caracteres o menos.
1
http://www.imperva.com/ld/password report.asp
1
2
Control de acceso
3
4
5
Control de acceso
Una vez identicado y autenticado, un usuario se
encuentra dentro del sistema
Es necesario denir una poltica de control de acceso a
los recursos del sistema
Qui en puede leer el chero foo.txt?
Qui en no puede escribir el chero bar.txt?
Qu e programas puede ejecutar el usuario pepe?
...
Terminologa
Un sujeto quiere acceder a un objeto a trav es de una
cierta operaci on, supervisada por un monitor de
referencia que media la operaci on entre sujeto y objeto
Sujeto: usuario, proceso . . .
Objeto: chero, memoria, dispositivo hardware . . .
Operaci on: leer, escribir, ejecutar, borrar, adjuntar . . .
Clasicaci on
Control de acceso discrecional (DAC)
La poltica de control de acceso es determinada por el
propietario del objeto
El propietario decide qu e permisos se asignan a qui en
Normalmente el propietario de un objeto es el usuario que
lo crea
Control de acceso obligatorio (MAC)
La poltica de control de acceso es determinada por el
sistema, y no por el propietario del objeto
Se clasican sujetos y objetos en niveles de seguridad.
Poco usado en sistemas software
Matriz de control de acceso
S: conjunto de sujetos
O: conjunto de objetos
A: conjunto de operaciones de acceso
M = (M
s,o
)
sS,oO
, M
s,o
A

Ejemplo
S ={pepe, paco, luis}
O ={bar.txt, foo.exe}
A ={r = read, x = execute, d = delete}
M =
bar.txt foo.exe
pepe {r}
paco {x, d}
luis {r, d} {x}
Ejemplo
S ={inc bal, dec bal, reset}
O ={balance, account}
A ={, , }
M =
balance account
inc bal {}
dec bal {}
reset {} {}
Puede ser muy grande en sistemas con muchos usuarios
y muchos recursos
Es un concepto abstracto, raramente se implementa
directamente
Posibles implementaciones:
1
Lista de control de acceso (ACL)
Una lista por cada objeto. Indica las operaciones que cada
sujeto puede hacer.
2
Lista de capacidades
Una lista por cada sujeto. Indica las operaciones que puede
hacer sobre cada objeto
ACL vs capacidades
A: conjunto de de operaciones de acceso
L
o
={(s, ) | s S, A} o O

Lista de control de acceso
Ejemplo:
L
bar.txt
={ (pepe, {r}), (paco, ), (luis, {r, d}) }
L
foo.exe
={ (pepe, ), (paco, {x, d}), (luis, {x}) }
Ventajas:
Es f acil ver los permisos de acceso de un determinado
objeto
Es f acil revocar todos los permisos sobre un objeto,
poniendo L
o
={}
Es f acil eliminar los permisos asociados a un objeto que ya
no existe, eliminando L
o
Desventajas:
Comprobar los permisos de acceso de un determinado
sujeto
Uso:
Se suele implementar en sistemas orientados a la gesti on
del acceso a recursos, como en los sistemas operativos
A: conjunto de de operaciones de acceso
L
s
={(o, ) | o O, A} s S

Ejemplo:
L
pepe
={ (bar.txt, {r}), (foo.exe, ) }
L
paco
={ (bar.txt, ), (foo.exe, {x, d}) }
L
luis
={ (bar.txt, {r, d}), (foo.exe, {x}) }
Ventajas:
Es f acil comprobar todos los permisos de un sujeto
Es f acil revocar todos los permisos de un sujeto, poniendo
L
s
={}
Es f acil eliminar los permisos asociados a un sujeto que ya
no existe, eliminando L
s
Desventajas:
Comprobar los permisos de acceso sobre un determinado
objeto
Uso:
Se suele implementar en sistemas orientados a los
usuarios, como las bases de datos o los sistemas
distribuidos
M etodos de agregaci on
Grupos
Los operaciones de acceso se pueden denir para un
determinado grupo de sujetos
Asignando un grupo a un sujeto, este hereda las
operaciones de acceso denidas para el grupo
Ejemplo:
Crear el grupo mail
Denir que los sujetos del grupo mail pueden acceder al
servidor smtp
A nadir el usuario pepe al grupo mail
M etodos de agregaci on
Roles
Las operaciones de acceso se agrupan en roles
A cada sujeto se le asigna uno o m as roles
Los roles se estructuran de manera jer arquica
Ejemplo:
Operaciones:
depositar, retirar

Rol: Empleado
, traspasar

Rol: Supervisor
,crear cuenta

Rol: Administrador
Taxonoma: Administrador Supervisor Empleado
Si a pepe se le asigna el rol Administrador, podr a ejecutar
todas las operaciones
Si a paco se le asigna el rol Empleado, s olo
podr a depositar o retirar dinero de una cuenta
1
2
Control de acceso
3
4
5
Usuarios
Cada usuario est a identicado por un username y un user
ID (UID)
Existe un usuario, root, que tiene privilegios especiales de
administraci on (super user ), cuyo UID es 0
Unix no es capaz de distinguir dos usuarios con el mismo
UID
El usuario root puede hacer pr acticamente cualquier cosa,
por lo tanto es el punto m as debil de un sistema Unix
Casi todos los ataques se reducen a conseguir ser root !!!
Grupos
Un grupo est a identicado por un group name y un group
ID (GID)
Cada usuario puede pertenecer a uno (primary group) o
m as grupos
El usuario root pertenece al grupo root, cuyo GID es 0
/etc/passwd
Los datos de autenticaci on de un usuario est an
almacenados en el chero /etc/passwd, en el formato:
username:encrypted pwd:user ID:group ID:ID:home dir:login shell
Ejemplo:
root:a5ZHb29w:0:0:Administrator:/home/root:/bin/bash
pepe:hgf5D3Ws:1002:1002:Pepe:/home/pepe:/bin/bash
Todos los usuarios pueden leer el chero /etc/passwd,
pero solo root puede modicarlo. Por qu e?
Qu e pasa si pepe modica el chero /etc/passwd de
esta manera?
root:a5ZHb29w:0:0:Administrator:/home/root:/bin/bash
pepe:hgf5D3Ws:0:0:Pepe:/home/pepe:/bin/bash
/etc/shadow
La contrase na que aparece en el chero /etc/passwd
est a cifrada. Sin embargo, hay problemas de seguridad.
Por qu e?
En las versiones m as recientes, el chero /etc/passwd
es algo as
root:
*
:0:0:Administrator:/home/root:/bin/bash
pepe:
*
:1002:1002:Pepe:/home/pepe:/bin/bash
La password cifrada est a en otro chero, /etc/shadow,
que s olo root puede leer y modicar
Set UserID y Set GroupID
Si s olo root puede leer el chero /etc/shadow o
modicar el chero /etc/passwd, c omo puede un
usuario no privilegiado autenticarse en el SO o modicar
su password?
Los programas Set UserID (SUID) y Set GroupID (SGID)
permiten a un usuario adoptar temporalmente el UID o el
GID del propietario del programa a lo largo de su ejecuci on
Ejemplos de programas SUID cuyo propietario es root :
/usr/bin/passwd: cambiar password
/usr/bin/login: autenticarse en el SO
Cuando pepe ejecuta un programa SUID de root, hereda
todos los privilegios de root !!!
Permisos
Objeto
chero
inode
Permisos
Permisos
Los permisos de acceso est an agrupados en tres
tripletas, que representan las operaciones permitidas al
propietario del chero, a los usuarios del grupo al cual
pertenece el chero, y a todos los dem as usuarios
Para los ejecutables SUID, aparece una s en vez de una x
El monitor de referencia concede el acceso comprobando
los permisos de la siguiente manera
if usuario.UID == inode.uid then
comprueba permisos user
else if usuario.GID == inode.gid then
comprueba permisos group
else
comprueba permisos others
end if
Qu e pasa si los permisos son ------rwx ???
Permisos
El propietario de un chero (y obviamente root ) puede
cambiar los permisos de acceso usando el comando
chmod
Ejemplos:
chmod [ugo][+-][rwx] file
asignar o quitar (+-) los permisos de lectura/escritura
/ejecuci on (rwx) al propietario/grupo/otros (ugo)
chmod [ugo][+-][rws] file
asignar o quitar (+-) los permisos de lectura/escritura
/ejecuci on SUID (rws) al propietario/grupo/otros (ugo)
chmod [+-][t] dir
asignar o quitar (+-) el sticky bit (t) al directorio. Con el
sticky bit, s olo el propietario puede borrar/renombrar los
cheros contenidos en el directorio
chmod perm file
especicar los permisos con un n umero octal (perm)
Permisos
chmod 660 file = rw-rw----
chmod 777 file = rwxrwxrwx
chmod 744 file = rwxr--r--
chmod 500 file = r-x------
1
2
Control de acceso
3
4
5
Los sujetos en Java son las clases
Java dene mecanismos de accesibilidad a las clases y a
las variables y m etodos de estas
Ejemplo:
public class MyClass{
private int age;
String name;
...
protected void setAge(int a){
age = a;
}
}
Existen 4 niveles de acceso
public
protected
package-private (ning un modicador explcito)
private
Las clases pueden declararse public o package-private
Variables miembros y m etodos pueden declararse public,
protected, package-private o private
Modicador Clase Paquete Subclase Otras clases
public

protected

ninguno

private

SamePackClass puede acceder a la variable age de MyClass?
MyClass puede acceder a la variable root de SamePackClass?
SubOfMyClass puede acceder a la variable name de MyClass?
OtherClass puede acceder a la variable series de
SamePackClass?
1
2
Control de acceso
3
4
5
A veces, ejecutar una poltica de control de acceso no es
suciente
Ejemplo
Probar software no seguro
Acceso a usuarios desconocidos (ftp)
Soluci on: aislamiento de c odigo
Construir una prisi on de manera que un proceso no
pueda ver los recursos que est an fuera
chroot
m aquinas virtuales (VirtualBox, VMWare)
chroot
Para limitar el acceso a los recursos, se cambia el
directorio raz
Ejemplo
chroot(/tmp)
Si se intenta acceder a /etc/shadow, en realidad se
est a intentando acceder a /tmp/etc/shadow
Ventajas:
El proceso no puede escapar de la prisi on
Desventajas:
Hay que copiar todos los comandos y libreras necesarias
(/bin/ls, /bin/cp)
chroot
Solamente root puede ejecutar chroot
En caso contrario, cualquier usuario puede escalar
privilegios
Ejemplo
Crear un chero /tmp/etc/passwd con los datos de un
usuario fakeroot con UID=0
Ejecutar chroot(/tmp)
Ejecutar su fakeroot
M aquinas virtuales
Idea nacida en los 60
M ultiples SO sobre harwdare muy costoso
P erdida de inter es en los 80 y 90
Hardware barato, SO multiusuario
Hoy, vuelta a los 60
Procesadores muy r apidos
Prestaciones similares
M aquinas virtuales
M aquinas virtuales
Seguridad
Cada m aquina virtual es independiente
Diferentes SO, discos, direcciones IP
Imposible compartir datos directamente
Imposible afectar el SO donde se ejecuta la m aquina virtual
Fallos
Los fallos son autocontenidos y no afectan al hardware
subyacente
Ejemplo: honeypot

Control Acceso

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Control Acceso

Загружено:

Авторское право:

Доступные форматы

Seguridad Inform atica

Вам также может понравиться