我可以使用java策略文件安全地使用sudo运行不受信任的应用程序吗

我正在运行一个J2SE应用程序，它有点可信（Minecraft），但可能包含完全不可信（甚至可能是一些恶意）的插件

我想创建一个插件，可以访问Raspberry PI上的GPIO引脚

我见过的每一个解决方案都要求这样的应用程序具有sudo的超级能力，因为gpio是通过直接内存访问来访问的

看起来正确的解决方案是提供如下命令行选项：

-Djava.security.policy=java.policy

这似乎默认为您没有权限（甚至可以访问文件和高端口），然后将应用程序需要的权限添加回策略文件

实际上，您似乎在赋予Java“sudo”权限，然后信任Java的安全模型，只为各种类赋予适当的权限。我猜这使得应用程序可以安全地与sudo一起运行——这是正确的吗

---

有趣的是，从1.0开始，我几乎每天都在使用Java，而且以前从未需要过它。。。你每天都会学到新东西。

[免责声明：我对Java安全模型不是很信服。]

我解决这个问题的方法是让需要访问硬件的代码作为一个单独的特权进程运行，然后让Java应用程序作为一个非特权进程运行，并连接到特权进程，让它代表它执行某些操作

在特权进程中，您应该以最大的不信任度检查每个请求是否可以安全执行。如果您担心其他未经授权的进程也会连接到守护进程，并让它执行不应该执行的命令，那么可以在启动之前通过一个用C编写的小包装器将其套接字归一个特殊组所有，并将Java应用程序

setgid（）

添加到该组

---

Unix域套接字可能是最好的选择，但如果您想

chroot（）

Java应用程序，可能需要TCP/IP套接字。

这也是我的第一个想法，但由于我运行的是Raspberry pi，内存是一种稀缺资源，所以我试图避免使多个JVM旋转。如果安全模型不起作用，我可能会尝试一个C应用程序，它能做到你所说的，但我更喜欢java。您在Java安全模型方面是否有任何具体的问题经验？还是一个好建议，我会投票赞成：）我的假设是守护进程将用C编写，所以它的开销应该相对较低。你不需要去C访问硬件吗？我没有任何可以引用的负面经验，但我认为如果存在操作系统级的安全机制，就应该使用它，在应用程序级模仿它是一个较差的解决方案。更多参与这项工作的人非正式地告诉我，打破JVM约束“很容易”，但我没有能力谈论这一点。硬件访问似乎是通过/dev/mem实现的，并且已经在java库中实现了。当然，它也在C库中实现——甚至可能作为某种类型的服务，但如果这种内存保护的东西真的起作用的话，我宁愿使用Java——移动部件更少，构建更简单，而且我学到了一些新东西：）