-
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