[PATCH v39 02/42] SM: Infrastructure management of the sock security
Paul Moore
paul at paul-moore.com
Fri Jun 21 20:31:27 UTC 2024
On Fri, Dec 15, 2023 at 5:18 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> Move management of the sock->sk_security blob out
> of the individual security modules and into the security
> infrastructure. Instead of allocating the blobs from within
> the modules the modules tell the infrastructure how much
> space is required, and the space is allocated there.
>
> Acked-by: Paul Moore <paul at paul-moore.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>
> Reviewed-by: John Johansen <john.johansen at canonical.com>
> Acked-by: Stephen Smalley <stephen.smalley.work at gmail.com>
> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
> ---
> include/linux/lsm_hooks.h | 1 +
> security/apparmor/include/net.h | 3 +-
> security/apparmor/lsm.c | 20 +-------
> security/apparmor/net.c | 2 +-
> security/security.c | 36 ++++++++++++++-
> security/selinux/hooks.c | 76 ++++++++++++++-----------------
> security/selinux/include/objsec.h | 5 ++
> security/selinux/netlabel.c | 23 +++++-----
> security/smack/smack.h | 5 ++
> security/smack/smack_lsm.c | 70 ++++++++++++++--------------
> security/smack/smack_netfilter.c | 4 +-
> 11 files changed, 131 insertions(+), 114 deletions(-)
I had to do some minor merge fixups, but I just merged this into the
lsm/dev-staging branch to do some testing, assuming all goes well I'll
move this over to the lsm/dev branch; I'll send another note if/when
that happens.
One of the things that has bothered me about the LSM framework is the
inconsistency around allocation and management of the LSM security
blobs (the `void *security` fields present in many kernel objects).
In some cases the framework itself manages these fields, in other
cases it is left up to the individual LSMs; while there are reasons
for this (move to the framework on an as-needed basis), it is a little
odd and with any inconsistency I worry about the potential for bugs.
I think moving the allocation and management of all the LSM blobs into
the LSM framework, similar to what was done here with the sock's
sk_security field, would be a Very Good Thing and help bring some
additional consistency to the LSM interfaces. Looking quickly at only
the SELinux code, I see six additional blobs that would need to be
converted; it's possible there are others in use by other LSMs, but I
haven't checked.
Casey, is this something you would be interested in pursuing or would
you rather I give it a shot?
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list