¿Existe un método confiable de "monitoreo" de llamadas al sistema bajo Linux?
Por ejemplo, strace monitorea las llamadas y señales del sistema. ¿Hay alguna manera de que un proceso salte de strace ? Si es así, ¿hay otro método confiable y seguro para "monitorear" las llamadas al sistema (y, tal vez, recibir señales), de la que no puede escapar un proceso (suponiendo una implementación de Linux adecuada)?
En Linux, puede supervisar de manera confiable una selección de llamadas al sistema o accesos a archivos con el subsistema de auditoría . Asegúrese de que el daemon auditd se esté ejecutando, luego configure lo que desea registrar con auditctl . Cada operación registrada se registra en /var/log/audit/audit.log (en configuraciones típicas).
Encontrará ejemplos simples de uso de auditctl en este sitio , en Server Fault y en Intercambio de pila Unix .
strace o los programas asociados que usan ptrace son formas confiables de monitorear las llamadas al sistema, pero desconfiaría de usarlas en un programa malicioso. No podría decirle lo poco que estoy pensando, pero debería ser posible que un programa monitoreado realice las llamadas correctas ptrace para evadir el monitoreo.
Tenga en cuenta que un programa malintencionado podría generar un proceso que no se audita y puede ejecutar código que no se registrará. Por ejemplo, podría usar mmap para escribir en un archivo sin que el contenido del archivo aparezca como los argumentos de las llamadas al sistema, haga que este archivo sea ejecutable y genere un proceso de ejecución. El proceso generado normalmente puede romper el árbol de procesos con algo como ssh localhost . Si audita todos los procesos ejecutados por un usuario determinado (a diferencia de un solo proceso y sus descendientes), podrá registrar todo.
En caso afirmativo, ¿existe otro método confiable y seguro para "monitorear" las llamadas al sistema (y, tal vez, recibir señales), ese proceso no puede interrumpirse (suponiendo una implementación de Linux adecuada)?
Para re-iterar de una manera ligeramente diferente lo que D.W. ya ha dicho, ptrace es una llamada al sistema que strace , gdb y similares hacen para monitorear las acciones de un proceso. Hay dos problemas con este enfoque:
ptrace , proporcionarle la salida de otro proceso o algún otro tipo de malversación. Los procesos no siempre se escriben para enviarlos voluntariamente a los depuradores. Tal vez le gustaría leer este conjunto de desafíos (enfocado en win32: vea la primera entrada y continúe leyendo para hacerlo difícil) de una compañía de appsec (no tengo vínculos con ellos). Si bien se centró en el mecanismo IsDebuggerPresent() , existen soluciones para ptrace similares. Si desea ver esto en forma salvaje y tener skype instalado en un cuadro de Linux, intente depurarlo.
Repitiendo esas técnicas aquí, hay dos mecanismos claros contra el seguimiento:
if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
printf("being ptraced\n");
exit(1);
}
Este método se basa en el hecho de que un proceso no se puede rastrear dos veces. Si no puedes seguirte, estás siendo tratado.
struct timespec spec;
signal(SIGALRM, SIG_IGN);
alarm(1);
spec.tv_sec = 2;
spec.tv_nsec = 0;
if (nanosleep(&spec, NULL) < 0) {
/* EINTR */
printf("being ptraced\n");
exit(1);
}
Para explicar esto, eche un vistazo a nanosleep() y lea el artículo original. En términos simples, nanosleep() es una llamada al sistema no reiniciable y regresará pronto cuando el proceso maneje una señal. Este proceso en particular, cuando no se está depurando, simplemente no manejará esa señal en particular y, por lo tanto, no se activará. Sin embargo, un proceso procesado lo manejará, lo que provocará que nanosleep regrese antes. Otro ejemplo en el que esto sucede es la llamada al sistema select() .
En última instancia, puede mitigar los efectos de 1 asegurando la integridad de su sistema antes de iniciar y aplicar medidas de seguridad suficientes y un kernel debidamente configurado.
¿Qué puedes hacer de manera confiable con respecto a 2? No mucho sin modificar el código binario original, ya que cualquier técnica para depurar introducirá inconsistencias observables o problemas de implementación en algún lugar.
tl; dr ptrace te ayudará si el proceso de destino no se escribió teniendo en cuenta a los depuradores.
Sí. strace es una forma razonable de monitorear las llamadas al sistema y sus argumentos, siempre que el proceso que se monitorea no sea malicioso. Si el proceso que se está monitoreando es malicioso y se escribió para evadir strace, espero que pueda hacerlo. strace no se escribió como una herramienta de seguridad, y puedo suponer varias formas en que el proceso podría derrotarlo. Ver, por ejemplo, Robert Watson, Explotación de vulnerabilidades de concurrencia en envoltorios de llamadas del sistema o Tal Garfinkel, Trampas y trampas: Problemas prácticos en las herramientas de seguridad basadas en interposición de llamadas del sistema .
Si está preocupado por el código malicioso, querrá usar una caja de arena diseñada para la seguridad, en lugar de una herramienta como strace que no fue diseñada para la seguridad. El enfoque general para construir una caja de arena de este tipo es utilizar la interposición de llamadas al sistema tanto para contener el proceso monitoreado como para monitorear sus acciones. Un método portátil es usar ptrace, aunque esto puede introducir una sobrecarga de rendimiento no trivial, ya que obliga a un cambio de contexto en cada llamada al sistema. En Solaris, puedes usar / proc; / proc le permite especificar el subconjunto de llamadas al sistema que le interesa envolver, lo que le permite lograr un mejor rendimiento al costo de la compatibilidad.
Eche un vistazo a Plash, Systrace y Subterfugue, para ver algunos sistemas que usan este tipo de métodos. También vea la caja de arena de Chrome, que utiliza una variedad de mecanismos (incluido seccomp en Linux).
Lea otras preguntas en las etiquetas operating-systems linux sandbox