Dr. Alonso Ramírez Manzanares 26-Nov-2009

Seguridad en el Sistema de
Archivos
Dr. Alonso Ramírez Manzanares
26-Nov-2009
Seguridad
La protección de la información es algo muy
valioso, la información es una moneda en si.
Esto va muy asociado a los terminos de
protección de información. De ahi que en los
SO usamos el término de mecanismo de
protección.
Escencialmente hay 2 facores dañinos:
pérdida de información e intrusos.
Los “Titanics” de los sistemas
computacionales.
En UNIX se pudo alguna vez usar una utileria para
imprimir el archivo de contraseñas.
Otra falla en UNIX era elazar un archivo llamado CORE
al de contraseñas y con una utileria de SO vaciar el
contenido de esta en el archivo CORE, sobreescribiendo
el archivo de contraseñas.
Tambien se podia cambiar el propietario del archivo de
contraseñas haciendo una liga del nuevo directorio al
archivo de contraseñas a medio proceso de MKDIR (entre
el MKNOD y el CHOWN). Si el CPU estaba lento, se
podia intentar muchas veces hasta lograrlo.
Los “Titanics” de los sistemas
computacionales.
Violación de password en TENEX, ya que cuando se hacía una paginación se
disparaba una función de usuario. Esto reduce el número de pruebas de 128n a 128n
Corruptores de
seguridad
Caballos de Troya: Un programa aparantemente
inofensivo que accesa y distribuye información o
destruye información, por ejemplo.
Bomba lógica: Cuando el que la programó y la introdujo
en SO le alimente diariamente algo, como por ejemplo,
su contraseña, no se dispara. Si no se le alimenta un
día, entonces se dispara y hace algo dañino.
Gusano: se propaga de maquina en maquina, como el
famosos caso legal de Robert Tappan Morris en 1988.
¿Que pasa con el open
source?
Que si existe una falla de seguridad,
cualquier persona capacitada puede verla.
Pero es más probable que se detecte rápido.
Virus
Es un fragmento de programa que se anexa a un programa
legítimo con la intensión de infectar otros programas.
Normalmente cuando el virus detecta un archivo no
infectado, agrega el código del virus al final del archivo,
sustituyendo la primera linea por un salto al código del
virus. El virus al finalizar ejecuta el programa original, de
tal forma que cada vez que se ejecuta un programa
infectado este intenta infectar más.
Por supuesto, aparte de infectar otros archivos, el virus
normalmente hace algun daño al sistema (por ejemplo
impedir que el sistema arranque).
Hay virus que incluso han mostrado mensajes de extorsión.
¿Cual es el problema de windows
con respecto a los virus?
Que a diferencia de UNIX, cualquier usuario
puede modificar los archivos de sistema, o
archivos ejecutables de sistema.
Principios de diseño de seguridad
Basado en la experiencia en MULTICS tenemos:
El diseño del sistema debe de ser público
La política por omisión (default) debe de ser de no otorgar
acceso.
Se debe de verificar la vigencia de autorización de acceso.
Privilegios mínimos para cada proceso.
El mecanismo de protección debe de ser sencillo y estar
integrado en las capas mas bajas del SO (los parches casi
nunca trabajan).
El esquema implementado debe de ser psicológicamente
aceptado.
Verificación de autenticidad de usuarios.
Por contraseña, las mas usada y la mas fácil de violar
(Ver Morris and Thompson, 1979). Para mejorar, incluir
mayúsculas, minúsculas y caracteres especiales. Otra
forma es que el sistema proponga palabras
pronunciables sin significado (consultar a Julio
Cortazar). El extremo “contraseña de una sola ves”, cada
login usa una diferente. El sistema hace preguntas.
Identificación física: Tarjetas con tira magnética, lector
de huellas digitales, detector de patrón de voz, firmas en
toch screens. ¿Problemas con esto?
Una medida preventiva
muy usada
El sistema reporta la dirección (IP) desde donde se
realizó la ultima entrada al sistema, de tal forma que
un usuario se puede dar cuenta de que un intruso
entró desde una dirección desconocida.
Otra es poner trampas de fácil violación para poder
capturar espias, ver “The Cuckoo's Egg: Tracking a
Spy Through the Maze of Computer Espionage”
1990”, Clifford Stoll.
Mecanismos de protección
Algunos sistemas emplean un monitor de referencias que
valida quien tiene acceso a que cosa y toma una desición.
Los objetos a protejer pueden ser hardware (CPU,
segmentos de memoria, unidades de disco, etc) o software
(procesos, archivos, bases de datos, etc). Tambien tenemos
un conjunto de acciones a realizar por objeto, por ejemplo,
OPEN, READ, WRITE, etc.
Podemos usar pares (objeto,derechos) llamados dominios. Los
procesos pueden pertenecer a diferentes dominios en
diferentes tiempos.
Dominios de protección
Cuando un proceso conmuta de usuario a kernel,
entonces conmuta de dominio.
Los procesos se asocian a dominios y los dominios tienen
caracterizticas que se pueden guardar en una matriz de
datos (un dominio también puede ser un objeto):
Dominios de protección
Cuando un proceso conmuta de usuario a kernel,
entonces conmuta de dominio.
Los procesos se asocian a dominios y los dominios tienen
caracterizticas que se pueden guardar en una matriz de
datos (un dominio también puede ser un objeto):
Dominios de protección
Cuando un proceso conmuta de usuario a kernel,
entonces conmuta de dominio.
Los procesos se asocian a dominios y los dominios tienen
caracterizticas que se pueden guardar en una matriz de
datos (un dominio también puede ser un objeto):
Así es como guarda los dominios UNIX
Y por último
¿Que dijeron?, ya acabamos, ¡no!, todavia no,
¡hasta la victoria siempre!
¡Semaforos en Linux!,
¿pues en donde más?
Creación de un semáforo:
#include <sys/sem.h>
int semget(key_t key, int nsems, int semflg);
La llave key en un identificador único usado por varios
procesos:
#include <sys/msg.h>
key = ftok("/home/beej/somefile", 'b');
¡Semaforos en Linux!,
¿pues en donde más?
Poner el valor del semáforo en una operación atómica:
int semop(int semid ,struct sembuf *sops, unsigned int
nsops);
nsops es el número de estructuras de abajo, para aplicar a varios
semáforos.
struct sembuf {
ushort sem_num; // número de semaforo
short sem_op; // operacion -1 DOWN, 1 UP
short sem_flg; // Operaciones especiales, como no bloquearse
};
¡Semaforos en Linux!,
¿pues en donde más?
Para inicializar y destruir un semáforo usamos
int semctl(int semid, int semnum, int cmd, ... /*arg*/);
Para cmd usamos SETVAL (Poner un valor que es el
siguiente argumento arg) o bien IPC_RMID (para
eliminar el semáforo).
/*** seminit.c -- sets up a semaphore for semdemo.c*/
#include <stdio.h> #include <stdlib.h> #include <errno.h> #include <sys/types.h>
#include <sys/ipc.h> #include <sys/sem.h>
int main(void)
{
key_t key;
int semid;
//union semun arg;
!
int arg;
if ((key = ftok("semdemo.c", 'J')) == -1) {
perror("ftok");
exit(1);
}
/* create a semaphore set with 1 semaphore: */
if ((semid = semget(key, 1, 0666 | IPC_CREAT)) == -1) {
perror("semget");
exit(1);
}
!
}
/* initialize semaphore #0 to 1: */
//arg.val = 1;
arg=1;
if (semctl(semid, 0, SETVAL, arg) == -1) {
perror("semctl");
exit(1);
}
return 0;
/*semdemo.c -- demonstrates semaphore use as a file locking mechanism*/
#include <stdio.h> #include <stdlib.h> #include <errno.h> #include <sys/types.h>
#include <sys/ipc.h> #include <sys/sem.h>
int main(void)
{
key_t key;
int semid;
struct sembuf sb = {0, -1, 0};
/* set to allocate resource */
if ((key = ftok("semdemo.c", 'J')) == -1) {
perror("ftok"); exit(1);}
/* grab the semaphore set created by seminit.c: */
if ((semid = semget(key, 1, 0)) == -1) {
perror("semget"); exit(1);}
printf("Press return to lock: ");
getchar();
printf("Trying to lock...\n");
if (semop(semid, &sb, 1) == -1) {
perror("semop"); exit(1);}
printf("Locked.\n");
printf("Press return to unlock: ");
getchar();
sb.sem_op = 1; /* free resource */
if (semop(semid, &sb, 1) == -1) {
perror("semop"); exit(1);}
printf("Unlocked\n");
return 0;
}
/*semrm.c -- removes a semaphore*/
#include <stdio.h> #include <stdlib.h> #include <errno.h> #include <sys/types.h>
#include <sys/ipc.h> #include <sys/sem.h>
int main(void)
{
key_t key;
int semid;
//union semun arg;
! int arg;
if ((key = ftok("semdemo.c", 'J')) == -1) {
perror("ftok");
exit(1);
}
/* grab the semaphore set created by seminit.c: */
if ((semid = semget(key, 1, 0)) == -1) {
perror("semget");
exit(1);
}
/* remove it: */
if (semctl(semid, 0, IPC_RMID, arg) == -1) {
perror("semctl");
exit(1);
}
}
return 0;
Para mas información
consultar:
http://www.ecst.csuchico.edu/~beej/guide/
ipc/semaphores.html
Y ¿cómo supe que tenía
que usar
int arg;
en lugar de
union semun arg; ?
Y ¿cómo supe que tenía
que usar
int arg;
en lugar de
union semun arg; ?
cat /usr/include/sys/sem.h
Ahora si, El fin del FIN
¡Muchas gracias por su atención!