On Tue, 11 Apr 2006 16:06:24 +0200 Marcos Guglielmetti Gmail <[email protected]> wrote: [...snip...] MGG> pero, sé un carajo se seguridad, asi que ahí va mi pregunta, ¿podría MGG> un virus diseñado para GNU+Linux no dañar NUNCA jamás de los jamases MGG> una instalación de un sistema si el usuario es no-root al momento de MGG> abrir el fukin virus? Qué intentaría hacer si crease un virus para linux? 0 - Asumir que el usuario no es idiota y jamas de los jamases se conecta a la Internet como root 1 - Infectar a un usuario con pocos privilegios 2a - Abrir un canal en un puerto alto para hacer "call back" a casa (ocasionalmente; no haria falta que fuese permanente, sino que "llamara" de tanto en tanto); o 2b - hacer el viejo y remanido truco de reemplazar un comando por un código malicioso, cambiándole el .bash_profle y el .bashrc. ¿Cuántos son los que ponen /bin/ls para hacer un ls ;)?; o 2c - Instalarle un logger para capturar cosas interesantes y trasmitirlas con el canal descripto en 2a; o 2d - Si fuera muy bruto, hacerle pelota el /home/tu_usuario/ 3 - Continuando con 2a, esperar a que aparezca un exploit para algún agujero explotable en modo local, transmitir el exploit al "agente" que vive en la máquina de la víctima, correrlo, escalar privilegios y listo :"y0u are 0wn3d" Es posible prevenir algunas de estas cosas, o hacerselas más difícles al atacante, si uno corre un sistema operativo con control mandatorio de acceso (como SE/Linux). Pero, en síntesis, la respuesta es "no". Todo depende del empeño que ponga el atacante, y de lo hábil que sea. Saludos, Enrique -- ``Izena duen guzia omen da.''

On Tue, 11 Apr 2006 18:22:40 -0300 "Nahuel Iglesias" <[email protected]> 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.''