-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hola:
Quiero ejecutar un programa externo cuando aparezca un mensaje determinado en el syslog.
documentación syslog-ng Destination drivers file() pipe() unix-stream() & unix-dgram() udp() & tcp() usertty() program()
Es decir, puedo enviar una retahila de mensajes a un programa. La documentación de program() está en file:///usr/share/doc/packages/syslog-ng/html/index.html##id2510439 y pone:
program()
This driver executes the specified program with the specified arguments and sends messages to the standard input (stdin) of the child.
The program() driver has a single required parameter, specifying a program name to start. The program is executed with the help of the current shell, so the command may include both file patterns and I/O redirection, they will be processed.
Declaration: program(commandtorun);
Note
The program is executed once at startup, and kept running until SIGHUP or exit. The reason for this is to prevent starting up a large number of programs for messages, which would imply an easy DoS.
Example 3.14. Using the program() destination driver
destination d_prg { program("/bin/cat >/dev/null"); };
Que no es lo que yo busco. Lo que hace es arrancarlo desde el principio y mandarle los mensajes que corresponda; y yo quiero que lo ejecute sólo cuando ocurra el mensaje en cuestión.
En fin.
Entonces parece que tengo que hacer algún programita que esté en un bucle esperando un texto por stdin, y que mientras no reciba ninguna linea esté parado. Y pienso hacerlo con un script.
¿pero como?
¿Que bucle pongo en el script para que espere sin hacer nada hasta que llegue una linea por stdin? Esa es mi duda.
¿Quizás esto? :
#!/bin/bash while true ; do read # hacer mis cosas router_ip | grep 0.8.32 | cut --fields=14-15 | logger done
- -- Saludos Carlos E.R.
2008/1/30 Carlos E. R. robin.listas@telefonica.net:
-----BEGIN PGP SIGNED MESSAGE-----
hola
[...]
¿pero como?
¿Que bucle pongo en el script para que espere sin hacer nada hasta que llegue una linea por stdin? Esa es mi duda.
¿Quizás esto? :
#!/bin/bash while true ; do read # hacer mis cosas router_ip | grep 0.8.32 | cut --fields=14-15 | logger done
mmm.. puedes mirar el codigo de guardian (http://www.chaotic.org/guardian/) este trabaja revisando los logs de snort y caso encontre un patron.. entonces ejecuta un comando !!!
salu2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-30 a las 08:52 -0300, Victor Hugo dos Santos escribió:
mmm.. puedes mirar el codigo de guardian (http://www.chaotic.org/guardian/) este trabaja revisando los logs de snort y caso encontre un patron.. entonces ejecuta un comando !!!
Es una manera, pero se me complica.
Lo que llevo probado es esto en el syslog:
filter f_router_got_ip { host("router") and match("Received valid IP address from server"); };
destination router2 { file("/var/log/router2"); }; log { source(ext); filter(f_router_got_ip); destination(router2); };
Y eso sí funciona, guarda la linea en el fichero "/var/log/router2", luego hasta ahí bien. Si lo cambio el destino (siguiendo la documentación):
destination routerip { program("/usr/local/syslog-askandlogrouterip"); }; log { source(ext); filter(f_router_got_ip); destination(routerip); };
entonces falla, el programa en cuestión no se ejecuta. Algo falla.
El programa está bien, si lo llamo externamente hace lo que debe. Pero el syslog no lo carga: igual no le gusta que sea un script :-(
O no lo han compilado con ese soporte.
:-/
- -- Saludos Carlos E.R.
El 30/01/08, Carlos E. R. escribió:
destination routerip { program("/usr/local/syslog-askandlogrouterip"); }; log { source(ext); filter(f_router_got_ip); destination(routerip); };
entonces falla, el programa en cuestión no se ejecuta. Algo falla.
Si llega a ejecutarlo (o al menos a intentarlo) deberías tener el error grabado en el registro (messages o warn).
¿Has probado a detener apparmor / auditd y ver si de esta forma se ejecuta? Si lo tienes activado y configurado con algún perfil quizá le impida lanzar el script pensando que va a hacer alguna barbaridad :-?
El programa está bien, si lo llamo externamente hace lo que debe. Pero el syslog no lo carga: igual no le gusta que sea un script :-(
Prueba a llamar a algún binario (programa) en lugar del script tuyo, algo que no parezca sospechoso >:-).
O no lo han compilado con ese soporte.
No creo :-/
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-30 a las 15:12 +0100, Camaleón escribió:
El 30/01/08, Carlos E. R. escribió:
destination routerip { program("/usr/local/syslog-askandlogrouterip"); }; log { source(ext); filter(f_router_got_ip); destination(routerip); };
entonces falla, el programa en cuestión no se ejecuta. Algo falla.
Si llega a ejecutarlo (o al menos a intentarlo) deberías tener el error grabado en el registro (messages o warn).
No, (no), no (no, no).
Esa es lal puñetería, que el syslog nunca graba nada de nada sobre si mismo. Nunca sabes porqué falla él, sólo porqué fallan los demás. Y mira que arranqué el daemon en modo debug...
¿Has probado a detener apparmor / auditd y ver si de esta forma se ejecuta? Si lo tienes activado y configurado con algún perfil quizá le impida lanzar el script pensando que va a hacer alguna barbaridad :-?
¡ARGHHHH!
type=APPARMOR_DENIED msg=audit(1201702120.420:26): type=1503 operation="inode_permission" requested_mask="x" denied_mask="x" name="/bin/bash" pid=13448 profile="/sbin/syslog-ng"
¡Bingo!
Ahí está. Joder. (perdón). ¡AHHHHHHHH!
Es que estoy cabreado... ¿se nota? Me han borrado de cuatro listas de suse, con esta y con la dirección de gmail. Acabo de recuperar tu correo del archivo.
El programa está bien, si lo llamo externamente hace lo que debe. Pero el syslog no lo carga: igual no le gusta que sea un script :-(
Prueba a llamar a algún binario (programa) en lugar del script tuyo, algo que no parezca sospechoso >:-).
Ya lo hice:
destination routerip { program("/bin/cat >/dev/null"); };
O no lo han compilado con ese soporte.
No creo :-/
Cosas veredes...
- -- Saludos Carlos E.R.
El 30/01/08, Carlos E. R. escribió:
No, (no), no (no, no).
Esa es lal puñetería, que el syslog nunca graba nada de nada sobre si mismo. Nunca sabes porqué falla él, sólo porqué fallan los demás. Y mira que arranqué el daemon en modo debug...
Bueno, no se trata de que registre un error del propio "syslog" sino de un fallo en la ejecución del script o del programa (por ejemplo, que no lo pudiera ejecutar por un tema de permisos, porque no fuera ejecutable o por pasarle un argumento inválido...).
¡ARGHHHH!
Anda... ¿q'ha pasao?
type=APPARMOR_DENIED msg=audit(1201702120.420:26): type=1503 operation="inode_permission" requested_mask="x" denied_mask="x" name="/bin/bash" pid=13448 profile="/sbin/syslog-ng"
¡Bingo!
Ahí está. Joder. (perdón). ¡AHHHHHHHH!
¿Te lo estaba bloqueando? Jo, oye, y el apparmor ¿no tiene algún "modo debug" que te vaya sacando en una ventanita fija en pantalla lo que deja pasar y lo que no? Porque a ver cómo te enteras si no revisas el registro... para uso diario, vale, el registro es suficiente, pero si estás probando alguna cosa, mejor sería verlo en tiempo real...
Es que estoy cabreado... ¿se nota? Me han borrado de cuatro listas de suse, con esta y con la dirección de gmail. Acabo de recuperar tu correo del archivo.
Sí, ya vi el mensaje en la lista inglesa... ¿qué ha pasado al final?
Saludos,
robin.listas> Es que estoy cabreado... ¿se nota? Me han borrado de cuatro listas de robin.listas> suse, con esta y con la dirección de gmail. Acabo de recuperar tu correo robin.listas> del archivo. robin.listas>
Sip, ayer alguien estuvo toqueteando las configuraciones. En mi caso intentaron dar de baja únicamente mi dirección antigua (que ya había dado yo de baja para hacer el alta de esta). Primero pensé en algún gracioso, pero horas más tarde recibí un correo con ese texto:
there was a lists.opensuse.org maintenance process hanging (undetected) for a very long time. This process continued a couple of minutes ago. Unfortunately because of the long delay some calculations went wrong (bounce times). This had the effect that the list software may have you unsubscribed.
Please check your subscriptions. To do so you can simply subscribe again by sending a mail to <listname>+subscribe (en) opensuse (punto)org. In case your are still subscribed the system will tell you about it. In case you are not anymore subscription is exactly what you want :)
Sorry for the inconvenience. The underlying problem has been fixed.
Henne
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-30 a las 21:20 +0100, Camaleón escribió:
El 30/01/08, Carlos E. R. escribió:
No, (no), no (no, no).
Esa es lal puñetería, que el syslog nunca graba nada de nada sobre si mismo. Nunca sabes porqué falla él, sólo porqué fallan los demás. Y mira que arranqué el daemon en modo debug...
Bueno, no se trata de que registre un error del propio "syslog" sino de un fallo en la ejecución del script o del programa (por ejemplo, que no lo pudiera ejecutar por un tema de permisos, porque no fuera ejecutable o por pasarle un argumento inválido...).
No, es el syslog quien no lanza el proceso. Se ve. Cuando funciona, se ve esto con "ps afx"
3798 ? Ss 0:00 /sbin/syslog-ng -a /var/lib/dhcp/dev/log -a /var/lib/named/dev/log -a /var/lib/ntp/dev/log 3799 ? Ss 0:00 _ /bin/bash /usr/local/bin/syslog-askandlogrouterip
El syslog tiene un proceso hijo. Cuando no funcionaba el hijo no estaba.
He tenido que desactivar completamente el armor de syslog para que funcione. Lo he puesto en modo "complain", pero no "complaina", el log está a cero. Si lo reactivo, no va. El armor me está tocando las narices.
¡ARGHHHH!
Anda... ¿q'ha pasao?
type=APPARMOR_DENIED msg=audit(1201702120.420:26): type=1503 operation="inode_permission" requested_mask="x" denied_mask="x" name="/bin/bash" pid=13448 profile="/sbin/syslog-ng"
¡Bingo!
Ahí está. Joder. (perdón). ¡AHHHHHHHH!
¿Te lo estaba bloqueando? Jo, oye, y el apparmor ¿no tiene algún "modo debug" que te vaya sacando en una ventanita fija en pantalla lo que deja pasar y lo que no? Porque a ver cómo te enteras si no revisas el registro... para uso diario, vale, el registro es suficiente, pero si estás probando alguna cosa, mejor sería verlo en tiempo real...
No, no avisa nada, nada, nada. Sólo el log.
Ayer descubrí que tiene un algo para avisar al gnome vía dbus, pero todavía no he visto nada.
Encima he pillado otro bug del yast/apparmor, que al editar los profiles quedan procesos pillados.
Es que estoy cabreado... ¿se nota? Me han borrado de cuatro listas de suse, con esta y con la dirección de gmail. Acabo de recuperar tu correo del archivo.
Sí, ya vi el mensaje en la lista inglesa... ¿qué ha pasado al final?
Pues que un proceso quedó pillado, y cuando se desenganchó puso algún temporizador a vete a saber cuantos dias, con lo que lo que sea que calculaba pensó que había tardado nosecuantos dias en no enviar noseque correos, con lo que automáticamente borró todas esas cuentas pensando que estaban inactivas.
¿No te ha llegado el correo de Henne?
- -- Saludos Carlos E.R.
El 31/01/08, Carlos E. R. escribió:
No, es el syslog quien no lanza el proceso. Se ve. Cuando funciona, se ve esto con "ps afx"
3798 ? Ss 0:00 /sbin/syslog-ng -a /var/lib/dhcp/dev/log -a /var/lib/named/dev/log -a /var/lib/ntp/dev/log 3799 ? Ss 0:00 _ /bin/bash /usr/local/bin/syslog-askandlogrouterip
El syslog tiene un proceso hijo. Cuando no funcionaba el hijo no estaba.
Pero... ¿y si intentas lanzar con syslog-ng un programa ("mail" por ejemplo) con un argumento no válido...? Debería aparecer en el registro algún error relacionado con syslog-ng y el intento de lanzarlo pero con resultado de error ¿no?
He tenido que desactivar completamente el armor de syslog para que funcione. Lo he puesto en modo "complain", pero no "complaina", el log está a cero. Si lo reactivo, no va. El armor me está tocando las narices.
Tendrás que afinarlo, crear alguna regla / perfil específica para que ese programita se pueda ejecutar sin problemas... ¿No hay una lista blanca de aplicaciones como en el SA? O:-)
No, no avisa nada, nada, nada. Sólo el log.
Ayer descubrí que tiene un algo para avisar al gnome vía dbus, pero todavía no he visto nada.
Encima he pillado otro bug del yast/apparmor, que al editar los profiles quedan procesos pillados.
Jo, te vas a ganar el DVD pero en Versión Limitada para Coleccionistas con tanto bugzilla :-P
Pues que un proceso quedó pillado, y cuando se desenganchó puso algún temporizador a vete a saber cuantos dias, con lo que lo que sea que calculaba pensó que había tardado nosecuantos dias en no enviar noseque correos, con lo que automáticamente borró todas esas cuentas pensando que estaban inactivas.
¿No te ha llegado el correo de Henne?
No, no me ha llegado nada, quizá sólo recibieron el mensaje las direcciones que fueron dadas de baja... :-?
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-31 a las 13:23 +0100, Camaleón escribió:
El 31/01/08, Carlos E. R. escribió:
No, es el syslog quien no lanza el proceso. Se ve. Cuando funciona, se ve esto con "ps afx"
3798 ? Ss 0:00 /sbin/syslog-ng -a /var/lib/dhcp/dev/log -a /var/lib/named/dev/log -a /var/lib/ntp/dev/log 3799 ? Ss 0:00 _ /bin/bash /usr/local/bin/syslog-askandlogrouterip
El syslog tiene un proceso hijo. Cuando no funcionaba el hijo no estaba.
Pero... ¿y si intentas lanzar con syslog-ng un programa ("mail" por ejemplo) con un argumento no válido...? Debería aparecer en el registro algún error relacionado con syslog-ng y el intento de lanzarlo pero con resultado de error ¿no?
Primero, ten en cuenta que no se puede lanzar un proceso en cada evento: se lanza el proceso durante el arranque, y se cierra al cerrar el syslog. Lo que hace el syslog es pasarle al proceso hijo, en plan filtro, los mensajes que genera el syslog con el patrón de coincidencias. Le puedes mandar el log entero si quieres, o una sóla linea.
Eso lo que yo hago en el script: cuando recibe una linea, la que sea, interroga al router y manda escribir la IP.
Si los parámetros son inválidos, si el hijo no se ejcuta, no te enteras. El apparmour deniega el permiso, pero el syslog ni pía.
He tenido que desactivar completamente el armor de syslog para que funcione. Lo he puesto en modo "complain", pero no "complaina", el log está a cero. Si lo reactivo, no va. El armor me está tocando las narices.
Tendrás que afinarlo, crear alguna regla / perfil específica para que ese programita se pueda ejecutar sin problemas... ¿No hay una lista blanca de aplicaciones como en el SA? O:-)
Lo tenía medio afinado cuando dejó de funcionar. Ahora mismo, el apparmor deniega el permiso, pero no escribe nada en su propio log, por lo que me es imposible afinar el perfil (/etc/apparmor.d/sbin.syslog-ng). Y eso es otro bug >:-)
Así que no he tenido más remedio que desactivar el perfil.
Encima he pillado otro bug del yast/apparmor, que al editar los profiles quedan procesos pillados.
Jo, te vas a ganar el DVD pero en Versión Limitada para Coleccionistas con tanto bugzilla :-P
¡Ya te digo!
¿No te ha llegado el correo de Henne?
No, no me ha llegado nada, quizá sólo recibieron el mensaje las direcciones que fueron dadas de baja... :-?
¡JA! Me lo temía.
- -- Saludos Carlos E.R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-31 a las 14:51 +0100, Carlos E. R. escribió:
...
He tenido que desactivar completamente el armor de syslog para que funcione. Lo he puesto en modo "complain", pero no "complaina", el log está a cero. Si lo reactivo, no va. El armor me está tocando las narices.
Tendrás que afinarlo, crear alguna regla / perfil específica para que ese programita se pueda ejecutar sin problemas... ¿No hay una lista blanca de aplicaciones como en el SA? O:-)
Lo tenía medio afinado cuando dejó de funcionar. Ahora mismo, el apparmor deniega el permiso, pero no escribe nada en su propio log, por lo que me es imposible afinar el perfil (/etc/apparmor.d/sbin.syslog-ng). Y eso es otro bug >:-)
Así que no he tenido más remedio que desactivar el perfil.
Fíjate que afinar este perfil es un peñazo de cuidado.
Hay que decirle al apparmour que deje que el syslog ejecute el programa externo, o bien en modo "confined" o "unconfined". En el primer caso hereda todas las prohibiciones, en el segundo ninguna. En el segundo caso funciona bien, pero es peligroso, se supone. En el primer caso es un peñazo, porque como el filtro llama a varios otros programas: expect, ssh, grep y cut, pues a todos ellos también hay que darles permiso. Y como el expect parece que usa tcl y abre o mira un montón de ficheros, pues no veas la cantidad de cosas que hay que abrirle para que funcione.
- -- Saludos Carlos E.R.
El 31/01/08, Carlos E. R. escribió:
Fíjate que afinar este perfil es un peñazo de cuidado.
Pues abre un bug del tipo "mejora" para que el apparmor permita una lista blanca de programas (definidas por el administrador, claro está, persona altamente responsable y cualificada donde las "hayga" :-P) que se puedan ejecutar sin más historias O:-)
Hay que decirle al apparmour que deje que el syslog ejecute el programa externo, o bien en modo "confined" o "unconfined". En el primer caso hereda todas las prohibiciones, en el segundo ninguna. En el segundo caso funciona bien, pero es peligroso, se supone. En el primer caso es un peñazo, porque como el filtro llama a varios otros programas: expect, ssh, grep y cut, pues a todos ellos también hay que darles permiso. Y como el expect parece que usa tcl y abre o mira un montón de ficheros, pues no veas la cantidad de cosas que hay que abrirle para que funcione.
Pues no sé... la verdad es que nunca me he puesto a jugar con el apparmor, sólo lo tengo activado por recomendación de (ejem, ejem...) alguien >:-)
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-31 a las 18:11 +0100, Camaleón escribió:
El 31/01/08, Carlos E. R. escribió:
Fíjate que afinar este perfil es un peñazo de cuidado.
Pues abre un bug del tipo "mejora" para que el apparmor permita una lista blanca de programas (definidas por el administrador, claro está, persona altamente responsable y cualificada donde las "hayga" :-P) que se puedan ejecutar sin más historias O:-)
No, si se puede hacer... en el perfil del syslog-ng dices que:
/usr/local/bin/syslog-askandlogrouterip rUx,
y te deja ejecutarlo, pero cuando arranca el apparmour en vez de decir "done" te pone un texto de aviso y un "warning" o algo asín.
No puedes dar una lista blanca de programas, porque es un coladero. Si tienes un servidor con un servicio abierto al exterior (syslog puede recibir conexiones de la red) no puedes dejar que ejecute cualquier cosa. Tienes que encargarte tú de listar lo que puede ejecutar, y es más, que ficheros, uno a uno, puede abrir esa segunda aplicación.
Eso es lo que hace el apparmor: asegurarse de que las aplicaciones conectables no puedan acceder a ficheros o programas no previstos.
Hay que decirle al apparmour que deje que el syslog ejecute el programa externo, o bien en modo "confined" o "unconfined". En el primer caso hereda todas las prohibiciones, en el segundo ninguna. En el segundo caso funciona bien, pero es peligroso, se supone. En el primer caso es un peñazo, porque como el filtro llama a varios otros programas: expect, ssh, grep y cut, pues a todos ellos también hay que darles permiso. Y como el expect parece que usa tcl y abre o mira un montón de ficheros, pues no veas la cantidad de cosas que hay que abrirle para que funcione.
Pues no sé... la verdad es que nunca me he puesto a jugar con el apparmor, sólo lo tengo activado por recomendación de (ejem, ejem...) alguien >:-)
Bueno, si es que es una medida de seguridad considerable, y como todas las medidas de seguridad, incluyendo los seguratas, te tocan las narices de vez en cuando. La historia con el apparmor es que te olvidas que está ahí y no piensas en él cuando algo no funciona.
- -- Saludos Carlos E.R.
El 31/01/08, Carlos E. R. escribió:
No, si se puede hacer... en el perfil del syslog-ng dices que:
/usr/local/bin/syslog-askandlogrouterip rUx,
y te deja ejecutarlo, pero cuando arranca el apparmour en vez de decir "done" te pone un texto de aviso y un "warning" o algo asín.
Ah, pues eso podría servir ¿no? Con tal de que lo deje pasar...
No puedes dar una lista blanca de programas, porque es un coladero.
Ya, vale, pero es "tu coladero" ;-) por tu cuenta y riesgo. ¿O me estás diciendo que el apparmor es más inteligente que el administrador? Si es así, mañana pido una "jubilación anticipada" >:-)
Si tienes un servidor con un servicio abierto al exterior (syslog puede recibir conexiones de la red) no puedes dejar que ejecute cualquier cosa. Tienes que encargarte tú de listar lo que puede ejecutar, y es más, que ficheros, uno a uno, puede abrir esa segunda aplicación.
Faale, pero que me explique el apparmor por qué bloquea un proceso que ha lanzado el syslog-ng, en qué se basa para determinar que es perjudicial...
Eso es lo que hace el apparmor: asegurarse de que las aplicaciones conectables no puedan acceder a ficheros o programas no previstos.
"No previstos"... ¿y qué hay "previsto" en un sistema? ¿acaso algo "previsto" no puede ser dañino? :-/
Sí, ya lo sé. Seguro que requiere configuración para que sea más flexible o se ajuste a las necesidades de cada sistema.
Bueno, si es que es una medida de seguridad considerable, y como todas las medidas de seguridad, incluyendo los seguratas, te tocan las narices de vez en cuando. La historia con el apparmor es que te olvidas que está ahí y no piensas en él cuando algo no funciona.
El problema es que tener activado algo que se sabe cómo funciona suele ser más problemático que beneficioso :-P.
<modo IA on>
Al menos podría haberte preguntado, si tenía dudas... "eh, tú, psss, oye, mira, que tengo un proceso que no sé muy bien qué es. Se llama "askandlogrouterip", me viene desde el "syslog-ng" y tiene "mu mala" pinta, pero ¿me dejas ejecutarlo?"
</modo IA off>
O:-)
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-01-31 a las 21:58 +0100, Camaleón escribió:
El 31/01/08, Carlos E. R. escribió:
No, si se puede hacer... en el perfil del syslog-ng dices que:
/usr/local/bin/syslog-askandlogrouterip rUx,
y te deja ejecutarlo, pero cuando arranca el apparmour en vez de decir "done" te pone un texto de aviso y un "warning" o algo asín.
Ah, pues eso podría servir ¿no? Con tal de que lo deje pasar...
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
No puedes dar una lista blanca de programas, porque es un coladero.
Ya, vale, pero es "tu coladero" ;-) por tu cuenta y riesgo. ¿O me estás diciendo que el apparmor es más inteligente que el administrador? Si es así, mañana pido una "jubilación anticipada" >:-)
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.
Si tienes un servidor con un servicio abierto al exterior (syslog puede recibir conexiones de la red) no puedes dejar que ejecute cualquier cosa. Tienes que encargarte tú de listar lo que puede ejecutar, y es más, que ficheros, uno a uno, puede abrir esa segunda aplicación.
Faale, pero que me explique el apparmor por qué bloquea un proceso que ha lanzado el syslog-ng, en qué se basa para determinar que es perjudicial...
En que no está en la lista, así de simple.
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.
Eso es lo que hace el apparmor: asegurarse de que las aplicaciones conectables no puedan acceder a ficheros o programas no previstos.
"No previstos"... ¿y qué hay "previsto" en un sistema? ¿acaso algo "previsto" no puede ser dañino? :-/
No es el sistema lo que protege, sino aplicaciones concretas. Debes proteger todas las aplicaciones que sirven a la red.
Sí, ya lo sé. Seguro que requiere configuración para que sea más flexible o se ajuste a las necesidades de cada sistema.
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.
Bueno, si es que es una medida de seguridad considerable, y como todas las medidas de seguridad, incluyendo los seguratas, te tocan las narices de vez en cuando. La historia con el apparmor es que te olvidas que está ahí y no piensas en él cuando algo no funciona.
El problema es que tener activado algo que se sabe cómo funciona suele ser más problemático que beneficioso :-P.
Mmmm
<modo IA on>
Al menos podría haberte preguntado, si tenía dudas... "eh, tú, psss, oye, mira, que tengo un proceso que no sé muy bien qué es. Se llama "askandlogrouterip", me viene desde el "syslog-ng" y tiene "mu mala" pinta, pero ¿me dejas ejecutarlo?"
Mmmm ¿veo la sombra alargada de guillermito asomarse por ahí? :-P
</modo IA off>
O:-)
- -- Saludos Carlos E.R.
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"?
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
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...
...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.
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 ;-).
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? :-?
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)
Saludos,
-----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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-02-01 a las 01:55 +0100, escribí:
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).
Y eso era porque el demonio auditd estaba caído. El "rcauditd start" fallaba silenciosamente, porque no le gustaban los permisos del log. Grrr!
- -- Saludos Carlos E.R.
El 1/02/08, Carlos E. R. escribió:
Creo que es un bug nuevo que he descubierto. ¡Miii teessssoooorooooo! Ya te digo, quiero el dvd de platino.
Je, y con diamantes incrustados ¿no? >:-)
(está mandando los registros de audit al syslog, facilidad kernel; lo he descubierto al rebotar el kernel que acabo de compilar).
Vaya. Y ahora que lo leo, ¿recuerdas que bind también sacaba un error al warn? Pues acaban de poner el bug:
https://bugzilla.novell.com/show_bug.cgi?id=357892
Tú eres la administradora y lo sabes to. Por definición. Si no lo sabes, se aplica el artículo uno.
:-)
¿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.
Buenoooo, eso de "simple", ejem O:-).
IBM está desarrollando herramientas de este tipo (de autogestión y autocontrol) que son realmente interesantes. Por ahí van los tiros...
¿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 >:-)
Era un caso hipotético-teórico, no práctico. Pero no es una situación tan descabellada. Mediante "ingeniería social" puedes estar leyendo un "inocente" mensaje desde Pine (bueno, Alpine :-P) en formato texto, pero con un enlace que lleva a un sitio comprometido que se descarga cualquier cosa "jorobante".
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...
Jupe, me voy a poner una máquina virtual sólo para leer el correo... o ya puestos, como hace Stallman, que no navega con "navegador" X-)
Richard Stallman no usa navegador http://www.theinquirer.es/2008/01/31/richard_stallman_no_usa_navegador.html
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.
No, no la hay. Y de todo lo que has enumerado, el menos fiable es el "segurata" que se va a comer su pincho de tortilla al bar a las 11:00 todos los días (y éste no deja registro, bueno, sí, las miguitas en la silla)... :-D
Así es como lo veo yo. Un usuario tecleando es un peligro invallable, sobre todo si tiene privilegios.
Tendrían que desarrollar un "botón de pánico" que permitiera la desconexión de la red del equipo al pulsarlo :-P
El guillermito no usa zypper - usa iexplorer :-P
Pues en cuestión de "sustos al usuario" no creas que se llevan tanta diferencia estos dos X-)
Saludos,
-
Camaleón -
Carlos E. R. -
J.M.Queralt -
Victor Hugo dos Santos