| Message ID | 20240710213230.11978-1-casey@schaufler-ca.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | LSM: Infrastructure blob allocation | expand |
On Wed, Jul 10, 2024 at 5:32 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > When more than one Linux Security Module (LSM) can use the security > blob for a partincular object the management of the memory associated > with that blob needs to be done by the infrastructure rather than the > individual modules. Until now, this has been done on an as needed basis, > with the blob management remaining in the modules until such time as a > new configuration of modules requires sharing the blob. This piecemeal > approach makes adding new modules that use blobs more difficult, as > moving the blob management to the infrastructure isn't as simple as > it might seem. This patch set moves management of the security blobs > that is done in the modules into the infrastructure. Making security > blob management more consistant improves mantainablity and makes the > possibilty of general improvement of LSM blob managment easier. > > No effort has been put into pursuing the possible performance > optimizations these changes introduce. For example, sk_security blobs > might be moved to use kmem_zone_alloc(). The option of changing the > blob sizes to being compile time determined rather than calculated at > run time has been considered for future exploration. > > In the cases where infrastructure blob freeing no longer requires > any special action on the part of any security module the hook > definition has been removed as it is no long necessary. > > Security blobs for the xfrm subsystem are problematic as the only > security module that implements them (SELinux) has a variable size blob > that has a published external API. Management of these blobs by the > infrastructure will require significant consideration and negotiation > with the maintainers of the existing code. This has been deferred until > such time as another user of xfrm appears. > > Casey Schaufler (6): > LSM: Infrastructure management of the sock security > LSM: Infrastructure management of the key security blob > LSM: Add helper for blob allocations > LSM: Infrastructure management of the dev_tun blob > LSM: Infrastructure management of the infiniband blob > LSM: Infrastructure management of the perf_event security blob > > include/linux/lsm_hook_defs.h | 8 +- > include/linux/lsm_hooks.h | 5 + > security/apparmor/include/net.h | 3 +- > security/apparmor/lsm.c | 17 +-- > security/apparmor/net.c | 2 +- > security/security.c | 184 +++++++++++++++++++++--------- > security/selinux/hooks.c | 157 +++++++++---------------- > security/selinux/include/objsec.h | 30 +++++ > security/selinux/netlabel.c | 23 ++-- > security/smack/smack.h | 12 ++ > security/smack/smack_lsm.c | 101 ++++++++-------- > security/smack/smack_netfilter.c | 4 +- > 12 files changed, 298 insertions(+), 248 deletions(-) Thanks Casey, these look good. I'm going to merge them in lsm/dev-staging now with the expectation that they'll be merged after the upcoming merge window closes.
On Thu, Jul 11, 2024 at 4:15 PM Paul Moore <paul@paul-moore.com> wrote: > On Wed, Jul 10, 2024 at 5:32 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > When more than one Linux Security Module (LSM) can use the security > > blob for a partincular object the management of the memory associated > > with that blob needs to be done by the infrastructure rather than the > > individual modules. Until now, this has been done on an as needed basis, > > with the blob management remaining in the modules until such time as a > > new configuration of modules requires sharing the blob. This piecemeal > > approach makes adding new modules that use blobs more difficult, as > > moving the blob management to the infrastructure isn't as simple as > > it might seem. This patch set moves management of the security blobs > > that is done in the modules into the infrastructure. Making security > > blob management more consistant improves mantainablity and makes the > > possibilty of general improvement of LSM blob managment easier. > > > > No effort has been put into pursuing the possible performance > > optimizations these changes introduce. For example, sk_security blobs > > might be moved to use kmem_zone_alloc(). The option of changing the > > blob sizes to being compile time determined rather than calculated at > > run time has been considered for future exploration. > > > > In the cases where infrastructure blob freeing no longer requires > > any special action on the part of any security module the hook > > definition has been removed as it is no long necessary. > > > > Security blobs for the xfrm subsystem are problematic as the only > > security module that implements them (SELinux) has a variable size blob > > that has a published external API. Management of these blobs by the > > infrastructure will require significant consideration and negotiation > > with the maintainers of the existing code. This has been deferred until > > such time as another user of xfrm appears. > > > > Casey Schaufler (6): > > LSM: Infrastructure management of the sock security > > LSM: Infrastructure management of the key security blob > > LSM: Add helper for blob allocations > > LSM: Infrastructure management of the dev_tun blob > > LSM: Infrastructure management of the infiniband blob > > LSM: Infrastructure management of the perf_event security blob > > > > include/linux/lsm_hook_defs.h | 8 +- > > include/linux/lsm_hooks.h | 5 + > > security/apparmor/include/net.h | 3 +- > > security/apparmor/lsm.c | 17 +-- > > security/apparmor/net.c | 2 +- > > security/security.c | 184 +++++++++++++++++++++--------- > > security/selinux/hooks.c | 157 +++++++++---------------- > > security/selinux/include/objsec.h | 30 +++++ > > security/selinux/netlabel.c | 23 ++-- > > security/smack/smack.h | 12 ++ > > security/smack/smack_lsm.c | 101 ++++++++-------- > > security/smack/smack_netfilter.c | 4 +- > > 12 files changed, 298 insertions(+), 248 deletions(-) > > Thanks Casey, these look good. I'm going to merge them in > lsm/dev-staging now with the expectation that they'll be merged after > the upcoming merge window closes. These are now in lsm/dev, thanks!