Re: [PATCH v24 00/25] LSM: Module stacking for AppArmor

On 2/2/2021 9:12 AM, Topi Miettinen wrote: Dealing with SO_PEERSEC has been discussed at length, and I wouldn't say that anyone is really happy with the conclusions. The patch set presented uses the interface_lsm to determine which module's data is presented in SO_PEERSEC. The interface_lsm is controlled by writing the desired security module name to /proc/self/attr/interface_lsm. The addition of SO_PEERCONTEXT, which would contain all active security module data, has been proposed as a follow-on but is not included in this patch set. It's unfortunate that the early days of the LSM where dominated by the mindset that security had to be a complete solution. I was in that camp myself for a good long time, but came to recognize that attempting to solve all security problems for everyone using one mechanism was destined to excess. Because user-space development has assumed a single LSM for so long it's hard to imagine that there won't need to be changes in both the libraries and the programs. Because SELinux has the longest history and most complete distribution integration it will also have the most trouble with sharing the LSM stack. I expect so eventually. The SELinux developers have not been especially enthusiastic about the prospect of module stacking. Once it is available I expect to see some accommodation, but not necessarily to the level you might like. The patch set here is strongly influenced by the assumption that putting the most highly integrated module first (SELinux on Fedora, AppArmor on Ubuntu, Smack on Tizen, ...) is going to get you most of what you need. Whoever wants to add Smack to Ubuntu is going to have some work to do. Stacking AppArmor with SELinux is a real use case in the container world, but that's not the real focus of this effort. I have seen several cases where security features have not been implemented because they couldn't be added to a system that also required SELinux, AppArmor or Smack. I have seen many proposals for changes to existing security modules that where outside their scope just because there was no other way. Great to hear. Thanks again.