From bbolker at gmail.com  Sun May 19 20:16:30 2013
From: bbolker at gmail.com (Ben Bolker)
Date: Sun, 19 May 2013 14:16:30 -0400
Subject: [Rd] locking down R
Message-ID: <519916FE.6060309@ufl.edu>


  Is anyone on this list aware of discussions about locking down/securing R?

  My colleagues and I are working with health statistics in an office
that disallows many useful tools (e.g. emacs, vim, perl, make) on the
grounds that they represent a security risk.  We are considering pushing
back, but we are worried that if we attract the attention of the Powers
That Be to the reality that R allows execution of arbitrary shell
commands, they will then disallow the use of R (SAS and Stata are our
other optiona). It might be useful to be able to give them options for
securing R.

  Possibly useful information:

* the office allows use of SAS (and Stata, MLWiN, etc.) but uses the
NOXCMD specification to prevent shell access from within SAS. They also
disallow access to the Windows shell (in the current configuration,
shell() works fine from within R, but we think this may have escaped
their notice ...) The workstations have no access to external networks,
nor to external media (thumb drives etc.) [information transfer to the
outside world is via shared drives that can be accessed by
administrators with network access].

* I stipulate that (1) the security policies don't make sense, (2)
allowing users access to arbitrary shell commands should _not_ represent
a security risk on a well-administered, modern operating system (they're
running WinXP), (3) R probably offers many other avenues for system
access to a malicious user, even in the absence of shell access,
compilers, etc..

* I suspect the answer given here will be "if you really want to secure
R, run it within a standard restricted-access shell (e.g. chroot on a
Linux system)".  If anyone has experience of 'locking down' R on Windows
(XP) in a sensitive environment, I'd be curious about the details.

 thanks
  Ben Bolker



[Rd] locking down R
Ben Bolker