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
locking down R
4 messages · R. Michael Weylandt, Ben Bolker, Tim Triche, Jr.
On Sun, May 19, 2013 at 7:16 PM, Ben Bolker <bbolker at gmail.com> wrote:
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..
If you really mean a "modern operating system"... ;-) http://arxiv.org/abs/1303.4808 Cheers, MW
* 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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 13-05-19 06:08 PM, R. Michael Weylandt wrote:
On Sun, May 19, 2013 at 7:16 PM, Ben Bolker <bbolker at gmail.com> wrote:
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..
If you really mean a "modern operating system"... ;-) http://arxiv.org/abs/1303.4808 Cheers, MW
Interesting, of course, but WinXP is the target OS (unless your point is that people are worrying about this even on Linux). (Another point not mentioned previously is that users have to sign a fairly serious confidentiality oath to get access to this system in the first place, which presumably includes an implied "I won't hack the system" clause ...) RAppArmor is an interesting idea, as is sandboxR (mentioned in the paper); I also looked up Sandboxie (a Windows program for sandboxing). I don't think any of these will really solve the problem, though ... thanks Ben Bolker
* 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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20130520/6ffab19a/attachment.pl>