On Fri, 25 May 2018, Eric W. Biederman wrote: > James Morris <jmorris@xxxxxxxxx> writes: > > > On Thu, 24 May 2018, Eric W. Biederman wrote: > > > >> Below is where I suggest you start on sorting out these security hooks. > >> - Adding a security_kernel_arg to catch when you want to allow/deny the > >> use of an argument to a syscall. What security_kernel_file_read and > >> security_kernel_file_post_read have been abused for. > > > > NAK. This abstraction is too semantically weak. > > > > LSM hooks need to map to stronger semantics so we can reason about what > > the hook and the policy is supposed to be mediating. > > I will take that as an extremely weak nack as all I did was expose the > existing code and what the code is currently doing. I don't see how you > can NAK what is already being merged and used. It's a strong NAK. LSM is a logical API, it provides an abstraction layer for security policies to mediate kernel security behaviors. Adding an argument to a syscall is not a security behavior. Loading a firmware file is. = -- James Morris <jmorris@xxxxxxxxx>
