summaryrefslogtreecommitdiffstats
path: root/fs/9p/Makefile
diff options
context:
space:
mode:
authorJann Horn <jannh@google.com>2019-04-10 09:56:05 -0700
committerMicah Morton <mortonm@chromium.org>2019-07-15 08:07:29 -0700
commit03638e62f55f27e7a96d6b1175e75b7a81e562b3 (patch)
tree75a711e1f8e03fcddcc50b58db6324e64f564a08 /fs/9p/Makefile
parent71a98971b932174e121bc19056475c601598132f (diff)
downloadlinux-03638e62f55f27e7a96d6b1175e75b7a81e562b3.tar.bz2
LSM: SafeSetID: rewrite userspace API to atomic updates
The current API of the SafeSetID LSM uses one write() per rule, and applies each written rule instantly. This has several downsides: - While a policy is being loaded, once a single parent-child pair has been loaded, the parent is restricted to that specific child, even if subsequent rules would allow transitions to other child UIDs. This means that during policy loading, set*uid() can randomly fail. - To replace the policy without rebooting, it is necessary to first flush all old rules. This creates a time window in which no constraints are placed on the use of CAP_SETUID. - If we want to perform sanity checks on the final policy, this requires that the policy isn't constructed in a piecemeal fashion without telling the kernel when it's done. Other kernel APIs - including things like the userns code and netfilter - avoid this problem by performing updates atomically. Luckily, SafeSetID hasn't landed in a stable (upstream) release yet, so maybe it's not too late to completely change the API. The new API for SafeSetID is: If you want to change the policy, open "safesetid/whitelist_policy" and write the entire policy, newline-delimited, in there. Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
Diffstat (limited to 'fs/9p/Makefile')
0 files changed, 0 insertions, 0 deletions