> > > BPF LSM); while the sys admin can configure permissions of the pseudo > > files in user space. > > > Other LSMs also have policy that can control access to pseudo filesystems and > other resources. Again, the control doesn't have to be hard coded. And seccomp can > be used to block the syscall. > > > > > > Again, each module decides which operations to expose through this syscall.â?¯In many cases > > > the operation will still require CAP_SYS_ADMIN or a similar capability, so environments > > > that choose this interface remain secure while gaining its advantages. > > > > > > > > - Avoids overhead of other kernel interfaces for better efficiency > > > > > > > > .. and it is is probably less efficient, because everything need to > > > > fit in the same API. > > > > > > As shown below, the syscall can significantly improve the performance of policy management. > > > A more detailed benchmark is available inâ?¯[1]. > > > > > > The following table presents the time required to load an AppArmor profile. > > > > > > For every cell, the first value is the total time taken by aa-load, and the value in > > > parentheses is the time spent to load the policy in the kernel only (totalâ?¯-â?¯dryâ??run). > > > > > > Results are in microseconds and are averaged over 10â?¯000 runs to reduce variance. > > > > > > > > > | t (µs) | syscall | pseudofs | Speedup | > > > |-----------|-------------|-------------|---------------| > > > | 1password | 4257 (1127) | 3333 (192) | x1.28 (x5.86) | > > > | Xorg | 6099 (2961) | 5167 (2020) | x1.18 (x1.47) | > > > > > > > I am not sure the performance of loading security policies is on any > > critical path. > > generally speaking I agree, but I am also not going to turn down a > performance improvement either. Its a nice to have, but not a strong > argument for need. > > > The implementation calls the hook for each LSM, which is why I think the > > syscall is not efficient. > > > it should only call the LSM identified by the lsmid in the call. > > > Overall, I am still not convinced a syscall for all LSMs is needed. To > > justify such > > its not needed by all LSMs, just a subset of them, and some nebulous > subset of potentially future LSMs that is entirely undefinable. > > If we had had appropriate LSM syscalls landlock wouldn't have needed > to have landlock specific syscalls. Having another LSM go that route > feels wrong especially now that we have some LSM syscalls. I don't agree. Dedicated syscalls are a good thing. See my other reply. > If a > syscall is needed by an LSM its better to try hashing something out > that might have utility for multiple LSMs or at the very least, > potentially have utility in the future. > > > > a syscall, I think we need to show that it is useful in multiple LSMs. > > Also, if we > > really want to have single set of APIs for all LSMs, we may also need > > get_policy, > > We are never going to get a single set of APIs for all LSMs. I will > settle for an api that has utility for a subset > > > remove_policy, etc. This set as-is appears to be an incomplete design. The > > To have a complete design, there needs to be feedback and discussion > from multiple LSMs. This is a starting point. > > > implementation, with call_int_hook, is also problematic. It can easily > > cause some> controversial behaviors. > > > agreed it shouldn't be doing a straight call_int_hook, it should only > call it against the lsm identified by the lsmid Yes, but then, I don't see the point of a "generic" LSM syscall.
