• Jann Horn's avatar
    LSM: SafeSetID: rewrite userspace API to atomic updates · 03638e62
    Jann Horn authored
    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: default avatarJann Horn <jannh@google.com>
    Signed-off-by: default avatarMicah Morton <mortonm@chromium.org>
    03638e62
securityfs.c 4.27 KB