> Filter programs may _only_ cross the execve(2) barrier if last filter > program was attached by a task with CAP_SYS_ADMIN capabilities in its > user namespace. Once a task-local filter program is attached from a > process without privileges, execve will fail. This ensures that only > privileged parent task can affect its privileged children (e.g., setuid > binary). I think this model is wrong. The rest of the policy rules all work on the basis that dumpable is the decider (the same rules for not dumping, not tracing, etc). A user should be able to apply filter to their own code arbitarily. Any setuid app should IMHO lose the trace subject to the usual uid rules and capability rules. That would seem to be more flexible and also the path of least surprise. [plus you can implement non setuid exec entirely in userspace so it's a rather meaningless distinction you propose] > be tackled separately via separate patchsets. (And at some point sharing > BPF JIT code!) A BPF jit ought to be trivial and would be a big win. In general I like this approach. It's simple, it's compact and it offers interesting possibilities for solving some interesting problem spaces, without the full weight of SELinux, SMACK etc which are still needed for heavyweight security. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
