2011-03-03 19 views
7

Tengo un portal en mi LAN de la universidad donde la gente puede cargar el código a los acertijos de programación en C/C++. Me gustaría asegurar el portal para que las personas no puedan hacer llamadas al sistema a través de su código enviado. Puede haber varias soluciones, pero me gustaría saber si puedo hacerlo simplemente configurando algunos indicadores de gcc inteligentes. libc por defecto parece incluir <unistd.h>, que parece ser el archivo básico donde se declaran las llamadas al sistema. ¿Hay alguna manera de decirle a gcc/g ++ que 'ignore' este archivo en tiempo de compilación para que no se pueda acceder a ninguna de las funciones declaradas en unistd.h?Supresión de llamadas al sistema al usar gcc/g ++

+2

¿Qué tal si usamos algo como http://www.citi.umich.edu/u/provos/systrace/? – GWW

+0

Actualmente estoy haciendo algo como systrace, me preguntaba si era más fácil omitir algo que está tan claramente diferenciado (al menos en la descripción de manualidades) del código de biblioteca habitual. – kyun

Respuesta

3

Alguna razón particular por la cual chroot("/var/jail/empty"); setuid(65534); no es lo suficientemente bueno (asumiendo que 65534 tiene límites razonables)?

+0

¿Es eso algo así como crear/simular un usuario diferente para ejecutar el código subido? He visto a otros usar ese enfoque, siempre me he preguntado cómo. – kyun

+1

La idea es vincular con -estático, escribir el binario en la cárcel y ejecutarlo. No hay nada más en la cárcel, así que no pueden hacer mucho. – Joshua

+0

¡Ah! Eso es un buen hack! ¡Es como tu propio pequeño arenero! Creo que sería mucho más simple que suprimir las llamadas al sistema como está. Ahora, pasé de la idea de la zona de pruebas a la implementación de la zona de pruebas. ¡Gracias! – kyun

2

-D puede sobrescribir nombres de funciones individuales. Por ejemplo:

gcc file.c -Dchown -Dchdir 

O puede establecer el las guardas para ti mismo:

gcc file.c -D_UNISTD_H 

Sin embargo, sus efectos pueden ser fácilmente revertidos con #undef s por los remitentes inteligentes :)

+0

Veo lo que quiere decir, creo que como señaló Matthew Slattery, el camino a seguir es tener algún tipo de entorno de caja de arena – kyun

3

La restricción del acceso a la cabecera el archivo no le impedirá acceder a las funciones libc: todavía están disponibles si enlaza con libc; simplemente no tendrá los prototipos (y las macros) a mano; pero puedes replicarlos tú mismo.

Y no vincular en contra de libc tampoco ayudará: las llamadas al sistema se pueden realizar directamente a través del ensamblador en línea (o incluso trucos que implican saltar a los datos).

No creo que este sea un buen enfoque en general. Ejecutar el código cargado en un entorno de pruebas virtual completamente autónomo (a través de QEMU o algo así, tal vez) probablemente sería una mejor manera de hacerlo.

+0

Eso es verdad, no había pensado en eso. Creo que el sandboxing sería el camino a seguir, solo parece una gran sobrecarga para un entorno tan simple (generalmente no malicioso) – kyun

Cuestiones relacionadas