Re: [Rd] locking down R
Is like comma 22: - They hire you to use a console and you will be fired if you use a console! I am italian, and for us, this kind of contradictions are normal ... - Davide Rambaldi, PhD. - IEO ~ MolMed [e] davide.ramba...@ieo.eu [e] davide.ramba...@gmail.com On May 20, 2013, at 5:09 PM, Ben Bolker wrote: On 13-05-20 04:42 AM, Barry Rowlingson wrote: On Sun, May 19, 2013 at 7:16 PM, Ben Bolker bbol...@gmail.com wrote: 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, Correct. If the machines aren't on an external network and have no removable media then this isn't about security from the outside hacker, its about trust. The organisation does not trust YOU. (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), When does WinXP go out of support? Even so, the PC isn't on the network right? So what's the security issue? Doesn't make sense. You can't stomp on other people's files. Would it matter if you could accidentally see other people's files because they set permissions loosely? How compartmentalised are the projects? That is indeed one of the major concerns. The administrators could certainly lock the file access down more than they have (permissions are restricted, but I have information about the existence of lots of directories that I don't have permission to access: the system would probably be more secure if I couldn't even see the top level of these directories). (3) R probably offers many other avenues for system access to a malicious user, even in the absence of shell access, compilers, etc.. The 'malicious user' here is on the inside. The only way to get on the machine is to be physically there? Then a malicious user can only be a trusted user gone bad. A sufficiently malicious user with hardware access can (nearly) always break the thing open and get at the data (even if it comes down to reading data lines with a tap to get at unencrypted streams). Tell the security guys they need to lock the PCs up in a room and provide thin client access over a secure private network at once. Enjoy your new Windows Client Access License costs. Glad I don't work for someone like that. For what it's worth, (1) the people I deal with directly are very nice, but not technically astute; the problem is more one of a large bureaucracy covering its ass in some nonsensical ways; (2) this is only a tiny component of my work. If I get really frustrated with this I can just drop it. I agree with your analysis of the real security situation, more or less. (The PCs are pretty secure physically; it would be pretty hard to break into the boxes without being noticed ...), but I think this http://xkcd.com/651/ is a pretty good analogy for the kind of argument I could get into here. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locking down R
On 13-05-20 04:42 AM, Barry Rowlingson wrote: On Sun, May 19, 2013 at 7:16 PM, Ben Bolker bbol...@gmail.com wrote: 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, Correct. If the machines aren't on an external network and have no removable media then this isn't about security from the outside hacker, its about trust. The organisation does not trust YOU. (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), When does WinXP go out of support? Even so, the PC isn't on the network right? So what's the security issue? Doesn't make sense. You can't stomp on other people's files. Would it matter if you could accidentally see other people's files because they set permissions loosely? How compartmentalised are the projects? That is indeed one of the major concerns. The administrators could certainly lock the file access down more than they have (permissions are restricted, but I have information about the existence of lots of directories that I don't have permission to access: the system would probably be more secure if I couldn't even see the top level of these directories). (3) R probably offers many other avenues for system access to a malicious user, even in the absence of shell access, compilers, etc.. The 'malicious user' here is on the inside. The only way to get on the machine is to be physically there? Then a malicious user can only be a trusted user gone bad. A sufficiently malicious user with hardware access can (nearly) always break the thing open and get at the data (even if it comes down to reading data lines with a tap to get at unencrypted streams). Tell the security guys they need to lock the PCs up in a room and provide thin client access over a secure private network at once. Enjoy your new Windows Client Access License costs. Glad I don't work for someone like that. For what it's worth, (1) the people I deal with directly are very nice, but not technically astute; the problem is more one of a large bureaucracy covering its ass in some nonsensical ways; (2) this is only a tiny component of my work. If I get really frustrated with this I can just drop it. I agree with your analysis of the real security situation, more or less. (The PCs are pretty secure physically; it would be pretty hard to break into the boxes without being noticed ...), but I think this http://xkcd.com/651/ is a pretty good analogy for the kind of argument I could get into here. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locking down R
On 13-05-19 06:08 PM, R. Michael Weylandt wrote: On Sun, May 19, 2013 at 7:16 PM, Ben Bolker bbol...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locking down R
short of running everything in a VM, I'd have to guess you're hosed... I don't understand how an operating system with internals as opaque as Windows (NT/2000/beyond, not just the old DOS-based garbage) could ever be considered secure for intensive computation, but that seems beside the point. You could perhaps recompile R, leaving out the bits offensive to management, and use that... ? If they will let you run in a VM, on the other hand, RAppArmor could satisfy most of these demands in a hurry. On Mon, May 20, 2013 at 8:12 AM, Ben Bolker bbol...@gmail.com wrote: On 13-05-19 06:08 PM, R. Michael Weylandt wrote: On Sun, May 19, 2013 at 7:16 PM, Ben Bolker bbol...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- *A model is a lie that helps you see the truth.* * * Howard Skipperhttp://cancerres.aacrjournals.org/content/31/9/1173.full.pdf [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] locking down R
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
