与不可信进程共享内存安全吗？

Question

我正在尝试创建一个x86 Linux程序，该程序以更高的权限运行，但也可以在子进程中运行可能不安全的代码，并通过共享内存与其通信，这主要是出于性能原因。我的想法是这样的：

根进程分配内存和MAP_SHARED|MAP_ANONYMOUS

• It分叉，子进程调用setuid并加载用户提供的代码afterwards.

• The子进程不再受信任。

事后访问共享内存的缺陷是什么？显然，子进程可以在任何时候提供无效的数据并对其进行更改，但是它实际上是否会以其他方式损害父进程，比如阻止内存访问，甚至杀死它或任何类似的东西？

或者使用memcpy()是否安全？

原子操作安全吗？sem_timedwait？

Answer 1

如果你只将内存用于简单的操作，比如memcpy，孩子就不能直接伤害你，但是如果你真的不信任他们，那么分享又有什么意义呢？

把信号量放在记忆中是个坏主意；同样，你不能信任他们，这意味着，你不能信任他们。信号灯，互斥声，秃鹰，.只有在高度的信任下才能工作。消息传递更好，但不需要共享内存。

我能想象的最糟糕的是一次轻微的拒绝服务攻击。在I/O期间，页面通常不可访问。如果您的孩子分叉了自己的许多副本，并设法不断地指向共享页面，那么它可能会在很大程度上扰乱父程序的执行进度。

有些人有比我更狡猾的想象力。

Answer 2

在这个答案中，我将尝试收集我所能找到的关于共享内存IPC的局限性的任何东西，其中包含一个敌对的进程和对策。

如果你发现一个错误或更好的东西，请纠正我！

使用只读映射进行单向通信

http://selinuxsymposium.org/2007/papers/11-SecureIPC.pdf

在3.3节中，本文指出进程A可以创建具有读/写访问权限的共享内存，而进程B只能被限制为只读访问。

如果根进程希望将数据发送到包含不可被子进程操作的脆弱数据结构的子进程，则可以使用只读映射。

但是，我不确定上述内容是否只适用于SELinux，如何实际执行，或者是否只能使用mmap完成。

在这里也有类似的说法：

Shared Memory when it's for read only

同步问题

Linux shared memory only allow read access

“共享内存涉及各种奇怪的同步问题”。

不幸的是没有更多的细节。

键.内存保护键

https://lwn.net/Articles/466304/

只限于英特尔Skylake

2011年LWN文章比较了各种IPC机制

https://lwn.net/Articles/466304/

LWN关于铬与seccomp砂盒通讯的文章

https://lwn.net/Articles/347547/

铬砂箱常见问题

https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox_faq.md#But-can_t-malware-just-infect-the-process-at-the-other-end-of-the-pipe-or-shared-memory

“但是，恶意软件不能只感染管道另一端的进程或共享内存吗?是的，如果存在错误，就有可能。关键是，编写和分析正确的IPC机制比web浏览器引擎更容易。努力使IPC代码尽可能简单，并让其他人对其进行审查。”

所以Chromium正在做某种共享内存IPC！