Seguridad en el Sistema de Archivos

Dr. Alonso Ramírez Manzanares23-Nov-2010

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 factores 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 ligar 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 podía 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 alimenta 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 máquina en máquina, 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.

VirusEs 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 seguridadBasado 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 touch 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ónAlgunos 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ónCuando 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ónCuando 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ónCuando 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 usamosint 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://beej.us/guide/bgipc/output/html/multipage/semaphores.html

Y ¿cómo supe que tenía que usarint arg;en lugar de union semun arg; ?

Y ¿cómo supe que tenía que usarint 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!