[Solar-general] virus para linux ...?

Mar Abr 11 23:59:04 CEST 2006

On Tue, 11 Apr 2006 18:22:40 -0300
"Nahuel Iglesias" <niglesias en gmail.com> wrote:

NI> Holas!
NI> 
NI> Enrique decía:
NI> 
NI> [...]
NI> >
NI> > Es posible prevenir algunas de estas cosas, o hacerselas más
NI> > difícles al atacante, si uno corre un sistema operativo con control
NI> > mandatorio de acceso (como SE/Linux).
NI> 
NI> Esta no la tenía! ¿Qué es un "sistema operativo con control
NI> mandatorio"?
Trataré de explicarlo lo más simple posible (lo que implica alguna
imprecisión). Aclaremos de movida que SE/Linux implementa un modo
de control mandatorio llamado RBAC (role based access control), y
además un modode control sobre procesos llamado "type enforcement".
Comentaré algo sobre ambos más abajo.

MAC (mandatory access control) es un modelo de seguridad más restrictivo
que DAC (discretionary access control), que es el que normalmente
usamos. En DAC el "dueño" de un objeto cualquiera en el sistema puede
determinar cómo y a quienes da acceso a dicho objeto, por ejemplo con

$ chmod 666 my_fcking_file

En DAC, en cambio, cada objeto en el sistema tiene asignada una
etiqueta que documenta su nivel de sensibilidad (digamos, por
ejemplo. "publico" "reservado" "secreto" "top secret" "top secret
ultra for your eyes only") y existe un conjunto de políticas que
determina cómo acceder a dichos objetos. La política base es, en
general, "no read up, no write down"; un objeto no puede leer 
ningún otro cuyo privlegio sea mayor que el suyo, ni escribir
ninguno cuyo privilegio sea menor que el suyo.

RBAC, que mencionaba más arriba, define un conjunto de roles
(extensible en el caso de SE/Linux). Cada proceso tiene un rol
asociado, lo que asegura que los procesos "privilegiados" pueden
separarse de los de los usuarios comunes. Cada rol de usuario tiene
un dominio inicial asociado con su shell de login. Los archivos de
configuración especifican los dominios a los que cada rol puede 
acceder. A medida que los usuarios ejecutan programas, pueden suceder
transiciones automáticas a otros dominios (requeridas para permitir
los cambios de privilegio), de acuerdo con las policas que se hayan
configurado.

"Type enforcement" define doominios y tipos. Cada proceso pertenece a
un cominio, y cada objeto tiene un tipo. La configuración establece
cómo los cominios pueden acceder a los tipos e interoperar con otros
dominios, especificando qué tipos aplicados a los programas pueden
usarse para entrar a cada dominio y las transciones entre dominios
permitidas.  

NI> > Pero, en síntesis, la respuesta es "no". Todo depende del empeño que
NI> > ponga el atacante, y de lo hábil que sea.
NI> 
NI> Han existido exploits que logran utilizar alguna vulnerabilidad de
NI> algún servidor que se ejecute en la máquina (bind, apache, proftpd).
NI> Lo peligroso es que alguno de estos servicios se ejecute con el
NI> usuario root, entonces de forma remota se podría hacer prácticamente
NI> (dependiendo de la vulnerabilidad) cualquier cosa.

No hace falta atacar "directamente" a root. Ver el caso 2a->3 del
ejemplo del mensaje anterior.

NI> Pero este tipo de "peligros" creo yo que es casi descartable, habida
NI> cuenta del nivel de concientización en los administradores de sistemas
NI> con respecto a estos peligros, que hace 10 años eran casi impensados.
NI> Claro que siempre hay malos administradores, o administradores fiacas
NI> que no actualizan software ni vigilan sus versiones.

¿Oíste alguna vez aquello de "la confianza mata al hombre---"? :)
Yo no sería tan alegre como para sostener que sean "casi descartables".

[...snip...]

NI> Por supuesto que no se puede comparar el nivel de vulnerabilidad de un
NI> servidor con Linux al de una estación de trabajo con IE! es
NI> sorprendente que simplemente "mirando" una página web sepueda ejecutar
NI> software en la PC!!!

Un Windows 2003 bien configurado y administrado es varios órdenes de
magnitud más seguro que un Linux nal administrado y/o configurado.
Usar un S.O. arquitectónicamente "mejor" no es un bálsamo protector
curalotodo, y ese exceso de confianza puede terminar resultando
un tiro por la culata.

Saludos,

Enrique

-- 
``Izena duen guzia omen da.''
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 197 bytes
Descripción: no disponible
Url        : /pipermail/solar-general/attachments/20060411/40253c25/attachment.pgp