-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-02-01 a las 00:16 +0100, Camaleón escribió:
El 31/01/08, Carlos E. R. escribió:
El problema es que sigue faltando algo, y como mi apparmor le ha dado un hipo, no registra en el log los problemas, con lo cual no puedo reparar lo que le falta porque no se que es:
nimrodel:~ # l /var/log/audit/audit.log
- -rw-r--r-- 1 root root 0 Jan 31 01:03 /var/log/audit/audit.log
¿Pero es algo que hace por "diseño" propio o por el "hipo"?
Creo que es un bug nuevo que he descubierto. ¡Miii teessssoooorooooo! Ya te digo, quiero el dvd de platino.
(está mandando los registros de audit al syslog, facilidad kernel; lo he descubierto al rebotar el kernel que acabo de compilar).
Pero una vez que activas un perfil para un proceso, tienes que listar todos y cada uno de los ficheros a los que accede. Si uno no está listado, le prohibe el acceso.
Enga, ya ;-)... ¿y qué sé yo de los procesos que ejecuta un programa o a qué archivos necesita acceder? Yo no soy el programa, y no puedo saberlo... ni apparmor tampoco sabe si se trata de algo bueno o malo :-P
Tú eres la administradora y lo sabes to. Por definición. Si no lo sabes, se aplica el artículo uno.
Mira, la prueba del ocho es que te ha denegado la ejecución de un script inocuo. Y no, no me vale tener que decirle antes que es "inocuo". Esa técnica de cerrar todo (impedir su ejecución) y permitir sólo lo que está definido en el perfil no es práctico...
¿Inocuo un script? Buff...
Pues sí, tienes que decirle que es inocuo. Para eso está el wizzard: se pone el perfil en modo "complain", que es un modo en que deja hacer todo, pero registra todos los accesos y graba lo que hubiera hecho en caso de estar en modo "enforced":
audit(1201825200.730:66): type=1502 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/meminfo" pid=3756 profile="null-complain-profile"
Claro, también puedes permitir accesos por plantilla.
Mira, este es el perfil del sbin.syslog-ng:
#include <tunables/global> /sbin/syslog-ng flags=(complain) { #include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice>
capability chown, capability dac_override, capability fowner, capability fsetid,
/dev/log w, /dev/tty10 rw, /dev/xconsole rw, /etc/syslog-ng/* r, /sbin/syslog-ng mr, /usr/local/bin/syslog-askandlogrouterip rUx, /var/lib/*/dev/log w, /var/log/** w, /var/run/syslog-ng.pid w, }
así de cortito y simple - con una linea añadida. No tiene acceso a nada más. Si de repente trata de acceder a cualquier otro fichero, se le impide porque se ha vuelto loco o lo han crakeado. Hasta que el administrador no diga lo contrario, de esas vallas no sale. Por decreto.
...imagina que te cuelan por e-mail un script que permite alterar los perfiles de apparmor de forma automática, y que da permisos a un programa (que también te cuelan por e-mail) "destructivo"... y el apparmor no se cosca de nada porque está definido en el perfil.
¿Y quien te manda leer el correo como root, de manera que pueda ejecutarse un script que altera ficheros de seguridad? Te mereces lo que te pase >:-)
Y, si estuvieras usando un programa de correo vallado por el apparmor, en plan paranoico, ese script lo capan en vivo. Si es que consigues leer el correo de esa guisa...
Ya está demostrado que el uso de patrones (o firmas, como utilizan los antivirus actuales) no sirve de gran cosa. Hacen falta herramientas "inteligentes" que controlen los procesos de forma "precisa" y en base a parámetros de autoaprendizaje (hum, sí, de tipo bayesiano o semántico).
Y no, no deben "preguntar" nunca al usuario ;-).
Pero es que no hay una herramienta de seguridad universal. Tienes varias cosas: cortafuegos, antivirus, apparmor, políticas... y un segurata vigilando la interfase sentada en la silla.
En que no está en la lista, así de simple.
Ese es el problema, que es muy simple :-). No, entiendo que pueda ser útil y el concepto no es malo.
Si el syslog estuviera comprometido, y el intruso consiguiera lanzar un programa que luego permitiera de alguna forma al intruso lanzar comandos arbitrarios, ese es el agujero de seguridad que el AA tapa: no le deja ejecutar nada que no le hayan dicho de antemano que puede ejecutar.
Ya.
No es el sistema lo que protege, sino aplicaciones concretas. Debes proteger todas las aplicaciones que sirven a la red.
¿Sólo relacionadas con la red? :-?
Así es como lo veo yo. Un usuario tecleando es un peligro invallable, sobre todo si tiene privilegios.
Claro. Pero el concepto fundamental es que sólo protege las aplicaciones concretas que se le dice, y a esas no les deja acceder a ningún fichero que no se le haya dicho, y con los permisos que se le ha dicho.
Entiendo.
Mmmm ¿veo la sombra alargada de guillermito asomarse por ahí? :-P
Y la de los antivirus, cortafuegos y antipsywares... "tos" te preguntan qué tienen que hacer... salvo zypper cuando va a auto-destruirse porque está en modo "best-effort+check_architecture+do_not_disturb_user" y decide por él mismo >:-)
(Es broma :-P)
El guillermito no usa zypper - usa iexplorer :-P
- -- Saludos Carlos E.R.