PROBLEMAS DE SEGURIDAD EN EL MUNDO UNIX - LINUX

1.- Introduccin

1.1.- Conceptos generales sobre seguridad

1.2.- Polticas de seguridad

1.3.- Seguridad por ocultacin

2.- Clasificacin de Sistemas operativos confiables: Libro Naranja

2.1.- Introduccin

2.2.- Clases de seguridad

2.2.1.- D: seguridad mnima

2.2.2.- C1: proteccin mediante seguridad discrecional

2.2.3.- C2: proteccin mediante accesos controlados

2.2.4.- B1: proteccin mediante seguridad etiquetada

2.2.5.- B2: proteccin estructurada

2.2.6.- B3: dominios de seguridad

2.2.7.- A1: diseo verificado

2.2.8.- Tabla resumen

3.- Mecanismos de seguridad de UNIX

3.1.- Introduccin

3.2.- Usuarios y grupos en UNIX

3.2.1.- Cuentas de usuario

3.2.2.- El archivo /etc/passwd

3.2.3.- Identificador de usuario (UID)

3.2.4.- Grupos

3.2.5.- El archivo /etc/group

3.2.6.- Identificador de grupo (GID)

3.2.7.- Contraseas

3.2.8.- Usuarios especiales: el superusuario

3.2.9.- El comando su

3.3.- El sistema de ficheros de UNIX

3.3.1.- Introduccin

3.3.2.-Tipos bsicos de archivos

3.3.3.- Inodos o nodos indice

3.3.4.- Fechas de los archivos

3.3.5.- Permisos de un archivo

3.3.6.- SUID, SGID y los bits adhesivos

3.3.6.1.- Cambio de UID: setuid()

3.3.7.- Listas de control de acceso (ACLs)

3.3.8.- Archivos de dispositivo

3.3.9.- Sistemas de ficheros montados

4.- Mantenimiento de sistemas confiables

4.1.- Introduccin

4.2.- Criptografa

4.3.- Defensa de cuentas

4.3.1.- Cuentas sin contrasea

4.3.2.- Cuentas predeterminadas

4.3.3.- Cuentas que ejecutan slo una instruccin

4.3.4.- Cuentas abiertas

4.3.4.1.- interpretes de comandos restringidos

4.3.4.2.- Sistemas de archivos restringidos

4.4.- Auditora

4.4.1.- Introduccin

4.4.2.- El sistema de log en UNIX

4.4.3.- El demonio syslogd

4.4.4 Algunos archivos de log

4.5.- Amenazas programadas

4.5.1.-Introduccin

4.5.2.-Base Fiable de Cmputo

4.5.3.-Tipos de amenazas programadas

4.5.4.-Programacin segura

4.5.4.1.-Buffer overflow

4.5.4.2.- Recomendaciones para una programacin segura

4.5.4.3.- Utilizacin segura de funciones de biblioteca

5.- Bibliografa

1.- Introduccin.

1.1.- Conceptos generales sobre seguridad.

Seguridad informtica

"Una computadora es segura si se puede confiar en que, junto con sus programas, funcione como se espera."

Una computadora se considera segura (o confiable, introduciremos este concepto ms adelante) si los datos contenidos en ella seguirn estando all y nadie que no deba leerlos los lea.

Segn esto, los desastres naturales y los errores de programacin son amenazas a la seguridad al igual que los usuarios no autorizados. Por lo tanto no existe diferencia si los datos se pierden por actos de un estudiante vengativo, por un virus, un error inesperado o un rayo: los datos se han perdido de igual forma.

Seguridad y UNIX

Dennis Ritchie dijo sobre UNIX: "No se dise para ser seguro. Se dise para que se pudiera usar la seguridad."

UNIX es un sistema operativo multiusuario y multitarea. Una de las funciones naturales de estos sistemas es prevenir que distintos usuarios o programas que estn usando la misma computadora se estorben. Si no existiera esta proteccin un programa podra afectar al funcionamiento de los programas de otros usuarios, borrar accidentalmente datos e incluso parar todo el sistema. Para evitar esto UNIX siempre ha contado con algn tipo de mecanismos de seguridad.

Pero esta seguridad no se limita a la proteccin de la memoria. UNIX posee un sistema de archivos que controla la forma en que los usuarios acceden a los archivos y a los recursos del sistema.

La mayor parte de los fallos de seguridad que se han encontrado se deben a problemas de configuracin y programas con errores, y no a defectos en el diseo del sistema.

Confiabilidad

Al referirse al nivel de seguridad de un sistema operativo, no es habitual utilizar los trminos "seguro" o "inseguro" , sino que se usa el trmino "confiable" para describir el nivel de confianza que se tiene en que un sistema se comporte como se espera.

Esto implica que no se puede lograr la seguridad absoluta, sino que se trata de acercarse a ella intentando conseguir un grado de confianza suficiente

para garantizar el funcionamiento correcto del sistema, dependiendo del contexto en el que se encuentre.

1.2.- Polticas de seguridad.

A pesar de no ser el objetivo fundamental de este trabajo, es importante considerar el establecimiento de polticas de seguridad a la hora de estudiar la seguridad de un sistema informtico. Debido a esto, resumiremos los conceptos ms relevantes de las polticas de seguridad.

La planificacin de las polticas de seguridad se dividen en seis etapas diferentes:

a.-Planificacin de las necesidades de seguridad:

Existen diferentes clases de seguridad, por lo que, dependiendo del tipo de sistema, habr que dar mayor o menor importancia a las que tengan ms relevancia:

Confidencialidad: Impedir el acceso a la informacin a usuarios no autorizados.

Integridad de los datos: Evitar el borrado o alteracin indeseados de la informacin, incluidos los programas.

Disponibilidad: Asegurar que los servicios est siempre disponibles para un usuario autorizado.

Consistencia: Asegurar que el sistema se comporta como esperan los usuarios autorizados; imagine lo que ocurrira si el comando ls borrara archivos de vez en cuando en lugar de listarlos.

Control: Reglamentar el acceso al sistema, de forma que programas e individuos no autorizados y desconocidos no alteren el normal funcionamiento del sistema.

Auditora: Determinar qu se hizo, quin lo hizo y qu fue afectado. Para esto es necesario llevar un registro inexpugnable de todas las actividades realizadas en el sistema y que identifica de forma no ambigua a los usuarios que las llevaron a cabo.

b.-Anlisis de riesgos:

Trata de responder a tres preguntas: qu se debe proteger?, contra qu debe protegieres?, cunto se est dispuesto a invertir para obtener una proteccin adecuada?. Para responder a estas preguntas, el anlisis de riesgos se divide en tres etapas:

Identificacin de los activos.

Identificacin de las amenazas.

Clculo de los riesgos.

c.- Anlisis de costo-beneficio.

Consiste en asignar un costo a cada riesgo, y determinar el costo de defenderse. De esta manera se puede decidir qu medidas hay que adoptar para proteger qu activos. Este aspecto no lo desarrollaremos por que no entra en el mbito de este estudio.

d.-Polticas de seguridad.

Las polticas sirven para definir qu se considera valioso y especifican qu medidas hay que tomar para proteger esos activos.

Deben aclarar qu se est protegiendo, establecer la responsabilidad de la proteccin y poner las bases para resolver e interpretar conflictos posteriores. No deben hacer una lista de riesgos especficos, computadoras o individuos por nombre. Deben ser generales y no variar mucho a lo largo del tiempo.

e.-Implementacin.

f.- Auditora y respuesta ante incidentes.

Estos dos ltimos apartados constituyen el resto de este trabajo.

1.3.- Seguridad por ocultacin

Esta costumbre proviene de las aplicaciones militares, donde la ocultacin es una forma efectiva de proteccin. Pero trasladar este concepto a un ambiente de computacin no resulta apropiado, pudiendo resultar incluso daino para la seguridad.

La ocultacin presenta bastantes inconvenientes. Por ejemplo, al negar el acceso a los manuales a los usuarios, un administrador puede pensar que ha mejorado la seguridad al impedir a estos el conocimiento de comandos y opciones que pueden usarse para penetrar el sistema. Sin embargo, resulta sencillo conseguir esa documentacin por diversos medios (universidades, Internet, libreras, ...), por lo que los administradores no pueden impedir que los usuarios accedan a la documentacin.

Adems, esto redunda en una prdida de eficacia de los usuarios, al no poder consultar los manuales. Esto tambin conlleva una actitud negativa porque da a entender que no se confa en los usuarios.

Los errores de programacin o caractersticas excepcionales son tambin objeto habitual de la ocultacin, pero esto tambin es una mala poltica. Los desarrolladores colocan frecuentemente puertas traseras en sus programas

que permiten obtener privilegios sin autentificarse debidamente. Otras veces esto permite que errores de programacin que afectan gravemente a la seguridad del sistema persistan ya que se supone que nadie los conoce. El problema es que estos agujeros de seguridad tienden a ser descubiertos por accidente o por intrusos persistentes.

Otra prctica habitual es mantener en secreto algoritmos desarrollados localmente, tales como algoritmos de cifrado. Esto tambin presenta algunos inconvenientes. Sin un estudio en profundidad estos podran presentar graves fallos de seguridad, y este estudio no es posible si se mantienen en secreto.

Desde el punto de vista de los sistemas operativos, mantener el cdigo fuente en secreto no garantiza la seguridad. Si un intruso desea penetrar en el sistema, antes o despus descubrir algn fallo de seguridad (estos siempre existen), pero el resto de usuarios bienintencionados no podr revisar el cdigo en busca de estos fallos.

Es mejor usar algoritmos y mecanismos robustos aunque sean conocidos por los enemigos, ya que esto adems puede desalentar a un posible atacante consciente de la fiabilidad del mecanismo. "Poner dinero en una caja fuerte es mejor que esconderlo en un frasco de mayonesa en la cocina porque nadie sabe que est all."

2.- Clasificacin de Sistemas operativos confiables: Libro Naranja.

2.1.- Introduccin

El Libro Naranja (Trusted Computer System Evaluation Criteria), elaborado por el Ministerio de Defensa de los E.E.U.U en 1983, establece criterios para medir la fiabilidad de los sistemas informticos en lo respectivo a la seguridad.

Antes de describir los diferentes niveles de seguridad, es necesario conocer algunos conceptos relevantes :

Base fiable de cmputo(TCB): Es el conjunto de mecanismos relevantes a efectos de la seguridad del sistema. En las clases con una fiabilidad elevada, la TCB se construye en torno a un monitor de referencias que impone las relaciones de acceso autorizadas entre los sujetos y objetos de un sistema.

Control de accesos discrecional: Permite restringir el acceso a los objetos basndose en la identidad de los usuarios y/o grupos de usuarios a

los que pertenecen. Los usuarios protegen sus objetos indicando quin puede acceder y el tipo de acceso permitido.

Reutilizacin de objetos: Implica proteger ficheros, memoria y otros objetos de accesos por parte de un usuario tras su uso por otro. Por ejemplo: Un usuario crea un fichero en el que almacena informacin confidencial y despus lo borra. A continuacin otro usuario malicioso reserva espacio en el disco y el sistema le asigna esos mismos bloques. Si el sistema no borra fsicamente la informacin del usuario anterior, el otro usuario podra leer la informacin borrada por el dueo original .

Etiquetas: Las etiquetas de confidencialidad se asocian a cada sujeto (usuario, proceso) y a cada objeto (fichero, directorio, ...) e indican su nivel de autoridad asociado y se denomina habilitacin. La etiqueta de confidencialidad de un fichero especifica el nivel de autoridad que un usuario debe tener para acceder al mismo.

Identificacin y autentificacin: Es necesario que los usuarios se identifiquen antes de realizar cualquier actividad que implique una interaccin con la TCB (ejecutar un programa, leer un fichero). En los sistemas UNIX la identificacin se realiza mediante un nombre de conexin (login) y la autentificacin mediante una contrasea (password).

Va fiable: En algunos sistemas se requiere que los usuarios puedan conectarse desde un terminal al sistema a travs de lo que llamaremos una va fiable. Para ello existe una secuencia de teclas, que al pulsarse elimina todos los procesos actuales y establece una conexin segura con la TCB permitiendo su autentificacin. Esto evita ataques sistemticos contra el sistema mediante programas marcadores y la introduccin de caballos de Troya en los programas de conexin al sistema

Auditoria: Es el registro y examen de la actividades relacionadas con la seguridad en un sistema fiable. Las actividades relacionadas con la seguridad son los accesos (y sus intentos) de un sujeto sobre un objeto y suelen denominarse sucesos. Cada vez que se produce un suceso, debe almacenarse en el registro de auditoria la siguiente informacin: fecha, hora, identificador del usuario, tipo, si ha tenido xito, terminal, nombre de objeto, descripcin de las modificaciones en la TCB y clases de seguridad del sujeto y del objeto.

Arquitectura del sistema: Estn relacionados con el diseo de un sistema para que sea posible la seguridad."

Integridad del sistema: Se refiere al conjunto de pruebas de integridad que se ejecutan siempre que se arranca el ordenador, o peridicamente siguiendo un mantenimiento preventivo (en UNIX, se lleva a cabo un chequeo del sistema de ficheros cada vez que se monta un determinado numero de veces).

Canales ocultos: Son rutas de informacin que habitualmente no se utilizan como medio de comunicacin en el sistema y, por lo tanto, no estn protegidos por sus mecanismos de seguridad. Utilidad para la administracin de la fiabilidad: Implica asignar todas las actividades de seguridad a una persona diferente al administrador de sistema. Esto se basa en el principio de que es mejor asignar las actividades de seguridad a varias personas, para que el control total no recaiga sobre una sola persona, lo que podra comprometerlo.

Gestin de configuracin: protege a un sistema fiable mientras se disea, desarrolla y mantiene. Implica controlar todos lo cambios realizados en la TCB. As se mantiene un control del sistema durante su ciclo de vida, asegurando que el sistema que se utiliza no es una versin antigua del mismo.

Distribucin segura: Garantiza la proteccin del sistema mientras se enva a un cliente, asegurando que el sistema que recibe es idntico al suministrado por el vendedor.

Gua de usuario sobre las caractersticas de seguridad: Indica a los usuarios no privilegiados del sistema todo lo que deben saber sobre la seguridad.

Manual para la administracin de la seguridad: Proporciona a los administradores toda la informacin necesaria para establecer e implantar la seguridad del sistema

Documentacin de pruebas: Debe contener un plan de pruebas con el objeto de encontrar cualquier posible error en el diseo o implementacin de la TCB, que permite a un usuario acceder a informacin no autorizada.

Documentacin de diseo: Permite conocer la construccin interna de la TCB, ayudando a los equipos de diseo y desarrollo a definir el modelo de seguridad del sistema y su construccin.

2.2.- Clases de seguridad

El Libro Naranja divide su clasificacin en cuatro niveles de seguridad. Los requisitos para un determinado nivel siempre lo son para el siguiente, pudiendo este restringir ms an los criterios, ya que se trata de una jerarqua de niveles:

2.2.1.- D: seguridad mnima

En esta categora estn englobados todos los sistemas que han sido valorados y no han superado los requisitos mnimos para pertenecer a un nivel de seguridad superior. En esta categora no existen requisitos de seguridad."

En realidad ningn sistema pertenece a esta categora, puesto que ningn vendedor evaluara un sistema para obtener un nivel de seguridad "D". Ordenadores bajo MS-DOS o las versiones personales de Windows (familia 9x), adems de otros sistemas antiguos son un ejemplo de sistemas que perteneceran a esta categora.

2.2.2.- C1: proteccin mediante seguridad discrecional

Todos los usuarios manejan los datos al mismo nivel . En este nivel se procura evitar que los usuarios cometan errores y daen al sistema. Las caractersticas mas importantes de este nivel son el control de autentificacin mediante contraseas y la proteccin discrecional de los objetos. El cdigo del sistema debe estar protegido frente a ataques procedentes de programas de usuario (en UNIX, un proceso no puede salirse de su espacio virtual de direcciones ,y si lo intenta, morir.

Un sistema de este nivel no necesita distinguir entre usuarios individuales, Tan solo entre tipos de accesos permitidos o rechazados. En UNIX C1 hay que ser dueo de un objeto para ceder sus derechos de accesos y siempre se protege a los objetos de nueva creacin.

2.2.3.- C2: proteccin mediante accesos controlados

A partir de este nivel, el sistema debe ser capaz de distinguir entre los usuarios individuales. Generalmente el usuario debe ser dueo de un objeto para ceder los derechos de acceso sobre l. En la mayora de los sistemas UNIX a partir de este nivel, existen listas de control de acceso (ACLs). Debe permitir que los recursos del sistema se protejan mediante accesos controlados. En UNIX el acceso a los perifricos (dispositivos de E/S) siguen un esquema de permisos idntico al de los ficheros de los usuarios.

Se aplican los requisitos de reutilizacin de objetos cuando esos mismos se reasignan.

Se requiere a partir de este nivel que el sistema disponga de auditoria. Por ello cada usuario debe tener un identificador nico que se utiliza para comprobar todas las acciones solicitadas. Se deben auditar todos los sucesos relacionados con la seguridad y proteger la informacin de la auditoria. El sistema debe ser capaz de auditar a nivel de usuario.

La mayor parte de los UNIX comerciales pertenecen a este nivel, puesto que lo nico que han tenido que aadir los fabricantes es un paquete de auditoria.

2.2.4.- B1: proteccin mediante seguridad etiquetada

A partir de este nivel, los sistemas poseen un sistema de control de accesos obligatorio que implica colocar una etiqueta a los objetos (principalmente sobre los ficheros). Esto, junto con el nivel de habilitacin de los usuarios es utilizado para reforzar la poltica de seguridad del sistema. En estos

sistemas, el dueo no es el responsable de la proteccin del objeto, a menos que disponga de la habilitacin necesaria.

En cuanto a la auditoria, el sistema debe ser capaz de registrar cualquier cambio o anulacin en los niveles de seguridad, y tambin hacerlo selectivamente por nivel de seguridad."

Debe existir una documentacin que incluya el modelo de seguridad soportado por el sistema. No es necesaria una demostracin matemtica, pero si una exposicin de las reglas implantadas por las caractersticas de seguridad del sistema.

2.2.5.- B2: proteccin estructurada

A partir de este nivel, los cambios en los requisitos no son visibles desde el punto de vista del usuario respecto de los niveles anteriores.

En B2, todos los objetos del sistema estn etiquetados, incluidos los dispositivos. Deben existir vas fiables que garanticen la comunicacin segura entre un usuario y el sistema. Los sistemas deben ser modulares y utilizar componentes fsicos para aislar las funciones relacionadas con la seguridad de las dems. Requieren una declaracin formal del modelo de seguridad del sistema, y que haya una gestin de la configuracin. Tambin deben buscarse los canales ocultos.

2.2.6.- B3: dominios de seguridad

Es necesario que exista un administrador de seguridad, que sea alertado automticamente si se detecta una violacin inminente de la seguridad.

Deben existir procedimientos para garantizar que la seguridad se mantiene aunque el ordenador se caiga y luego rearranque. Es obligatoria la existencia de un monitor de referencia sencillo, a prueba de agresiones e imposible de eludir. La TCB debe excluir todo el cdigo fuente que no sea necesario para proteger el sistema.

2.2.7.- A1: diseo verificado

Esta es la clase de certificacin ms alta, aunque el Libro Naranja no descarta la posibilidad de exigir requisitos adicionales. Son sistemas funcionlmente equivalentes a B4. Tan solo se aade la distribucin fiable que refuerza la seguridad. Los sistemas A1 tienen la confiabilidad adicional que ofrece el anlisis formal y la demostracin matemtica de que el diseo del sistema cumple el modelo de seguridad y sus especificaciones de diseo.

En la siguiente tabla se resumen las caractersticas principales de los diferentes niveles de seguridad definidos en el Libro Naranja:

2.2.8.- Tabla resumen

Requisito C1 C2 B1 B2 B3 A1

Control de accesos discrecional nue mej sin sin mej sin

Reutilizacin de objetos no nue sin sin sin sin

Dispositivos mononivel/multinivel no no nue sin sin sin

Control de accesos obligatorio no no nue mej sin sin

Etiquetas no no no nue sin sin

Identificacin y autentificacin nue mej mej sin sin sin

Auditoria no nue mej mej mej sin

Vas fiables no no no nue mej sin

Arquitectura del sistema nue mej mej mej mej sin

Integridad del sistema nue sin sin sin sin sin

Pruebas de seguridad nue mej mej mej mej mej

Especificacin y verificacin del diseo no no nue mej mej mej

Canales ocultos no no no nue mej mej

Facilidad para la administracin de la fiabilidad

no no no nue mej sin

Gestin de configuracin no no no nue sin mej

Recuperacin segura no no no no nue sin

Distribucin segura no no no no no nue

Gua de usuario de seguridad nue sin sin sin sin sin

Gua de administracin de la seguridad nue mej mej mej mej sin

Documentacin de pruebas nue sin sin mej sin mej

Documentacin de diseo nue sin mej mej mej mej

Leyenda:

no: no existe criterio en esta clase.

nue: criterio nuevo para esta clase

mej: nuevos requisitos para el criterio en esta clase.

sin: no existen requisitos adicionales para el criterio en esta clase.

3.- Mecanismos de seguridad de UNIX

3.1.- Introduccin

En este captulo se destacan los principales mecanismos de seguridad de UNIX, es decir, aquellos recursos que el sistema operativo proporciona y que conforman la base sobre la que se establece la seguridad.

El conocimiento de estos mecanismos por parte del administrador de seguridad es completamente imprescindible, puesto que, bien utilizados permiten que el sistema se muestre robusto ante cualquier ataque o fallo. Por otro lado, mal utilizados proporcionarn una puerta abierta a cualquier atacante o convertirn un programa inocente en un autntico agujero de seguridad.

3.2.- Usuarios y grupos en UNIX

Las cuentas de usuario son el primer objetivo de cualquier atacante, su finalidad suele ser casi siempre esta, penetrar en el sistema consiguiendo apoderarse de una cuenta de usuario (preferentemente la del root). Despus pueden robar, destruir o falsificar datos o simplemente dejar una nota, pero el dao ya est hecho: la seguridad del sistema se ha visto comprometida.

3.2.1.- Cuentas de usuario

Como se seala en el captulo anterior, la identificacin en los sistemas UNIX se realiza mediante un nombres de usuarios (login) y la autentificacin mediante contraseas (password). Los nombres de usuario se conocen tambin como nombres de cuenta. Para iniciar una sesin en un sistema UNIX, es necesario conocer tanto el nombre de usuario como la contrasea correspondiente. Por ejemplo, Manuel Rodrguez posee una cuenta en el servidor de practicas de su universidad. Su nombre de usuario es manurod y su contrasea es "as35FgS". Cuando Manuel desee iniciar una sesin de trabajo en el laboratorio, deber autentificarse como usuario autorizado ante la mquina de la siguiente manera:

Bienvenido al servidor X de la Universidad Y

login: manurod

password: as35FgS

De esta manera, el usuario queda totalmente autentificado y obtendr un interprete de comandos (shell) desde el que podr realizar

diferentes tareas. Otra posibilidad es que el servidor disponga de un entorno de trabajo en modo grfico (X-Window), en ese caso el proceso de autentificacin se realiza de idntica manera, con la nica diferencia de que el usuario obtendr un entorno grfico de trabajo en lugar del shell habitual.

Los nombres de usuario estndar en UNIX tienen una longitud que puede ir de 1 a 8 caracteres. Estos nombres deben ser nicos en una misma computadora, puesto que deben identificar al usuario de forma inequvoca (despus se vera que esto no es estrictamente cierto, puesto que dos usuarios pueden compartir el mismo UID). Las contraseas en UNIX tradicionalmente tenan una longitud de entre 1 y 8 caracteres, aunque algunas versiones comerciales permiten contraseas mas largas. El uso de contraseas mas largas implica una mayor seguridad, por que son mas difciles de adivinar. La contrasea no debe ser obligatoriamente nica para cada usuario, varios usuarios pueden tener, de hecho, la misma contrasea, aunque de ser as, esto indicara que estos usuarios han elegido una mala contrasea.

La eleccin de las contraseas, as como las posibles restricciones que se pueden establecer sobre ellas, es de vital importancia a la hora de evitar intrusiones en el sistema, por ello, se dedicar a esto otro apartado.

3.2.2.- El archivo /etc/passwd

En los sistemas tipo UNIX , la informacin sobre las cuentas de usuario se almacenan en una base de datos localizada en el archivo /etc/passwd. Esta es un fichero de texto en el que los diferentes registros se encuentran separados por el carcter dos puntos (:).

Se puede emplear el comando cat para visualizar el contenido del fichero passwd. A continuacin se puede ver una muestra de un archivo tpico como ejemplo :

root:o8o7aSVh13nLD:0:0:root:/root:/bin/bash

bin:*:1:1:bin:/bin:

daemon:*:2:2:daemon:/sbin:

adm:*:3:4:adm:/var/adm:

lp:*:4:7:lp:/var/spool/lpd:

mail:*:8:12:mail:/var/spool/mail:

news:*:9:13:news:/var/spool/news:

uucp:*:10:14:uucp:/var/spool/uucp:

operator:*:11:0:operator:/root:

ftp:*:14:50:FTP User:/home/ftp:

nobody:*:99:99:Nobody:/:

manurod:EH5/.mj7J5dFh:501:100:Manuel Rodrguez:/home/alumnos/manurod:/bin/bash

maripet:aCq87MC03c9e:502:100:Mario Petru:/home/alumnos/maripet:/bin/bash

javitup:md0mHM86yn3aW:503:100:Javier Tup:/home/alumnos/javitup:/bin/bash

Algunas de las cuentas del ejemplo son cuentas del sistema como root,daemon o apm. El resto son cuentas de usuario regulares del sistema como manurod, javitup, maripet.

Las cuentas que tienen un * en al campo de la contrasea no pueden ser utilizadas para iniciar una sesin desde un terminal, es necesario utilizar la orden su. Son cuentas de sistema (en ocasiones usuarios 'castigados'), que poseen archivos, a veces muy importantes, que realizan tares administrativas o dan servicios.

Cada campo individual del archivo passwd posee un significado directo. En la siguiente tabla se explica el significado de una de las lneas del ejemplo:

Campo Contenido

manurod Nombre de usuario

EH5/.mj7J5dFh Contrasea cifrada del usuario

501 Numero de identificacin del usuario (UID)

500 Numero de identificacin de grupo del usuario (GID)

Manuel Rodrguez Nombre completo del usuario

/home/alumnos/manurod/ Directorio base del usuario

/bin/bash Interprete de comandos del usuario

La contrasea se guarda cifrada. La contrasea en s no se guarda tal cual en el sistema, si as se hiciera, esto representara un grave riesgo

para la seguridad, y solo es aceptable cuando la poltica de seguridad lo admita por razones particulares.

En la actualidad, muchas organizaciones poseen grandes redes de tipo cliente-servidor que contienen muchos servidores y una gran cantidad de estaciones de trabajo. Normalmente es deseable que los usuarios entren en cualquiera de estas computadoras, y que lo hagan con el mismo nombre de usuario y la misma contrasea. Esto conlleva que cada usuario tenga una cuenta en cada estacin de trabajo.

Este requisito hace que sea extremadamente difcil mantener la coherencia entre las bases de datos de usuarios de todas las computadores. Para lograr esto se utilizan diversos paquetes software que proporcionan el contenido del fichero /etc/passwd a toda la red.

Algunos de estos sistemas son:

Network Information System (NIS:Sistema de Informacin para la Red) de Sun Microsystems.

NIS+ de Sun Microsystems

Distributed Computing Environment (DCE: Ambiente de Computacin Distribuido) de Open Software Foundation.

NetInfo de NeXT Computers

Todos estos sistemas toman la informacin, que por lo general, est almacenada en cada estacin de trabajo y la ponen en una o mas computadoras que se usan como servidores de red. Al usar estos sistemas, ya no se puede usar simplemente el comando cat, sino que hay que utilizar una instruccin especifica para cada sistema para ver el contenido del archivo /etc/passwd.

El servicio NIS de Sun complementa la informacin almacenada en los archivos de las estaciones de trabajo. Por lo tanto, para ver la lista completa de las cuentas de usuario, es necesario listar el contenido del archivo passwd local y ademas utilizar la siguiente instruccin:

% ypcat passwd

El servicio NIS+, tambin de Sun, se puede configurar para complementar sustituir sus entradas sobre cuentas de usuario en lugar de las que estn en el archivo passwd local, dependiendo del contenido del archivo /etc/nsswitch.conf. Para ver la lista de usuarios bajo NIS+ hay que utilizar el comando niscat y especificar el dominio de NIS+. Por ejemplo :

% niscat -o passwd.dominio

En las computadoras que ejecutan NetInfo, el archivo local no se toma en cuenta y en su lugar se usa la versin de red. Por ejemplo, para ver las cuentas de usuario, si se usa NetInfo, hay que escribir:

% nidump passwd /

Las computadoras que usan DCE emplean una base de datos de red cifrada como alternativa a las contraseas cifradas y al archivo /etc/passwd.

Muchos administradores no utilizan sistemas de administracin de bases de datos en red porque temen que la seguridad se vea comprometida. Estos temores provienen del hecho de que la configuracin de estos sistemas es, en ocasiones, muy complicada y los protocolos que utilizan pueden no ser particularmente resistentes a ataques. Es una practica habitual entre los administradores mantener simplemente un archivo central con la informacin de los usuarios y copiarlo de forma peridica en las computadoras remotas. El inconveniente que se presenta es que con frecuencia el administrador tiene que cambiar manualmente contraseas de usuarios. En general, es preferible aprender a dominar la configuracin de estos sistemas y luego colocar otras medidas defensivas como es el caso del cortafuegos (firewall).

3.2.3.- Identificador de usuario (UID)

El UID es un nmero entero real de 16 bits (de 0 a 65535). Los primeros UID se usan principalmente para funciones del sistema. Para las personas, normalmente empiezan en el 20, el 100 o el 500. Es habitual asignar el UID dependiendo del grupo primario del usuario: los usuarios del grupo 500 tendrn los UID 501, 502, 503, y as sucesivamente. Algunas versiones de UNIX permiten ahora UID de 32 bits. En las versiones antiguas de UNIX los UID son enteros de 16 bits con signo (de -32768 a 32767).

UNIX utiliza el archivo /etc/passwd para almacenar la correspondencia entre el nombre de cada usuario y su UID. El UID de cada usuario se guarda en el tercer campo, despus de la contrasea cifrada. Esta es una lnea del ejemplo anterior:

manurod:EH5/.mj7J5dFh:501:100:Manuel Rodrguez:/home/alumnos/manurod:/bin/bash

Aqu se puede ver que el UID de manurod es 501.

El UID es la informacin real que utiliza el sistema operativo para identificar al usuario. Los nombre de usuario son solo una comodidad para nosotros. Si dos usuarios tienen el mismo UID, UNIX los trata como si fueran el mismo usuario, aunque tengan nombres y contraseas distintos. Dos usuarios con el mismo UID pueden leerse y

borrarse archivos libremente el uno al otro, as como suspenderse los programas que ejecuten. Asignar a dos usuarios el mismo UID es, por lo general, una mala idea, salvo algunas excepciones.

3.2.4.- Grupos

Todos los usuarios de UNIX pertenecen a uno o ms grupos. El administrador del sistema puede utilizar los grupos para definir conjuntos de usuarios que tendrn permiso de leer, escribir y/o ejecutar ciertos archivos, directorios o dispositivos.

Cada usuario pertenece a un grupo primario, que se anota en el archivo /etc/passwd. El GID del grupo primario de un usuario aparece despus del UID del usuario.

Los grupos permiten manejar cmodamente a varios usuarios de alguna manera. Por ejemplo, tal vez se quiera abrir un grupo para un equipo de estudiantes que trabajan en un proyecto y permitirles a ellos y slo a ellos leer y modificar los archivos del equipo.

Los grupos tambin se usan para restringir el acceso a la informacin confidencial o aplicaciones con licencias especificas. Por ejemplo, en muchas computadoras que usan UNIX, solamente se permite examinar el contenido de la memoria del kernel del sistema a ls usuarios que pertenecen al grupo kmem. El grupo ingres se usa normalmente para quienes estn registrados como usuarios del programa comercial del manejo de bases de datos Ingres.

Algunas versiones especiales de UNIX permiten usar CAO o Controles de Acceso Obligatorio (MAC: Mandatory Access Controls), los cuales controlan el acceso mediante etiquetas en los datos, ademas o en lugar de los controles tradicionales CAV o Controles de Acceso Voluntario (DAC: Discretionary Access Controls) de UNIX . Los sistemas que se basan en CAO/CAV (MAC/DAC) no emplean los grupos tradicionales de UNIX. En su lugar, los valores de los GID y el archivo /etc/group se pueden usar para especificar etiquetas de seguridad para el control de acceso o bien para apuntar a listas de capacidades.

3.2.5.- El archivo /etc/group

El archivo /etc/group contiene la base de datos con todos los grupos que hay en la computadora y sus GID correspondientes. Su formato es similar del del archivo /etc/passwd.

He aqu una muestra de archivo /etc/group que pertenece a un sistema tpico:

root:*:0:root

bin:*:1:root,bin,daemon

daemon:*:2:root,bin,daemon

sys:*:3:root,bin,adm

adm:*:4:root,adm,daemon

lp:*:7:daemon,lp

kmem:*:9:

wheel:*:10:root,javitup

mail:*:12:mail

news:*:13:news

uucp:*:14:uucp

ftp:*:50:

users:*:100:

floppy:*:19:

cdwriter:*:500:manurod

pppusers:*:44:maripet

La primera lnea define el grupo root. Los campos se detallan en la siguiente tabla:

Campo Contenido

root Nombre de grupo

* Contrasea de grupo (cifrada)

0 Numero de identificacin del grupo (GID)

root Lista de usuarios miembros del grupo

Los usuario que aparecen en el archivo /etc/group pertenecen a los grupos que se indican, adems de pertenecer a sus grupos primario los

cuales se indican en el archivo /etc/passwd. Por ejemplo, manurod, maripet y javitup pertenecen al grupo users a pesar de no aparecer explcitamente en el archivo /etc/group porque su grupo primario es el 100. En algunas versiones de UNIX, se puede ejecutar el comando groups o id para ver la lista de grupos a los que se pertenece.

3.2.6.- Identificador de grupo (GID)

Todos los usuarios de UNIX pertenecen a uno o ms grupos. Al igual que las cuentas de usuario, los grupos tienen un nombre de grupo y un nmero de identificacin de grupo (GID). Usualmente, los valores de los GID tambin son enteros de 16 bits.

Anlogamente al UID, el GID representa al grupo en el sistema, y no su nombre. Los grupos permiten agrupar a varios usuario que posean el mismo grupo primario (campo GID del archivo /etc/passwd) o que aparezcan en el archivo /etc/group.

Las versiones de UNIX de AT&T anteriores a SVR4 slo permitan que un usuario estuviera en un grupo a la vez. Para cambiar de grupo haba que usar el comando newgrp. Cuando un usuario intentaba acceder a un archivo sobre el que tena permiso por pertenecer al mismo grupo, se le denegaba el acceso si, en ese instante, el usuario no estaba en ese mismo grupo. Por eso deba usar el comando newgrp.

En la actualidad, los usuarios pertenecen a todos los grupos en los que aparecen en el archivo /etc/group a la vez. El sistema operativo chequea todos los grupos a los que pertenece el usuario para comprobar sus derechos de acceso. Aun as, el comando newgrp sigue teniendo cierta importancia. Si un usuario quiere que sus archivos tengan un grupo (GID) en especial de entre los que posee, debe utilizar el comando newgrp en cada archivo para cambiarlos de grupo. Esto puede ser un poco pesado, si est generando muchos archivos, as que puede cambiar de grupo con newgrp, de forma que todos los archivos que genere tengan el nuevo GID.

3.2.7.- Contraseas

Para autentificar a un usuario, este debe demostrar su identidad. Existen tres maneras por la que un usuario puede autentificarse ante el sistema. Puede usarse una o varias de estas a la vez:

Se puede indicar algo que se sabe (por ejemplo, una contrasea)

Se puede mostrar algo que se tiene (por ejemplo, una tarjeta)

La computadora puede considerar alguna caracterstica personal (por ejemplo, una huella dactilar).

Ninguno de estos sistemas es infalible. Alguien puede robar la contrasea 'husmeando' la linea de un terminal, puede robar la tarjeta en un atraco, y si tiene un cuchillo, quizs pueda obtener una huella dactilar. En general, cuanto ms confiable sea la forma de identificacin, ms complicada ser de usar, y ms agresivo deber ser el agresor para violarla.

Las contraseas son el sistema de autentificacin ms simple: son un secreto que se comparte con la computadora. Al iniciar la sesin, se escribe la contrasea para demostrar a la computadora de quin se trata. La computadora se asegura de que la contrasea corresponde al nombre de usuario que se ha especificado. Si corresponde, se puede continuar.

En el sistema UNIX no se despliega la contrasea, es decir, no se escribe en el terminal a medida que se teclea. Esto proporciona proteccin adicional si alguien est mirando por encima del hombro del que escribe. Esto puede parecer trivial, pero constituye la primera medida de seguridad.

Las contraseas son la primera linea de defensa de UNIX contra los extraos que quieren penetrar en el sistema. Aunque se puede penetrar en el sistema o robar informacin a travs de la red sin abrir una sesin, muchas intrusiones se deben a contraseas mal elegidas y mal protegidas.

En los sistemas personales de escritorio no se usan contraseas. La seguridad se basa en mtodos fsicos como paredes, puertas y cerraduras. En algunos ambientes de confianza tampoco se usan contraseas, la confianza y el respeto pueden ser suficientes como medida de seguridad.

Pero cuando una computadora est conectada a un modem y se puede acceder desde casi cualquier parte del mundo, o cuando est conectada a una red, sobre todo Internet, entonces las contraseas son absolutamente necesarias. Si una cuenta de una computadora que pertenece a una red se ve comprometida, puede poner en peligro a toda la red.

Las contraseas convencionales han sido parte de UNIX desde sus primeros aos. La ventaja de las contraseas es que funcionan sin un equipo especial (como lectores de tarjeta y de huellas digitales).

En la actualidad las contraseas convencionales en sistemas de red (la mayora) no son suficiente. Es necesario usar contraseas descartables o criptografa, o ambas.

En algunas versiones de UNIX, si alguien intenta iniciar una sesin varias veces seguidas de forma invlida se bloquea la cuenta. Slo el administrados puede desbloquearla. El bloqueo protege al sistema de

quienes intentan adivinar una contrasea y avisa de que alguien ha intentado penetrar en la cuenta.

Esta tctica puede ser utilizada en ataques de negacin de servicio, para bloquear a ciertos usuarios del sistema, o simplemente para fastidiar. En lugar del bloqueo, algunos sistemas (como Linux) introducen un retardo mayor cada vez que se falla una conexin desde un terminal, lo que limita los ataques de negacin del servicio, cumpliendo el mismo efecto que el bloqueo.

El cambio de contrasea es otro momento crtico. El comando passwd, que sirve para cambiar la contrasea, solicita primero la contrasea anterior antes de la nueva. As se evita que alguien se siente en un terminal abierto y cambie la contrasea. Dejar un terminal abierto sin proteccin, es un fallo de seguridad bastante grave, pero, por lo general, bastante comn.

El comando passwd, tambin requiere que se repita la contrasea. Esto evita que, por un error tipogrfico, se cambie la contrasea por una desconocida.

Si se recibe un correo del administrador pidiendo que se cambie la contrasea a una determinada, se debe ignorar y avisar al administrador. Este tipo de mensajes se enva con frecuencia a usuarios novatos. Si se cumple la orden, puede tener consecuencias devastadoras.

Si se comete un error, o se olvida la contrasea y se pierde es acceso a la cuenta, hay que recurrir al administrador. Este no puede descifrar la contrasea de ningn usuario. Pero puede eliminar la contrasea o cambiarla, (esta parece la mejor opcin) sin dar la contrasea vigente.

Uno de los fallos ms habituales es asignar como contrasea el nombre de usuario. Esta es en algunos sistemas una prctica habitual cuando se crea un usuario. Se debe obligar al usuario a cambiar la contrasea en la primera sesin. Si no lo hace, es probable que cualquiera que intente entrar en la computadora no tarde ms de diez minutos en conseguirlo.

En general, se deben evitar las siguientes contraseas:

El nombre propio, el de la esposa o del socio

En nombre de la mascota o del hijo

Los nombre de amigos o compaeros de trabajo

Los nombres de los personajes favoritos

El nombre del jefe

El nombre de cualquier persona

El nombre del sistema operativo que se est utilizando

El nombre de la computadora que se usa

El nmero de telfono o el de la matricula del coche

Cualquier parte del dni o nmero de la Seguridad Social

Cualquier cumpleaos

Cualquier otra informacin que sea fcil de averiguar (direccin, universidad, etc.)

Cualquier forma del nombre de usuario (por ejemplo, en maysculas o con letras dobles)

Cualquier palabra que aparezca en un diccionario en cualquier idioma

Nombre propios de lugares o personas

Contraseas que sean una repeticin de la misma letra

Patrones simples de letras del teclado: por ejemplo, qwerty

Cualquiera de stos escrito al revs

Cualquiera de stos con un dgito al principio o al final

En general, cualquier combinacin de cualquiera de las anteriores.

El motivo de estas recomendaciones, es que uno de los ataques ms habituales consiste en conseguir el archivo /etc/passwd de la computadora, y utilizar despus un generador de contraseas. Estos programas (como el programa Crack) utilizan un diccionario y un archivo de normas. En el archivo de normas se encuentran reglas para combinar las palabras del diccionario. As se genera una lista de posibles contraseas que se encriptan (el algoritmo es pblico) y se comparan con las contenidas en el archivo /etc/passwd.

3.2.8.- Usuarios especiales: el superusuario

Adems de los usuarios normales, UNIX tiene varios usuarios especiales para propsitos administrativos y contables. Ya se han mencionado algunos. El ms importante es el root, el superusuario.

Todos los sistemas UNIX tienen un usuario especial en el archivo /etc/passwd cuyo UID es 0. Este es realmente el nico usuario

realmente especial del sistema, los dems son especiales porque son propietarios de determinados archivos o pertenecen a determinados grupos (que a su vez tienen archivos importantes).

La cuenta root es la identidad que usa el sistema operativo para llevar a cabo sus funciones bsicas, tales como el inicio y la terminacin de sesiones de usuario, el registro de la informacin contable y la administracin de dispositivos de entrada/salida. Por esta razn, el superusuario tiene el control de casi todo el sistema operativo: cualquier programa ejecutado por root puede eludir casi todas las restricciones de seguridad y se desactivan casi todas las verificaciones y advertencias.

Como se indic en la seccin sobre el identificador de usuario (UID), dos cuentas que tengan el mismo UID son la misma para el sistema operativo. De esta manera, cualquier cuenta que tenga el UID 0 tiene los privilegios del superusuario. El nombre de usuario root es simplemente convencional.

Hay que sospechar inmediatamente de cualquier cuenta que aparezca en el sistema con UID 0 que no haya sido creada por el administrador. Estas cuentas se aaden con frecuencia por personas que penetran en las computadoras como una manera sencilla de obtener privilegios de superusuario en el futuro.

La cuenta root no se ha diseado para que el administrador la use como cuenta personal. Debido a que se inhabilitan todas las pruebas de seguridad para el superusuario, un error tipogrfico fcilmente puede destruir todo el sistema.

Con frecuencia el administrador de un sistema UNIX tendr que convertirse en superusuario para llevar a cabo funciones administrativas. Este cambio de estado se puede lograr mediante el comando su para crear un intrprete de comandos privilegiado. Cuando de tiene la capacidad del superusuario se deben tomar precauciones extremas. Cuando cese la necesidad de tener este tipo de acceso, el administrador debe cerrar el intrprete de comandos privilegiado.

Cualquier proceso que tiene UID efectivo 0 se ejecuta como si fuera el superusuario, es decir, cualquier proceso con UID 0 se ejecuta sin verificaciones de seguridad y puede hacer prcticamente lo que sea. Las verificaciones y controles de seguridad se ignoran en el caso del superusuario aunque la mayor parte de los sistemas s registran en las bitcoras y auditan algunas de las acciones del superusuario.

El usuario es la principal debilidad de seguridad del sistema operativo UNIX. Dado el privilegio del superusuario, las personas que penetran en un sistema UNIX tratan de convertirse en el superusuario.

Para evitar este problema con el superusuario, se ha intentado varias veces disear un sistema UNIX seguro (que cumpla todos los requisitos para un sistema altamente confiable) adoptando la estrategia de dividir los privilegios del superusuario en muchas categoras. Lamentablemente estos intentos a menudo fallan. Casi siempre, muchos de los privilegios en los que se divide el superusuario pueden usarse para obtener los dems. Se cambia un gran fallo de seguridad por otros ms pequeos que llevan al mismo final.

3.2.9.- El comando su

A veces un usuario debe tomar la identidad de otro. Pos ejemplo si se desea acceder a archivos propios estando sentado delante el terminal de un amigo. En lugar de cerrar la sesin del amigo e iniciar una propia, UNIX permite cambiar temporalmente el nmero de identificacin de usuario. El comando que lo permite se llama su,que son las iniciales de substitute user (sustituir usuario). su requiere que se use la contrasea del usuario al que se est cambiando.

Los procesos en sistemas UNIX tienen al menos dos identidades en cada momento. Normalmente estas dos identidades son la misma. La primera identidad es el UID real. El UID real es la identidad verdadera y coincide, normalmente con el nombre de usuario con el que se inici la sesin. A veces se quiere asumir la identidad de otro usuario para acceder a algunos archivos o ejecutar algunos comandos. Esto se puede lograr iniciando una sesin con el otro nombre y obteniendo de esa forma un intrprete de comandos cuyo proceso subyacente tenga un UID igual al del usuario.

Como alternativa, si slo se desea ejecutar algunos comandos con la identidad de otro usuario, se puede emplear el comando su para crear nuevos procesos. Esto ejecutar otra copia del intrprete de comandos que tendr la identidad (UID real) del otro usuario. Para emplear el comando su es necesario conocer la contrasea del otro usuario o ser en ese momento el superusuario.

Si se escribe su sin un nombre de usuario, se indica a UNIX que se quiere convertir en superusuario. Entonces se solicita la contrasea del superusuario. Si la contrasea de root se escribe correctamente, se ejecuta un intrprete de comandos con UID 0. Al convertirse en superusuario, el prompt cambiar por defecto al carcter '#', lo que recordar los nuevos poderes que se han adquirido.

Cuando se usa en comando su para convertirse en superusuario, siempre debe usarse la trayectoria completa del comando /bin/su. Al hacerlo as, se asegura la ejecucin del comando su autntico y de que no se ha ejecutado algn otro comando su que se encuentre en la trayectoria de bsqueda. Esto es una manera importante de protegerse y proteger la contrasea del superusuario contra algn caballo de Troya.

Es recomendable invocar al comando su con un argumento simple en forma de guin cuando se quiere convertir en superusuario:

$ /bin/su -

De esta forma, su invoca al intrprete de comandos de forma que este lea todos loa archivos de configuracin necesarios y simule un inicio de sesin. Esto es importante porque as se evita que la trayectoria de bsqueda (PATH) sea la del usuario que invoco su y no la del superusuario.

Algunas versiones del UNIX de tipo Berkeley no permiten usar su a ninguna cuenta que no sea miembro del grupo wheel. Sin embargo la versin de su de GNU no utiliza esta caracterstica. Esta es la explicacin de Richard Stallman sacada de la propia pgina de manual de su.

A veces, algunos listillos intentan hacerse con el poder total sobre el resto de usuarios. Por ejemplo, en 1984, un grupo de usuarios del laboratorio de Inteligencia Artificial del MIT decidieron tomar el poder cambiando el password de operador del sistema Twenex y mantenindolo secreto para el resto de usuarios. (De todas maneras, hubiera sido posible desbaratar la situacin y devolver el control a los usuarios legtimos parcheando el kernel, pero no sabra como realizar esta operacin en un sistema UNIX.)

Sin embargo, casualmente alguien cont el secreto. Mediante el uso habitual de su una vez que alguien conoce el password de root puede contrselo al resto de usuarios. El grupo "wheel" har que esto sea imposible, protegiendo as el poder de los superusuarios.

Yo estoy del lado de las masas, no de los superusuarios. Si eres de los que estn de acuerdo con los jefes y los administradores de sistemas en cualquier cosa que hagan, al principio encontrars esta idea algo extraa.

Muchas versiones registran los intentos fallidos del comando su. Las versiones ms viejas de UNIX enviaban explcitamente a la consola los avisos de los intentos fallidos de su y tambin los colocaban en el archivo /var/adm/messages. Las versiones ms modernas registran los intentos fallidos de usar su a travs del programa syslog, el cual permite enviar los mensajes que se quieran a un archivo especfico o anotarlos en bitcoras que estn en computadoras remotas a travs de la red.

3.3.- El sistemas de ficheros de UNIX

3.3.1.- Introduccin

El sistema de ficheros de UNIX controla el modo en el que la informacin se almacena en el disco y otras formas de almacenamiento secundarias. Dentro del sistema UNIX todo son archivos: desde la memoria fsica del equipo hasta el ratn, pasando por modems, teclado, impresoras o terminales. Por esto, una correcta utilizacin de los permisos, atributos y otros controles sobre ficheros es vital para la seguridad de un sistema.

El sistema de ficheros proporciona las herramientas bsicas para el administrador, pero tambin para el atacante, sea este voluntario, un fallo de un usuario o de un programa. Ya que en UNIX todos los objetos son elementos del sistema de ficheros (a partir de aqu archivos o ficheros, indistintamente), un error en un permiso puede facilitar la escritura de cualquier usuario en un disco o en un directorio importante, la consecucin de un shell privilegiado, o la posibilidad de que un usuario 'vea' la memoria de todos los dems usuarios(y la del sistema).

3.3.2.-Tipos bsicos de archivos.

En un sistema UNIX existen tres tipos bsicos de archivos: ficheros planos, directorios y ficheros especiales (dispositivos). Tambin existen otros tipos de archivos como los enlaces simblicos, los sockets o las tuberas, pero no se tratarn aqu.

Ficheros planos: Son secuencias de bytes, que a priori no poseen ni estructura interna ni contenido significante para el sistema, su significado depende de las aplicaciones que interpretan su contenido.

Directorios: Son archivos cuyo contenido son otros ficheros de cualquier tipo (planos, otros directorios y otros ficheros especiales).

Ficheros especiales: Son archivos que representan dispositivos del sistema. Se dividen en dos grupos: los dispositivos orientados a carcter y los orientados a bloque. La principal diferencia entre ambos es la forma de realizar operaciones de entrada/salida:mientras que los dispositivos orientados a carcter la realizan byte a byte (esto es, carcter a carcter ), los orientados a bloque la realizan en bloques de caracteres .

3.3.3.- Inodos o nodos indice

Para cada objeto en el sistema de ficheros, UNIX guarda informacin administrativa en una estructura llamada inodo. Los inodos residen en

el disco y no tienen nombre, en vez de ello, tienen indices (nmeros) que indican su posicin en un arreglo de inodos. Un inodo es una estructura de datos que relaciona un grupo de bloques de un dispositivo con un determinado nombre del sistema de ficheros.

Cada inodo generalmente contiene lo siguiente:

La ubicacin del contenido del tem en el disco, si existe .

El tipo del tem (es decir, archivo, directorio, enlace simblico, etc.)

El tamao total del tem, en bytes, si esto se aplica.

La fecha de la ltima modificacin del archivo del inodo (el ctime).

La fecha de la ultima modificacin del contenido del archivo del inodo (el mtime).

La fecha del ultimo acceso al archivo (el atime) para read(), exec(),etc.

El numero de enlaces fsicos que tiene ese archivo.

Tamao de bloque para el sistema de ficheros de E/S

Numero de bloques asignados.

Tipo de dispositivo

El dueo del archivo (UID).

El grupo del archivo (GID).

Los bits de proteccin.

Estos tres ltimos, que se guardan para cada archivo, junto con la informacin UID/GID del proceso que se ejecuta, son los datos fundamentales que se emplean en UNIX para controlar el acceso de los usuarios a los archivos, y por lo tanto, prcticamente para toda la seguridad del sistema operativo.

3.3.4.- Fechas de los archivos.

Las fechas que aparecen al ejecutarse la instruccin ls -l son las fechas de modificacin de los archivos (mtime). Se puede obtener la fecha del ultimo acceso (atime) usando la opcin -u (escribiendo, por ejemplo, ls -lu). Ambas fechas se pueden cambiar usando una llamada a una rutina de la biblioteca del sistema. Por lo tanto, los administradores deben adquirir el habito de verificar la fecha de cambio del inodo (ctime) usando la opcin -c. Por ejemplo, ls -lc. Bajo circunstancias

normales, no se puede cambiar el ctime de un archivo. El sistema operativo lo actualiza cada vez que hay un cambio en el inodo del archivo.

Puesto que el inodo cambia cuando se modifica un archivo, ctime indica la fecha de la ultima escritura, cambio de proteccin o cambio de dueo. Un agresor puede cambiar el mtime o el atime de un archivo, pero normalmente el ctime ser correcto.

Un agresor listo, que adquiere privilegios de superusuario, puede cambiar el reloj del sistema y luego aplicar touch al inodo, forzando as que aparezca un ctime engaoso en el archivo. Ademas el agresor puede cambiar el ctime escribiendo directamente al disco, evitando el uso de las verificaciones del sistema operativo completamente. Si usa Linux, con el sistema de archivos ext2, un agresor puede modificar el contenido del inodo directamente usando la instruccin debugfs.

Si la cuenta del superusuario del sistema ha sido comprometida no se puede asumir que ninguna de las tres fechas que se almacenan para cada archivo o directorio sean correctas. Por esta razn, no se puede basar el control de archivos en las fechas.

3.3.5.- Permisos de un archivo

Los permisos de un archivo pueden verse en cada lnea (los diez primeros caracteres) del listado al ejecutar la orden ls -l. Indican qu es el archivo y qu tipo de acceso otorga (es decir, la posibilidad de leer, escribir o ejecutar ) a los diversos usuarios del sistema.

He aqu dos ejemplos de permisos de archivo:

drwxr-xr-x

-rwsr-sr-x

El primer smbolo del campo de modo del archivo indica el tipo del archivo, como se explica en la siguiente tabla:

Contenido Significado

- Archivo plano

d Directorio

c Dispositivo de tipo carcter (tty,impresora, ...)

b Dispositivo de bloque (disco, CD-Rom, etc.)

l Enlace simblico

s Socket

= o p FIFO

Los siguientes nueve smbolos tomados en grupos de tres indican quin y qu tipo de operaciones se pueden hacer con los archivos en la computadora. Hay tres tipos de permisos:

r permiso de lectura w permiso de escritura x permiso de ejecucin

De manera anloga, existen tres clases de permisos:

owner propietario del archivo group usuarios que estn en el grupo del propietario other todo el mundo (excepto el superusuario)

En el siguiente grfico se muestra como interpretar los distintos privilegios:

Los permisos de lectura,escritura y ejecucin tienen los siguientes significados especficos:

r (READ): El permiso de lectura quiere decir exactamente eso: el archivo se puede abrir con la llamada de sistema open() y su contenido puede leerse con read().

w (WRITE): El permiso de escritura permite sobreescribir con uno nuevo o modificar su contenido. Tambin se puede usar write() para hacerlo mas grande y truncate() o ftruncate() para hacerlo ms corto.

x (EXECUTE):Este permiso slo tiene sentido en el caso de programas. Si un archivo tiene los bits de ejecucin habilitados, se puede ejecutar escribiendo su trayectoria (o ejecutndolo con algn miembro de la familia de llamadas del sistema exec()). La manera en que se ejecuta el programa depende de los dos primeros bytes del archivo. Se supone que los dos primeros bytes de un archivo ejecutable son un nmeros mgico que indica la naturaleza del archivo. Algunos nmeros significan que el archivo es algn tipo de archivo binario en lenguaje maquina. La secuencia especial de dos bytes #! significa que es un guin ejecutable de algn modo. Si los valores son desconocidos se supone que es un guin de interprete de instruccin y se ejecuta de esa manera.

Los permisos de un archivo se aplican a los dispositivos y a los sockets con nombre del mismo modo que a los archivos normales. Si se tiene permiso de escritura se puede escribir informacin al archivo o al objeto. Si se tiene permiso de lectura se puede leer el contenido. Y si no se tienen ninguno de estos permisos, mala suerte.

Los permisos de archivo no se aplican a los enlaces simblicos. El que se pueda o no leer de un archivo al que apunta un enlace simblico depende de los permisos propios del archivo, y no de los permisos del enlace. De hecho, los enlaces simblicos casi siempre se crean con los permisos rwxrwxrwx (en modo 0777, en octal) y el sistema operativo no los usa para nada.

Las siguientes consideraciones sobre los permisos de un archivo son importantes:

Se puede tener permiso de ejecucin sin tener permiso de lectura. En ese caso se puede ejecutar un programa pero no leerlo. Esto es til si se desea ocultar el contenido de un programa. Otra forma de usar esto es permitir a los usuarios emplear el programa pero no copiarlo (salvo en servidores de ficheros NFS, que no distinguen este caso, pues para ejecutar un archivo este debe ser enviado al cliente).

Si se tiene permiso de lectura pero no de ejecucin, se puede hacer una copia del archivo y ejecutarla. No obstante, la copia ser distinta principalmente en dos maneras. Tendr una trayectoria absoluta diferente y ser propiedad de quien la haya copiado y no del dueo original del programa (esto se importante en los archivos con el bit SUID o SGID activado).

En algunas versiones de UNIX (incluyendo Linux) un guin de instrucciones ejecutable debe tener los bits de lectura y ejecucin habilitados para que sea posible ejecutarlo.

Los permisos de un archivo se pueden cambiar con la instruccin chmod o con las llamadas al sistema chmod() y fchmod(). Slo el dueo de un archivo puede cambiar los permisos. La nica excepcin a esta regla es el superusuario: si alguien est en una sesin de superusuario puede cambiar los permisos de cualquier archivo.

Los administradores expertos, prefieren usar chmod especificando los permisos en octal. Al usuario inexperto puede parecerle incmodo, pero una vez que se aprende, es mucho ms rpido. Los permisos de un archivo estn representados por doce bits, un bit por cada permiso, estos permisos son la interpretacin en octal del nmero binario resultante de poner a uno el permiso deseado y a cero los dems. La siguiente tabla, resume los diferentes permisos en octal:

Octal Permiso

4000 SUID --S------ 100000000000

2000 SGID -----S--- 010000000000

1000 Bit adhesivo(sticky) --------T 001000000000

0400 Lectura por el dueo r-------- 000100000000

0200 Escritura por el dueo -w------- 000010000000

0100 Ejecucin por el dueo --x------ 000001000000

0040 Lectura por el grupo ---r----- 000000100000

0020 Escritura por el grupo ----w---- 000000010000

0010 Ejecucin por el grupo -----x--- 000000001000

0004 Lectura por otros ------r-- 000000000100

0002 Escritura por otros -------w- 000000000010

0001 Ejecucin por otros --------x 000000000001

El clculo del valor octal que representa los permisos que se desean, se realiza efectuando un OR o suma (en este caso es lo mismo) de los valores de los permisos, o convirtiendo a octal el binario correspondiente a esos permisos, si se est acostumbrado.

Dada la importancia de los permisos, UNIX provee una utilidad, llamada umask, que permite especificar los permisos de creacin por defecto. Realmente, el argumento que acepta umask es una mscara en octal con los permisos que no se quieren asignar a los archivos nuevos. El valor ms usual es 022, que elimina el permiso de escritura para el grupo y otros.

Cuando los permisos de archivo se aplican sobre un directorio, estos tienen significados especiales:

r: Se permite usar las funciones opendir() y readdir() (o el comando ls) para buscar qu archivos estn en el directorio.

w:Se puede aadir, renombrar o quitar entradas en ese directorio.

x: Se puede emplear stat al contenido del directorio (es decir, se puede determinar quines son los dueos y cules son los tamaos de los archivos que estn en el directorio). Tambin se requiere permiso de ejecucin a un directorio para convertirlo en directorio actual o para abrir archivos que estn dentro de ese directorio (o en cualquiera de sus subdirectorios).

3.3.6.- SUID, SGID y los bits adhesivos

Muchos programas, como su, basan su funcionamiento en el uso de los bits SUID y SGID. Para entender completamente como maneja UNIX esta tcnica es imprescindible conocer los conceptos de UID real, UID efectivo y UID guardado.

UNIX almacena para todos los procesos que ejecuta dos identificadores bsicos de usuario: UID real y UID efectivo. Para un proceso normal, resultante de la ejecucin de un programa que no es SUID, los dos identificadores son el mismo e iguales al UID del proceso que lo gener.

Esto resulta ms sencillo con un ejemplo: cuando un usuario inicia una sesin, el proceso login verifica la identidad del usuario en el fichero /etc/passwd y genera un shell con UIDs real y efectivo iguales al del usuario. Cuando el usuario ejecuta cualquier programa que no sea SUID, sea suyo o no, sobre el que por supuesto debe tener permiso de ejecucin, el proceso creado hereda los UIDs del shell. Este comportamiento se mantiene si este proceso crea otros procesos, que a su vez pueden crear otros procesos, y as sucesivamente. Pensemos, por ejemplo, en un usuario que teclea bash continuamente, todos los shell creados tendrn los mismos UIDs.

De esta manera, si no tenemos en cuenta la existencia del bit SUID, bastara con un UID que identificara al usuario durante toda la sesin, puesto que no hay forma de que el usuario cambie el UID de un proceso.

El problema es que UNIX utiliza el UID efectivo del proceso (Linux utiliza un cuarto identificador, el FSUID) para analizar los privilegios que este tiene sobre el sistema de ficheros. Pero un usuario necesita escribir en archivos que no le pertenecen: para cambiar su contrasea necesita escribir en /etc/passwd, para imprimir debe dejar sus archivos en un directorio de spool, y multitud de tareas ms.

Si no se hubiera implementado ninguna manera de alterar esto, slo habra una forma de que el usuario escribiera en directorios y archivos que no le pertenecen: darle permiso sobre estos y, por extensin, a todos los usuarios del sistema. Pero esto es imposible, acabara con el sentido de la proteccin en el sistema de ficheros y con la seguridad de UNIX.

Para evitar estos problemas, UNIX permite que los programas tengan privilegios. Los procesos que ejecutan estos programas pueden adquirir un UID o GID distinto al propio cuando se estn ejecutando. Un programa que cambia su UID se llama programa SUID, y un programa que cambia su GID se llama programa SGID. Un programa puede ser SUID y SGID al mismo tiempo.

Cuando se ejecuta un programa SUID, su UID efectivo se convierte en el del dueo del archivo, en lugar del UID del usuario que lo est ejecutando. Este concepto es tan ingenioso que AT&T (Dennis Ritchie) lo patent, aunque despus la patente ha sido transferida al dominio pblico.

En el siguiente grfico se muestra como interpretar los distintos privilegios:

SUID: Un proceso que ejecuta un programa SUID obtiene un UID efectivo que es el del dueo del programa.

SGID: Un proceso que ejecuta un programa SGID tiene su GID efectivo cambiado al GID del programa. Los archivos creados por el proceso tambin pueden tener su grupo primario establecido a este GID, dependiendo de los permisos del directorio donde se crean los archivos. En las versiones de UNIX derivadas de Berkeley (tambin en Linux), un proceso que ejecuta un programa SGID adquiere tambin el GID del programa temporalmente, el cual se coloca en la lista de GID del proceso. Solaris y otros UNIX derivados de System V usan el bit de GID de los archivos de datos para habilitar el bloqueo obligatorio de archivos.

Adhesivo: Est obsoleto en lo que se refiere a archivos, pero se usa para directorios. Cuando un archivo ejecutable tena el bit adhesivo activado, significaba que deba permanecer en memoria principal el mayor tiempo posible. Esto mejoraba el rendimiento en computadores con una cantidad muy limitada de memoria RAM (sobre 64K, incluso). Pero esto ya no tiene mucho sentido. Sin embargo, si un directorio tiene activado el sticky bit (bit adhesivo o de permanencia), significa que aunque varios usuarios tengan permiso de escritura en l, slo el propietario del archivo y el superusuario pueden borrar un archivo. Esto es til en directorios donde pueden escribir muchos usuarios, pero no se desea que los usuarios se borren archivos unos a otros,como en /tmp o en un directorio de spool.

El bit SGID en directorios tambin tiene un comportamiento particular. Si est activado, los archivos de usuario que se crean en ese directorio, tendrn el mismo GID que el directorio, si el usuario tambin est en ese grupo. Si el usuario no est en el grupo del directorio, los archivos se crean con el GID del usuario (por lo general el primario), como es normal.

Es importante sealar que para activar estos permisos, tambin debe darse el permiso de ejecucin correspondiente, es decir, ejecucin para el propietario para el bit SUID, ejecucin para el grupo para el bit SGID y ejecucin para otros para el bit adhesivo. Si no se hace as, el bit correspondiente aparecer en maysculas (S o T) y no en minsculas (s o t), lo que indica que el bit est establecido pero no tendr efecto.

Esta caracterstica que hace que UNIX sea tan verstil, es tambin uno de los mayores problemas de seguridad.

Cualquier usuario puede convertirse en superusuario simplemente ejecutando una copia SUID de bash que sea propiedad del root. Afortunadamente, slo el superusuario puede realizar esta copia. Por lo tanto, uno de los objetivos del administrador ser evitar que existan este tipo de archivos en la computadora.

Si se deja un terminal sin vigilancia, cualquiera puede apoderarse de la cuenta simplemente introduciendo las siguientes instrucciones:

% cp /bin/bash /tmp/trampa

% chmod 4755 /tmp/trampa

%

Estas instrucciones crean una copia SUID del programa bash. Cada vez que el agresor ejecute este programa se convierte en el usuario, con pleno acceso a los archivos y privilegios. Se supone que el usuario tiene algn archivo interesante para el agresor, privilegios que le

permitan acceder al superusuario, o quiere suplantarle para alguna actividad delictiva, en el peor caso el usuario ser el propio root.

El agresor podra copiar ese programa en un directorio oculto que slo el superusuario, buscando archivos de este tipo, podra encontrar. Pero no todos los administradores realizan esta tarea con regularidad.

Es importante notar que el programa no tiene porque ser un interprete de comandos, un simple editor de textos SUID puede permitir al agresor modificar archivos o incluso crear un interprete de comandos que se ejecute con el UID del usuario (vi lo permite con el comando shell).

La mayor parte de los programas SUID de un sistema son SUID de root, es decir, se convierten en el superusuario cuando se ejecutan. Tericamente, esto no es un fallo de seguridad, porque un programa compilado nicamente puede llevar a cabo las funciones para las que fue compilado (se puede cambiar la contrasea propia usando passwd, pero no se puede cambiar la contrasea de otro usuario). Pero se han encontrado muchos fallos de seguridad creados por gente que se las ha ingeniado para lograr que un programa SUID haga algo para lo que no fue diseado. En muchos casos programas que son UID de root podran haberse diseado para ser SUID de otra cuenta (como daemon). Con demasiada frecuencia se usa SUID de root cuando sera suficiente con privilegios menores.

Un ejemplo de programa SGID con un fallo de seguridad es el programa write. Como write permite escribir en el terminal de otro usuario, este programa es SGID de tty. Esto permite que write escriba nuestro texto en el otro terminal. El fallo es que write permita que el usuario ejecute cualquier instruccin escribiendo el carcter '!' al principio de una lnea. El programa ejecutado heredara el GID efectivo de tty, lo que permitira al usuario, por ejemplo, 'escuchar' los terminales de otros usuarios. En la actualidad, el programa write sigue siendo SGID de tty, pero cambia el GID de tty al del usuario antes de ejecutar el shell (ms adelante se ver como se consigue esto) y luego lo restablece al de tty. En algunas versiones, esta caracterstica est deshabilitada.

Otro ejemplo, esta vez de SUID, era el programa /usr/lib/preserve, que realizaba las copias de seguridad para los editores vi y ex. Para poder hacer copias de seguridad en el directorio, el programa era SUID de root, de forma que el directorio estaba protegido contra la lectura por parte de los usuario (quizs alguien estuviera editando algo importante y no se poda permitir que lo leyera cualquiera). Haba tres detalles que hicieron que el programa fuera un fallo de seguridad:

Era SUID de root

Ejecutaba /bin/mail como root para avisar a los usuarios de que su archivo estaba copiado

Ejecutaba el programa mail con la llamada al sistema system()

El problema era que system() usa sh para leer la cadena que ejecuta. Hay una variable del intrprete de comandos, llamada IFS (separador interno de campos), que sh utiliza para ubicar las separaciones entre las palabras de cada lnea que lee. Normalmente IFS es el espacio en blanco, pero si se estableca IFS como '/' entonces, al llamar a /bin/mail se estaba llamando en realidad a un programa llamado bin del directorio actual, pero con privilegio de root. El resto es fcil, haciendo una copia de un shell en el directorio actual y llamndola bin, bastaba con ejecutar vi para convertirse en root.

El problema era que el programa preserve tena ms privilegios de los necesarios. La norma del privilegio mnimo establece que los programas (y usuarios) tengan los privilegios imprescindibles para realizar su labor, y no ms. En este caso, habra bastado con hacer a preserve SGID del grupo preserve, creado expresamente. Esto no hubiera eliminado el fallo, pero lo habra minimizado. El agresor slo podra leer las copias de los trabajos de otros usuarios.

Las versiones actuales de sh no toman en cuenta IFS si se ejecuta en modo root o si el UID efectivo es diferente del real.

El problema de los bits SUID y SGID est muy unido al ataque basado en la tcnica del desbordamiento de pila (buffer overflow), que se tratar ms adelante.

3.3.6.1.- Cambio de UID: setuid()

Con el objeto de facilitar la programacin de utilidades seguras, UNIX proporciona una serie de funciones que permiten cambiar entre los UID real, efectivo y guardado. Como se ha visto en el ejemplo de write, para que la aplicacin pueda ejecutar una orden del usuario sin peligro para la seguridad, esta debe cambiar al GID del usuario antes de ejecutarla y luego restablecer el GID anterior.

Una solucin para esto podra ser permitir el cambio entre los UID efectivo y real (o entre los GID efectivo y real, el funcionamiento es el mismo) de forma que durante la ejecucin de esa parte del proceso (o la de sus hijos, si es el caso) se perdieran los privilegios que se tenan.

Veamos un ejemplo:

Si el usuario 501 ejecuta el programa write, ste tiene GID real 501(usuario) y GID efectivo 5(tty). Al introducir una lnea que

comienza por '!', el programa write detecta que tiene que ejecutar un comando: para ello primero intercambia los GID, quedando GID real 5(tty) y GID efectivo 501(usuario) y despus ejecuta el comando.

Ahora, el comando ha heredado los GID (y los UID) de write, pero ya no tiene el GID efectivo de tty sino 501, el del usuario. Despus, write puede volver a intercambiar los GID y continuar su ejecucin normalmente.

Esto tiene un fallo: nada impide al proceso del usuario volver a intercambiar los GID, y recuperar los privilegios anteriores.

Para solucionar definitivamente este problema, UNIX utiliza la familia de funciones setuid() y setgid(). Estas funciones utilizan un tercer UID llamado UID guardado o salvado. El cambio a un UID/GID real o efectivo slo est permitido si el proceso posee ese UID/GID como UID/GID efectivo, real o guardado. Slo un proceso con UID 0(root) puede cambiar a cualquier otro UID/GID.

En el ejemplo anterior (nuevamente, el funcionamiento es igual con el UID), write puede establecer el GID efectivo a 501(usuario) dejando el GID real como estaba (501(usuario)), quedando como GID guardado el 5(tty). De esta forma, el proceso generado hereda estos dos GID, pero no el guardado, y no puede cambiar otra vez al GID 5(tty) puesto que no lo tiene.

Pero write s puede restablecer el GID efectivo a 5(tty), puesto que se es el GID guardado. Esta vez todo se ha hecho de forma segura, y el agujero de seguridad de write ha desaparecido.

Este es el funcionamiento de las diferentes funciones que permiten realizar estos cambios (por lo menos, en su versin Linux):

getuid(void): Devuelve el UID real del proceso actual.

geteuid(void): Devuelve el UID efectivo del proceso actual.

setuid(uid_t uid): (POSIX) Establece el UID efectivo del proceso en curso. Si el UID efectivo del proceso que las llama es 0(root) o si el proceso es SUID de root, se establecen tambin los UID real y guardado. Esto impide a un proceso del root que deja sus privilegios que los recupere ms tarde.

setreuid(uid_t ruid,uid_t euid) (BSD): Establece el UID real y el efectivo del proceso en curso. Un valor de -1 para el UID real o efectivo fuerza al sistema a dejar dicho ID sin cambios. Si el UID real es cambiado, o el UID efectivo se pone a un valor

distinto del UID real previo, el UID guardado tomar en valor del nuevo UID efectivo.

seteuid(uid_t euid) (BSD): Es funcionlmente equivalente a setreuid(-1, euid).

getgid(void): Devuelve el GID real del proceso actual.

getegid(void): Devuelve el GID efectivo del proceso actual.

setgid(gid_t gid) (POSIX): Establece el GID efectivo del proceso en curso. Si el GID efectivo del proceso que las llama es 0(root) o si el proceso es SGID de root, se establecen tambin los GID real y guardado. Esto impide a un proceso del root que deja sus privilegios que los recupere ms tarde.

setregid(gid_t rgid, gid_t egid) (BSD):Establece el GID real y el GID efectivo del proceso en curso. Un valor de -1 para el GID real o efectivo fuerza al sistema a dejar dicho ID sin cambios. Si el GID real es cambiado, o el GID efectivo se pone a un valor distinto del GID real previo, el GID guardado tomar el valor del nuevo GID efectivo.

setegid(gid_t egid) (BSD): Es funcionlmente equivalente a setregid(-1, egid).

3.3.7.- Listas de control de acceso (ACLs)

Algunas versiones de UNIX permiten usar listas de control de acceso (ACL, Access Control Lists). stas se ofrecen normalmente como extensiones a los modos de permisos de archivo estndar de UNIX. Usando ACLs se pueden especificar derechos adicionales de acceso para cada archivo y directorio a muchos usuarios en individual, en lugar de tener que hacerlo colocando a todos en un grupo nuevo o en la categora 'otros'. Tambin se pueden asignar permisos distintos a grupos diferentes. Se trata de una caracterstica que se popularizar en los prximos aos. Lamentablemente cada proveedor las ha implementado de forma diferente.

Las ACLs permiten refinar la capacidad de otorgar permisos de archivo que tiene el UNIX estndar. Permiten la especificacin completa del acceso a subconjuntos completamente arbitrarios de usuarios y/o grupos de usuarios. Tanto AIX como HP-UX ofrecen listas de control de acceso. Solaris y Linux supuestamente las ofrecern en versiones futuras.

Para muchos propsitos las ACLs son mejores que el mecanismo de grupos que ofrece UNIX a proyectos de colaboracin pequeos. Si Ana quiere darle a Miriam, y slo a Miriam, acceso a un archivo en particular, puede modificar la ACL del archivo para otorgrselo. Sin

ACLs Ana tendra que acudir al administrador del sistema, pedirle que cree un grupo nuevo que tuviera como miembros tanto a Ana como a Miriam (y slo a ellas) y luego cambiar el grupo del archivo para otorgar privilegios al nuevo grupo.

3.3.8.- Archivos de dispositivo

Como ya se ha comentado antes, todos los dispositivos en UNIX se representan como archivos normales. En el inodo se especifica que se trata de un dispositivo, el tipo de dispositivo, y su nmeros de dispositivo principal y secundario que permiten al sistema identificar al dispositivo.

El hecho de que los dispositivos sean archivos, da a UNIX una gran flexibilidad y unifica el acceso a los dispositivos, de forma que los programadores pueden desarrollar sus programas sin saber el tipo de dispositivo que se va a utilizar.

Pero esto tambin representa un problema de seguridad. Si un usuario consigue acceso sin restricciones a un archivo de dispositivo, podr hacer lo que quiera con l. Si es un terminal, podr leer lo que otro usuario escribe, si es un disco, podr escribir y leer en cualquier sitio, si es el dispositivo kmem, podr cambiar su UID o bloquear el sistema escribiendo basura en el rea de memoria reservada para ste.

UNIX agrupa todos los archivos de dispositivo en el directorio /dev. Por esta razn es muy importante que el administrador revise peridicamente los permisos de estos archivos. Unos pocos dispositivos deben permitir el acceso a todos los usuarios, como /dev/null o /dev/tty. Pero casi todos los dems no deben permitir lectura ni escritura por los usuarios normales. Tambin se debe revisar el sistema en busca de archivos de dispositivo creados por un intruso en cualquier parte del sistema de ficheros, y que podra darle acceso a este dispositivo.

3.3.9.- Sistemas de ficheros montados

Para poder acceder de forma uniforme a distintos tipos de sistemas de ficheros, UNIX incorpora una capa superior de abstraccin denominada VFS, Virtual File System o Sistema de Ficheros Virtual, que se ocupa de proporcionar este acceso uniforme a diferentes tipos de sistemas de ficheros.

Montar un sistema de ficheros consiste en asociar un determinado nombre de directorio (punto de montaje) con el sistema de ficheros en cuestin. A partir de ese momento el sistema de ficheros montado podr ser utilizado de forma normal por los usuarios. Es habitual en grandes sistemas UNIX montar diferentes partes de la estructura de directorios estndar (por ejemplo /home o /usr) en distintos dispositivos. Esto no presenta ningn problema de seguridad, puesto

que estos sistemas se montan cada vez que se inicia el sistema, normalmente son necesarios para el funcionamiento normal del sistema.

Pero para utilizar discos removibles, CD-ROMs o sistemas de ficheros en red (NFS) no queda ms remedio que montarlos como parte del sistema de ficheros. Esto si que representa un problema de seguridad. Estos sistemas de ficheros pueden contener archivos ejecutables (por ejemplo un shell con SUID de root) que pueden comprometer la seguridad del sistema.

Para evitar estos problemas, el archivo de configuracin fstab, que almacena la forma en que se montan los distintos dispositivos, y el comando mount, que se encarga de montarlo, aceptan una serie de opciones que protegern nuestro sistema. Estas opciones son:

auto/noauto: Puede o no montarse con la opcin -a (se montan todos automticamente)

dev/nodev: Interpreta o no dispositivos especiales

exec/noexec: Permite o no la ejecucin de binarios

rw/ro: El sistema de ficheros de monta como de lectura/escritura o como slo lectura.

suid/nosuid: Permite o no el efecto de los bits SETUID y SGID

user/nouser: Permite o no que los usuarios ordinarios monten el sistema de ficheros. La opcin user implica noexec, nosuid y nodev a menos que se indique lo contrario explcitamente.

sync: Toda E/S ha de realizarse de forma sncrona.

Esta opciones bien utilizadas impiden que un usuario monte un sistema de ficheros que pueda contener peligros como un dispositivo que apunte a nuestro disco (y sobre el que tenga permisos), un shell SUID de root y peligros similares. En muchos sistemas es habitual que slo el superusuario pueda montar sistemas de ficheros, incluso que slo l tenga acceso fsico a los dispositivos.

4.- Mantenimiento de sistemas confiables

4.1.- Introduccin

En este tema, se tratan las principales labores a realizar por parte del administrador, para mantener un sistema seguro, as como las tcnicas mas utilizadas para evitar la prdida de datos y para responder a los ataques de los intrusos.

4.2.- Criptografa

Aunque la misin principal de la seguridad en un sistema informtico es mantener la informacin confidencial, en ocasiones, no podemos confiar slo en la seguridad del sistema. Cuando la informacin es demasiado importante, se enva a travs de medios de comunicacin poco confiables o es imposible mantenerla en secreto, no queda ms remedio que recurrir a la criptografa.

En la actualidad, existen multitud de mtodos y aplicaciones criptogrficas. Como no es el objetivo de este trabajo, slo haremos una breve mencin de los diferentes tipos de sistemas criptogrficos y su relacin con el cifrado de contraseas.

Hasta la dcada de los 70, todos los criptosistemas conocidos, funcionaban con una clave de cifrado igual a la de descifrado o, si eran diferentes, una poda obtenerse de la otra en un tiempo y con unos recursos razonables. La invulnerabilidad de tales sistemas dependa, por tanto, del mantenimiento en secreto de la clave. Consiguientemente, deba transmitirse del emisor al receptor a travs de un canal seguro, obviamente diferente del canal del criptosistema, que por hiptesis est amenazado por posibles interceptores.

Estos criptosistemas se denominan de clave secreta, de clave nica y tambin simtricos.

Sin embargo, en 1976, Diffie y Hellman demostraron la posibilidad de conseguir criptosistemas que no precisaban transferir una clave secreta entre el emisor y el receptor, evitando as los problemas inherentes a la bsqueda de canales seguros para tal transferencia, previamente al establecimiento de una transmisin cifrada.

En estos criptosistemas la clave de cifrado, denominada clave pblica, se hace de general conocimiento. Sin embargo la clave de descifrado, denominada clave privada, se mantiene en secreto. Obviamente ambas claves no son independientes, pero del conocimiento de la pblica no se infiere la privada, a no ser que se tenga algn dato adicional que tambin habr que mantenerse en secreto o, mejor, destruirse una vez generado el par clave pblica-clave privada.

Cuando un usuario desea recibir informaciones cifradas, da a conocer a todos los potenciales remitentes su clave pblica. As, stos cifrarn los mensajes destinados al citado usuario con la misma clave, la pblica del destinatario. Sin embargo, no conociendo nadie ms la clave privada, ni pudindola obtener a partir de la pblica, slo el destinatario podr descifrar la informacin a l remitida.

Estos criptosistemas se denominan, de clave pblica o asimtricos, pues del conocimiento de una clave no se deduce la otra.

Todava se puede considerar un ltimo tipo de sistemas de cifrado denominados criptosistemas irreversibles, basados en algoritmos no invertibles. En estos criptosistemas, dado el criptograma no es posible obtener el mensaje en claro. Figuradamente, se puede decir que slo trabajan en un sentido, el que lleva del mensaje en texto claro al texto cifrado, pero no en el contrario, que conduce de este ltimo a aqul.

Estos cifrados se emplean en aplicaciones que no requieren descifrar los criptogramas. Una de estas aplicaciones consiste en la determinacin de si un cierto mensaje se corresponde con un determinado texto cifrado almacenado en un sistema. Para ello el algoritmo de cifrado produce un criptograma, que se compara con el guardado en la memoria. Para esta aplicacin se requiere, adems de que el algoritmo sea no invertible, que sea unvoco, es decir, que dos mensajes distintos produzcan dos cifrados diferentes. Un ejemplo de este tipo de aplicaciones se tiene en el almacenamiento de las contraseas de usuarios de un sistema. El mantenimiento en memoria de las mismas sin cifrar representa un grave riesgo, pues alguien puede averiguarlas y suplantar a los legtimos usuarios. Almacenarlas cifradas mediante criptosistemas de los tipos vistos hasta ahora tambin es inseguro, pues la clave descifrada puede ser conocida por el administrador del sistema (y posiblemente por ms profesionales informticos que trabajen sobre el ordenador), quien con el conocimiento del algoritmo de cifrado y de las contraseas criptografiadas es capaz de averiguar las contraseas en claro.

Por lo anterior, para el almacenamiento de contraseas se emplean algoritmos no invertibles. Cada vez que el usuario introduce su contrasea