Revert "CHROMIUM: seccomp_filter: make inherited filters composable"

This reverts commit f6782d03ec66556e112073ce513dccaeba3c23ea.

https://lists.ubuntu.com/archives/kernel-team/2012-January/018695.html

"At this point, since there are no consumers of the old API, and it
will be almost certainly replaced by the BPF API, I think in the face
of the 5-year support of the LTS release, we should probably just
remove all of the seccomp_filter patches from Ubuntu." - Kees Cook

Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>

1 files changed, 28 insertions, 28 deletions

diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt
index e21ead792d0..88e1d3fa863 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -53,8 +53,7 @@ and one existing one.
 
 PR_SET_SECCOMP:
 	A pre-existing option for enabling strict seccomp mode (1) or
-	filtering seccomp (13).  Performing this call (13) will enable
-	the current set of defined filters.
+	filtering seccomp (13).
 
 	Usage:
 		prctl(PR_SET_SECCOMP, 1);  /* strict */
@@ -155,32 +154,33 @@ Inheritance
 -----------
 
 Changing the availability of the kernel ABI at runtime runs the risk of
-providing access to unreachable code paths in normal applications.  To
-avoid the pitfalls that accompany this risk, seccomp filter inheritance
-is restricted.
-
-Filters may be inherited across a fork/clone if they have been activated
-by a call to prctl(PR_SET_SECCOMP, 13).  If the process had the
-CAP_SYS_ADMIN capability when configuring the filters, they may also be
-inherited across an execve call.
-
-Inherited filters may not be modified by the child process.  If child
-would like to further restrict the available system calls, it may
-perform the same calls as discussed earlier: set, clear, get, and
-finally prctl(PR_SET_SECCOMP, 13).  Until the child calls
-PR_SET_SECCOMP, their filters will be ignored and only the inherited
-filter will be evaluated.  After a successful PR_SET_SECCOMP call, all
-system calls performed by the child will be checked against the filters
-that were specified by itself and then against the filters supplied by
-any ancestors.  Any system call used must be allowed by all of the
-filters tested.  This composition of the ancestral seccomp filters and
-process-local filters guarantees that only the minimal set of system calls
-will be permitted at any point and without child processes needing to be
-aware of any prior system call filtering.
-
-(If, for instance, the child process merely copied the parent filters
-and then extended them, the child would be required to enumerate all
-existing filters to determine which needed to be dropped.)
+providing access to normally unreachable code paths in normal
+applications.  To avoid the pitfalls that accompany this risk, seccomp
+filters inheritance is restricted.
+
+In general, filters can be inherited across fork/clone, but only when
+they are active (e.g., PR_SET_SECCOMP has been set to 13) and not prior
+to use.  Inheriting only active filters stops a parent process from
+adding filters that may undermine the child process security or create
+unexpected behavior after an execve.
+
+For example, a parent process may add a rule to exposes a system call
+that was not normally part of the child process' filter set.  When the
+child process configures its filters, it would have to check
+/proc/self/seccomp_filter to ensure nothing unexpected has been added.
+The standard inheritance behavior ensures this suboptimal situation is
+avoided.
+
+Inheritance across execve follows a subset of this behavior.  In
+particular, execve can only be added to the allowed filter set by a
+process with CAP_SYS_ADMIN privileges.  The result is that an
+unprivileged process can never create a seccomp filter set that can be
+inherited across execve.  To further guarantee this behavior, any
+unprivileged modifications to a seccomp filter set will forcibly
+clear execve.  The end result is that a privileged parent may install
+a set of seccomp filters and, at any point in the hierarchy, a child may
+make a private version of the inherited filter set with their own
+changes applied but execve blocked.
 
 
 Caveats