具有不受信任的进程的共享内存是否安全？

Question

我正在尝试创建一个以提升的特权运行的x86 Linux程序，但也可能在子进程中运行潜在的不安全代码，并通过共享内存与其通信，这主要是出于性能方面的考虑。我的想法如下：

• 根进程使用mmap和MAP_SHARED|MAP_ANONYMOUS分配内存
• 它分叉，子进程调用setuid并随后加载用户提供的代码。
• 子进程不再受信任。

事后访问共享内存的陷阱是什么？显然，子进程可以提供无效的数据并随时对其进行更改，但是它实际上可以通过阻止内存访问，甚至杀死它或其他类似方法以其他方式损害父进程吗？

或者使用安全吗？ memcpy（）？

原子操作安全吗？ sem_timedwait？

Answer 1

如果仅将内存用于简单操作（如memcpy），则孩子不会直接伤害您，但是如果您真的不信任它们，共享的意义何在？

在内存中放置一个信号量是一个坏主意；同样，您不能信任他们，这意味着，您不能信任他们。信号量，互斥量，condvars ...仅在高度信任的情况下起作用。消息传递比较好，但是不需要共享内存。

我能想到的最糟糕的情况是轻微的拒绝服务攻击。在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

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

很遗憾，没有更多细节。

pkeys-内存保护键

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

仅限Intel Skylake

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

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

有关Chromium与seccomp沙箱通信的LWN文章

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机制要容易得多。力求使IPC代码尽可能简单，并让其他人对其进行审查。“

因此Chromium正在执行某种共享内存IPC！