2010-10-26 21 views
8

Supongamos que tiene R ejecutándose con privilegios de administrador/raíz. ¿Qué llamadas R considera dañinas, aparte de system() y file.*()?Bloquear llamadas R potencialmente dañinas

Esta es una pregunta específica de la plataforma, estoy ejecutando Linux, por lo que estoy interesado en las fugas de seguridad específicas de Linux. Lo entenderé si bloquea las discusiones sobre R, ya que esta publicación puede surgir fácilmente en "¿Cómo desordenar el sistema con R?"

+1

¿Cuál es la razón para ejecutar R como root? Tal vez la solución está ahí, es decir, debe hacerse la pregunta: "¿cómo le permito al usuario hacer xyz ** sin ** darle privilegios de root?". El otro punto, por supuesto, es que cualquiera que pueda ejecutar software con privilegios de administrador debe ser lo suficientemente confiable como para no preocuparse de que él/ella estropee el sistema, de lo contrario, él/ella no debería tener privilegios de root en primer lugar. – nico

+0

Esto se preguntó hace algunos años en las listas R-Help o R-Devel. No recuerdo los detalles, pero lo que preguntas es efectivamente imposible; una vez que desactivaste todas las avenidas posibles para hacer algo fuera de R, dejaste a R inútil. No corras como root –

+0

Una (tal vez demasiado) amplia lista de funciones potencialmente dañinas se puede encontrar en mi pequeño paquete: https://github.com/daroczig/sandboxR. Este paquete prohibiría muchas llamadas R y solo permitiría la carga de paquetes "incluidos en la lista blanca", por lo que podría no ser lo suficientemente permisivo, pero prohibiría a los usuarios comprometer cualquier archivo y recursos en su sistema. Por supuesto, este entorno de espacio aislado debe usarse en alguna aplicación que maneje, p. escribe en el disco, fuera del código R de los usuarios. – daroczig

Respuesta

11

No ejecute R con privs de la raíz. No existe una manera efectiva de asegurar R de esta manera, ya que el lenguaje incluye evaluación y reflexión, lo que significa que puedo construir invocaciones al sistema incluso si no quieres que lo haga.

Mucho mejor es ejecutar R de una manera que no puede afectar el sistema ni los datos del usuario, sin importar lo que intente hacer.

+4

Excelente punto sobre 'eval', y puedes ocultar los contenidos tanto como quieras. 'eval (parse (text = pegar (rev (c (") "," lo que sea "," ("," m "," e "," t "," s "," y "," s ")) , sep = "", collapse = ""))) ' –

+0

Puedes bloquear' eval' en ese caso, pero por supuesto estamos llegando al punto en que muchas de las funciones R de base dejarán de funcionar correctamente. – Shane

+0

@Shane ¿cómo se puede bloquear eval? base :: eval es inmutable. – mbq

8

Cualquier cosa que llama código externo también podría ser hacer cambios en el sistema, por lo que se necesita para bloquear ciertos paquetes y cosas por el estilo .Call(), .C(), .jcall(), etc.

Baste decir que va a terminar siendo una tarea virtualmente imposible, y es mejor que la ejecute en un entorno virtualizado, etc., si necesita acceso a la raíz.

5

No puede. Solo debe cambiar la pregunta: "¿Cómo ejecuto el código R proporcionado por el usuario para no dañar al usuario u otros usuarios del sistema?" Esa es en realidad una pregunta muy interesante y puede resolverse con un poco de computación en la nube, apparmor, chroot magic, etc.

+1

Tiene toda la razón, no puedo. Debería haber preguntado "¿Qué llamadas de R pueden ser potencialmente dañinas?" De todos modos, gracias por las sugerencias ... – aL3xa

3

Existen muchos comandos que puede utilizar para dañar el sistema. Un puñado de ejemplos: Sys.chmod, Sys.umask, unlink, cualquier comando que le permite leer/escribir en una conexión (hay muchos), .Internal, .External, etc.

Y si se bloquea a los usuarios de estos comandos, no hay nada que les impida implementar algo en un paquete que no sabría bloquear.

2

Para adaptar un cliché de la gente de derechos de armas, "el sistema() no es dañino - las personas que llaman al sistema() son perjudiciales".

Ninguna llamada de función es intrínsecamente dañina, pero si permite que las personas la utilicen libremente, esas personas pueden causar daños.

Además, la definición de daño dependerá de lo que considere dañino.

3

Como se ha señalado por casi todas las respuestas a este tema, la eliminación de la "potencialmente dañina" llama en el lenguaje R sería:

  • ser potencialmente imposible de hacer por completo.
  • Sea difícil de hacer sin pasar mucho tiempo escribiendo hacks complicados (es decir, feos).
  • Kneecap el lenguaje mediante la eliminación de una tonelada de funcionalidad que hace que R sea tan flexible.

Una solución más segura que no requiere la modificación/reescribir gran parte del lenguaje R, sería ejecutar R dentro de una cárcel de usar algo como BSD Jails, Jailkit o Solaris Zones.

Muchas de estas soluciones permiten que el proceso encarcelado ejerza privilegios de tipo raíz pero restrinjan las áreas de la computadora en las que puede operar el proceso.

Una máquina virtual desechable es otra opción. Si un usuario con privilegios golpea el entorno virtual, simplemente elimínelo e inicie otra copia.

1

En general, R es tan complejo que puede suponer que hay una forma de engañarlo al ejecutar datos con funciones aparentemente inofensivas, por ejemplo, mediante el desbordamiento del búfer.

3

Uno de mis favoritos de todos los tiempos. Ni siquiera tiene que ser r00t.

library(multicore); 
forkbomb <- function(){ 
    repeat{ 
    parallel(forkbomb()); 
    } 
} 
forkbomb(); 
Cuestiones relacionadas