如何在沒有root權限的情況下“監禁”一個程序？
如果我是 root，我可以簡單地創建一個虛擬使用者/組，相應地設置文件權限並以該使用者身份執行該過程。但是我不是，那麼有沒有辦法在不成為root的情況下實現這一目標？
更多類似Qs更多答案值得關注：
- https://stackoverflow.com/q/3859710/94687
- https://stackoverflow.com/q/4410447/94687
- https://stackoverflow.com/q/4249063/94687
- https://stackoverflow.com/q/1019707/94687
**注意：**那裡的一些答案指向此處尚未提及的特定解決方案。
實際上，有相當多的監獄工具具有不同的實現，但它們中的許多要麼在設計上不安全（如
fakeroot,LD_PRELOAD-based），要麼不完整（如fakeroot-ng, -basedptrace），或者需要 root (chroot，或者plash在fakechroot中提到警告標籤）。這些只是例子；我想將它們並排列出，並指出這兩個特性（“可以信任嗎？”、“需要 root 才能設置？”），也許在Operating-system-level virtualization Implementations。
一般來說，那裡的答案涵蓋了所有描述的可能性範圍，甚至更多：
虛擬機/作業系統
核心擴展（如 SELinux）
- （在這裡的評論中提到），
chroot
基於 Chroot 的助手（但是必須是 setUID root，因為
chroot需要 root；或者可能chroot可以在隔離的命名空間中工作——見下文）：$$ to tell a little more about them! $$
已知的基於 chroot 的隔離工具：
跟踪
另一個值得信賴的隔離解決方案（除了基於-
seccomp的解決方案）將是通過 的完整系統呼叫攔截ptrace，如手冊頁中所述fakeroot-ng：與以前的實現不同，fakeroot-ng 使用的技術使被跟踪的程序無法選擇是否使用 fakeroot-ng 的“服務”。靜態編譯程序、直接呼叫核心和操作自己的地址空間都是可以用來繞過基於 LD_PRELOAD 的程序控制的技術，但不適用於 fakeroot-ng。從理論上講，可以以完全控制跟踪過程的方式塑造 fakeroot-ng。
雖然理論上是可行的，但還沒有做到。Fakeroot-ng 確實對被跟踪的過程做出了某些“行為良好”的假設，並且打破這些假設的過程可能能夠（如果不能完全逃脫），那麼至少可以規避 fakeroot 強加給它的一些“假”環境-吳。因此，強烈警告您不要使用 fakeroot-ng 作為安全工具。Bug 報告聲稱一個程序可以故意（而不是無意地）逃脫 fake-root-ng 的控制，要麼被關閉為“不是 bug”，要麼被標記為低優先級。
將來可能會重新考慮這項政策。但是，目前，您已被警告。
儘管如此，正如您所讀到的，它
fakeroot-ng本身並不是為此目的而設計的。（順便說一句，我想知道為什麼他們選擇
seccomp對 Chromium 使用基於 - 的方法而不是ptrace基於 -…）在上面沒有提到的工具中，我自己注意到了**Geordi**，因為我喜歡控製程序是用 Haskell 編寫的。
已知的基於 ptrace 的隔離工具：
秒算
實現隔離的一種已知方法是通過Google Chromium 中使用的 seccomp 沙盒方法。但是這種方法假設您編寫了一個助手來處理“攔截”文件訪問和其他系統呼叫中的一些（允許的）；當然，還要努力“攔截”系統呼叫並將它們重定向到幫助程序（也許，這甚至意味著在受控程序的程式碼中替換被攔截的系統呼叫；所以，這聽起來不很簡單；如果您有興趣，最好閱讀詳細資訊，而不僅僅是我的回答）。
更多相關資訊（來自維基百科）：
- http://en.wikipedia.org/wiki/Seccomp
- http://code.google.com/p/seccompsandbox/wiki/overview
- LWN 文章：Google 的 Chromium 沙箱，Jake Edge，2009 年 8 月
- seccomp-nurse，一個基於 seccomp 的沙盒框架。
（如果有人在 Chromium 之外尋找基於通用
seccomp的解決方案，最後一項似乎很有趣。“seccomp-nurse”的作者還有一篇博文值得一讀：SECCOMP as a Sandboxing solution ? .）“seccomp-nurse”項目對這種方法的說明：
Linux 未來可能出現“靈活”的 seccomp 嗎？
曾經在 2009 年出現過對 Linux 核心進行修補的建議，以便該
seccomp模式具有更大的靈活性——這樣“我們目前需要的許多雜技可以避免”。（“雜技”是指編寫一個必須代表被監禁程序執行許多可能無辜的系統呼叫的助手以及在被監禁的程序中替換可能無辜的系統呼叫的複雜性。）一篇 LWN 文章寫到這一點：提出的一個建議是為 seccomp 添加一個新的“模式”。API 的設計理念是不同的應用程序可能有不同的安全要求；它包括一個“模式”值，它指定應該實施的限制。只有原始模式已經實現，但當然可以添加其他模式。創建一個允許啟動程序指定允許哪些系統呼叫的新模式將使該工具在 Chrome 沙箱等情況下更有用。
Adam Langley（也是 Google 的）發布了一個更新檔來實現這一點。新的“模式 2”實現接受描述哪些系統呼叫可訪問的位遮罩。如果其中之一是 prctl()，則沙盒程式碼可以進一步限制其自己的系統呼叫（但它無法恢復對已被拒絕的系統呼叫的訪問）。總而言之，它看起來是一個合理的解決方案，可以讓沙盒開發人員的生活更輕鬆。
也就是說，這段程式碼可能永遠不會被合併，因為討論已經轉向了其他可能性。
這種“靈活的 seccomp”將使 Linux 的可能性更接近於在作業系統中提供所需的功能，而無需編寫那麼複雜的幫助程序。
（與此答案內容基本相同的部落格文章：http: //geofft.mit.edu/blog/sipb/33。）
命名空間 (
unshare)通過命名空間隔離（
unshare基於 - 的解決方案）——這裡沒有提到——例如，取消共享掛載點（與 FUSE 結合使用？）可能是您想要限制不受信任程序的文件系統訪問的工作解決方案的一部分。現在更多關於命名空間的資訊，因為它們的實現已經完成（這種隔離技術在 nme **“Linux Containers” 或 “LXC”**下也被稱為，不是嗎？…）：
“命名空間的總體目標之一是支持容器的實現，這是一種用於輕量級虛擬化（以及其他目的）的工具”。
甚至可以創建一個新的使用者命名空間，這樣“一個程序可以在使用者命名空間之外擁有一個普通的非特權使用者 ID，同時在命名空間內擁有一個使用者 ID 0。這意味著該程序具有完全的 root 權限用於使用者命名空間內的操作，但對命名空間外的操作無特權”。
有關執行此操作的實際工作命令，請參見以下位置的答案：
和特殊的使用者空間程式/編譯
但是，當然，所需的“監獄”保證可以通過在使用者空間中程式來實現（無需作業系統對此功能的額外支持；也許這就是為什麼該功能沒有首先包含在作業系統設計中的原因); 或多或少的並發症。
提到
ptrace的或seccomp基於沙盒的沙盒可以看作是通過編寫沙盒助手來實現保證的一些變體，該沙盒助手將控制您的其他程序，這些程序將被視為“黑匣子”，任意 Unix 程序。另一種方法可能是使用可以關心必須禁止的效果的程式技術。（那時一定是你編寫程序；它們不再是黑匣子了。）要提一提的是，使用像Haskell這樣的純程式語言（這將迫使你在沒有副作用的情況下進行程式）將簡單地使程序顯式，因此程序員可以輕鬆確保不會出現不允許的效果。
我想，對於那些用其他語言（例如 Java）進行程式的人來說，有可用的沙盒工具。
- 參照。“沙盒 Haskell”項目提案。
- NaCl——這裡沒有提到——屬於這個組，不是嗎？
那裡的答案也指出了一些積累有關此主題的資訊的頁面：
