阻止潜在的恶意 R 调用
我们假设您以 root/admin 权限运行 R。除了 system() 和 file.*() 之外，您认为哪些 R 调用有害？
这是一个特定于平台的问题，我运行的是 Linux，所以我对特定于 Linux 的安全漏洞感兴趣。如果您阻止有关 R 的讨论，我会理解，因为这篇文章很容易变成“如何用 R 搞乱系统？”
Let's presuppose that you have R running with root/admin privileges. What R calls do you consider harmful, apart from system() and file.*()?
This is a platform-specific question, I'm running Linux, so I'm interested in Linux-specific security leaks. I will understand if you block discussions about R, since this post can easily emerge into "How to mess the system up with R?"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
不要以 root 权限运行 R。没有有效的方法以这种方式保护 R，因为该语言包含 eval 和反射，这意味着即使您不希望我这样做，我也可以构造对系统的调用。
更好的办法是以一种不会影响系统或用户数据的方式运行 R，无论它试图做什么。
Do not run R with root privs. There is no effective way to secure R in this way, since the language includes eval and reflection, which means I can construct invocations to system even if you don't want me to.
Far better is to run R in a way that cannot affect the system or user data, no matter what it tries to do.
任何调用外部代码的内容也可能会导致系统更改，因此您需要阻止某些包和诸如
.Call()、.C()、之类的内容.jcall() 等。可以说，这最终将成为一项几乎不可能完成的任务，如果您需要 root 访问权限，您最好在虚拟化环境等中运行它。
Anything that calls external code could also be making system changes, so you would need to block certain packages and things like
.Call(),.C(),.jcall(), etc.Suffice it to say that it will end up being a virtually impossible task, and you are better off running it in a virtualized environment, etc. if you need root access.
你不能。你应该改变这个问题：“我如何运行用户提供的 R 代码，以免伤害用户或系统的其他用户？”这实际上是一个非常有趣的问题，可以通过一些云计算、apparmor、chroot magic 等来解决。
You can't. You should just change the question: "How do I run user-supplied R code so as not to harm the user or other users of the system?" That's actually a very interesting question and one that can be solved with a little bit of cloud computing, apparmor, chroot magic, etc.
您可以使用大量命令来损害系统。一些示例：
Sys.chmod、Sys.umask、unlink、任何允许您读取的命令/write 到连接（有很多）、.Internal、.External等。如果您阻止用户使用这些命令，则没有什么可以阻止他们执行某些操作一个你不知道要阻止的包。
There are tons of commands you could use to harm the system. A handful of examples:
Sys.chmod,Sys.umask,unlink, any command that allows you to read/write to a connection (there are many),.Internal,.External, etc.And if you blocked users from those commands, there's nothing stopping them from implementing something in a package that you wouldn't know to block.
正如对该线程的几乎每个回复所指出的，删除 R 语言中的“潜在有害”调用将：
一个不需要修改/重写 R 语言大部分内容的更安全的解决方案是使用类似 BSD Jails、Jailkit 或 Solaris 区域。
其中许多解决方案允许被监禁的进程行使类似 root 的权限，但限制该进程可以操作的计算机区域。
一次性虚拟机是另一种选择。如果特权用户破坏了虚拟环境，只需将其删除并启动另一个副本即可。
As noted by just about every response to this thread, removing the "potentially harmful" calls in the R language would:
A safer solution that doesn't require modifying/rewriting large parts of the R language would be to run R inside a jail using something like BSD Jails, Jailkit or Solaris Zones.
Many of these solutions allow the jailed process to exercise root-like privileges but restrict the areas of the computer that the process can operate on.
A disposable virtual machine is another option. If a privileged user thrashes the virtual environment, just delete it and boot another copy.
我一直以来的最爱之一。你甚至不必成为r00t。
One of my all time favorites. You don't even have to be r00t.
套用枪支权利人士的一句陈词滥调，“system() 不是有害的 - 调用 system() 的人是有害的”。
没有函数调用本质上是有害的，但是如果您允许人们自由使用它们，那么这些人可能会造成伤害。
此外，伤害的定义取决于您认为有害的内容。
To adapt a cliche from gun rights people, "system() isn't harmful - people who call system() are harmful".
No function calls are intrinsically harmful, but if you allow people to use them freely then those people may cause harm.
Also, the definition of harm will depend on what you consider harmful.
一般来说，R 非常复杂，您可以假设有一种方法可以通过看似无害的函数来欺骗它执行数据，例如通过缓冲区溢出。
In general, R is so complex that you can assume that there is a way to trick it in executing data with seemingly harmless functions, for instance through buffer overflow.