Blocco di chiamate R potenzialmente dannose

Question

Supponiamo di avere R in esecuzione con privilegi root/admin. Quali chiamate R consideri dannose, ad eccezione di system() e file.*()?

Questa è una domanda specifica della piattaforma, sto eseguendo Linux, quindi sono interessato a perdite di sicurezza specifiche per Linux. Capirò se blocchi le discussioni su R, dal momento che questo post può facilmente emergere in "Come rovinare il sistema con R?"

Answer 1

Non eseguire R con privilegi di root. Non esiste un modo efficace per proteggere R in questo modo, dal momento che il linguaggio include eval e reflection, il che significa che posso costruire invocazioni al sistema anche se non vuoi che lo faccia.

Molto meglio è eseguire R in un modo che non può influire sul sistema o sui dati dell'utente, indipendentemente da ciò che tenta di fare.

Answer 2

Tutto ciò che chiama il codice esterno potrebbe anche essere fare le modifiche al sistema, quindi si avrebbe bisogno di bloccare determinati pacchetti e cose del genere .Call(), .C(), .jcall(), ecc

Basti dire che finirà per essere un compito praticamente impossibile, e si sta meglio eseguendolo in un ambiente virtualizzato, ecc. se è necessario l'accesso come root.

Answer 3

Non è possibile. Dovresti solo cambiare la domanda: "Come posso eseguire il codice R fornito dall'utente in modo da non danneggiare l'utente o altri utenti del sistema?" Questa è in realtà una domanda molto interessante che può essere risolta con un po 'di cloud computing, apparmor, chroot magic, ecc.

Answer 4

Ci sono tonnellate di comandi che è possibile utilizzare per danneggiare il sistema. Una manciata di esempi: Sys.chmod, Sys.umask, unlink, qualsiasi comando che permette di leggere/scrivere a una connessione (ce ne sono molti), .Internal, .External, ecc

E se ti ha bloccato gli utenti da questi comandi, non c'è nulla che impedisca loro di implementare qualcosa in un pacchetto che non sapresti bloccare.

Answer 5

Per adattare un cliché alle persone con diritti di pistola, "system() non è dannoso - le persone che chiamano system() sono dannose".

Nessuna chiamata di funzione è intrinsecamente dannosa, ma se si consente alle persone di utilizzarle liberamente, queste persone potrebbero causare danni.

Inoltre, la definizione di danno dipenderà da ciò che consideri dannoso.

Answer 6

Come notato da quasi ogni risposta a questa discussione, rimuovendo il "potenzialmente dannose" chiama nel linguaggio R sarebbe:

• essere potenzialmente impossibile da fare completamente.
• Essere difficili da fare senza passare molto tempo a scrivere hack complicati (cioè brutti).
• Gira la lingua rimuovendo una tonnellata di funzionalità che rende R così flessibile.

Una soluzione più sicura che non richiede la modifica/riscrittura gran parte del linguaggio R sarebbe quella di eseguire R all'interno di un carcere usando qualcosa come BSD Jails, Jailkit o Solaris Zones.

Molte di queste soluzioni consentono al processo di eseguire privilegi di tipo root ma limitare le aree del computer su cui il processo può operare.

Una macchina virtuale usa e getta è un'altra opzione. Se un utente privilegiato colpisce l'ambiente virtuale, è sufficiente eliminarlo e avviare un'altra copia.

Answer 7

In generale, R è così complesso che si può presumere che ci sia un modo per ingannarlo nell'eseguire i dati con funzioni apparentemente innocue, ad esempio attraverso l'overflow del buffer.

Answer 8

Uno dei miei preferiti di tutti i tempi. Non devi nemmeno essere r00t.

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