From: Casey Schaufler <casey@schaufler-ca.com>
To: casey@schaufler-ca.com, paul@paul-moore.com,
linux-security-module@vger.kernel.org
Cc: jmorris@namei.org, serge@hallyn.com, keescook@chromium.org,
john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
stephen.smalley.work@gmail.com, mic@digikod.net
Subject: [PATCH 0/6] LSM: Infrastructure blob allocation
Date: Mon, 8 Jul 2024 14:39:51 -0700 [thread overview]
Message-ID: <20240708213957.20519-1-casey@schaufler-ca.com> (raw)
In-Reply-To: 20240708213957.20519-1-casey.ref@schaufler-ca.com
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.
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 | 4 +-
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 | 166 +++++++++++++++++++++---------
security/selinux/hooks.c | 159 ++++++++++------------------
security/selinux/include/objsec.h | 30 ++++++
security/selinux/netlabel.c | 23 +++--
security/smack/smack.h | 12 +++
security/smack/smack_lsm.c | 103 +++++++++---------
security/smack/smack_netfilter.c | 4 +-
12 files changed, 288 insertions(+), 240 deletions(-)
--
2.41.0
next parent reply other threads:[~2024-07-08 21:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240708213957.20519-1-casey.ref@schaufler-ca.com>
2024-07-08 21:39 ` Casey Schaufler [this message]
2024-07-08 21:39 ` [PATCH 1/6] LSM: Infrastructure management of the sock security Casey Schaufler
2024-07-09 19:15 ` Paul Moore
2024-07-09 23:00 ` Casey Schaufler
2024-07-09 23:05 ` Paul Moore
2024-07-09 23:29 ` Casey Schaufler
2024-07-10 0:00 ` Paul Moore
2024-07-09 22:08 ` Paul Moore
2024-07-09 22:32 ` John Johansen
2024-07-08 21:39 ` [PATCH 2/6] LSM: Infrastructure management of the key security blob Casey Schaufler
2024-07-09 22:08 ` Paul Moore
2024-07-09 22:47 ` John Johansen
2024-07-09 23:01 ` Paul Moore
2024-07-08 21:39 ` [PATCH 3/6] LSM: Add helper for blob allocations Casey Schaufler
2024-07-09 22:08 ` Paul Moore
2024-07-09 23:09 ` Casey Schaufler
2024-07-10 0:01 ` Paul Moore
2024-07-09 22:51 ` John Johansen
2024-07-08 21:39 ` [PATCH 4/6] LSM: Infrastructure management of the dev_tun blob Casey Schaufler
2024-07-09 22:08 ` Paul Moore
2024-07-09 23:01 ` John Johansen
2024-07-09 23:11 ` Casey Schaufler
2024-07-08 21:39 ` [PATCH 5/6] LSM: Infrastructure management of the infiniband blob Casey Schaufler
2024-07-09 22:08 ` Paul Moore
2024-07-09 23:38 ` John Johansen
2024-07-08 21:39 ` [PATCH 6/6] LSM: Infrastructure management of the perf_event security blob Casey Schaufler
2024-07-09 22:08 ` Paul Moore
2024-07-09 23:47 ` John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240708213957.20519-1-casey@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=serge@hallyn.com \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox