Seccomp(secure computing)是Linux kernel （自從2.6.23版本之後）所支持的一種簡潔的sandboxing機制。它能使一個進程進入到一種“安全”運行模式，該模式下的進程只能調用4種系統調用（system calls），即read(), write(), exit()和sigreturn()，否則進程便會被終止。
Seccomp是Andrea Arcangeli在2005年設計的，其目的是解決grid computing中的安全問題，比如你打算出租你的CPU資源，但又擔心不可信的代碼會破壞你的系統。那麼，Seccomp則可以為“不可信的純計算型代碼”提供一個“安全（SAFE, not SECURE）”的運行環境，以保護你的系統和應用程序的正常運行不受不可信代碼的干擾。
據說Google Chrome浏覽器的開發人員曾經考慮過使用Seccomp來建立Chrome Sandbox，但考慮到Seccomp的一些不足而“另辟蹊徑”—— Native Client 。『據了解，Google Chrome 4 在今年 CanSecWest Applied Security 大會上是唯一沒有被當場攻破的浏覽器，而IE8 on Windows7/Vista/XP, Mozilla Firefox 3 和 Apple Safari 4 都相繼被攻破。』
簡潔、優美是Seccomp的優點，但只能支持“純計算型”代碼卻使得其應用受到很大限制。比如，Seccomp模式的進程不能動態分配內存、不能與其它進程使用共享內存、不能使用新的文件描述符、等等。如果要支持具有豐富功能的應用程序，則需要另外的方法來截獲並處理其它系統調用。
有人提議對seccomp進行改進使其支持對系統調用提供更細粒度的控制。比如，對seccomp增加一個新的mode，使用一個bitmap來精確描述哪些系統調用是可以被訪問的，而哪些是被禁止的。而進程自己還可以丟棄（但不能重新獲取）它所具有的訪問哪些系統調用的能力（這種工作方法有點像Linux capability安全機制，盡管這兩者是完全正交的）。但是到今天為止，還沒有看到相關的進展，據說是因為ftrace也支持類似的功能，如何裁定還需要進一步討論。
通過截獲系統調用來實現sandbox是一貫的做法，它假設Kernel是好人，而User不一定是好人。在現代操作系統中，User和Kernel的空間是隔離的，一個進程只能通過系統調用才能從user空間進入kernel空間。如果一個進程不需要執行系統調用（即不需要kernel提供的豐富功能），那麼我們的系統被攻擊的風險就小。當然假設進程不使用系統調用是不切實際的，但對今天的多數系統來說，為用戶程序提供的豐富功能是以犧牲安全性為代價的。但是，“僅僅通過截獲並處理系統調用的方法去實現sandbox”是否是正確的技術方向呢？我們知道，當系統調用的參數保存在用戶空間的時候，要想驗證該參數是否“安全”是非常困難的，比如TOC2TOU問題便是一個挑戰：一個惡意進程可能會在“參數被安全檢查”之後、而在“實際使用參數”之前將該參數換掉，這便使截獲系統調用時所做的參數檢查變得沒有意義。要解決這個問題，我們也許不應當只將目光鎖定在系統調用的入口處。
sandboxing一直以來都是一個大難題，對於今天的COTS OS來說還不存在一個通用的安全方案。如何去做滿足自己需要的sandbox，則需要量體裁衣。