On Fri, Jul 22, 2022 at 1:05 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Frederick Lawler <fred@xxxxxxxxxxxxxx> writes: > > > While creating a LSM BPF MAC policy to block user namespace creation, we > > used the LSM cred_prepare hook because that is the closest hook to prevent > > a call to create_user_ns(). > > That description is wrong. Your goal his is not to limit access to > the user namespace. Your goal is to reduce the attack surface of the > kernel by not allowing some processes access to a user namespace. > > You have already said that you don't have concerns about the > fundamentals of the user namespace, and what it enables only that > it allows access to exploitable code. > > Achieving the protection you seek requires talking and thinking clearly > about the goal. Providing a single concrete goal for a LSM hook is always going to be a challenge due to the nature of the LSM layer and the great unknown of all the different LSMs that are implemented underneath the LSM abstraction. However, we can make some very general statements such that up to this point the LSMs that have been merged into mainline generally provide some level of access control, observability, or both. While that may change in the future (the LSM layer does not attempt to restrict LSMs to just these two ideas), I think they are "good enough" goals for this discussion. In addition to thinking about these goals, I think it also important to take a step back and think about the original motivation for the LSM and why it, and Linux itself, has proven to be popular with everything from the phone in your hand to the datacenter servers powering ... pretty much everything :) Arguably Linux has seen such profound success because of its malleability; the open nature of the kernel development process has allowed the Linux Kernel to adopt capabilities well beyond what any one dev team could produce, and as Linux continues to grow in adoption, its ability to flex into new use cases only increases. The kernel namespace concept is an excellent example of this: virtualizing core kernel ideas, such as user credentials, to provide better, safer solutions. It is my belief that the LSM layer is very much built around this same idea of abstracting and extending core kernel concepts, in this case security controls, to provide better solutions. Integrating the LSM into the kernel's namespaces is a natural fit, and one that is long overdue. If we can't find a way to make everyone happy here, let's at least try to find a way to make everyone "okay" with adding a LSM hook to the user namespace. If you want to NACK this approach Eric, that's okay, but please provide some alternative paths forward that we can discuss. -- paul-moore.com
