linux-kernel - Re: [PATCH v39 02/42] SM: Infrastructure management of the sock security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhTK0etXQ3X4g4E-v_d3f50waoatbC2ihJ8vOV2RmwMYPQ@mail.gmail.com>
Date: Sun, 23 Jun 2024 15:57:54 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: linux-security-module@...r.kernel.org, jmorris@...ei.org, serge@...lyn.com, 
	keescook@...omium.org, john.johansen@...onical.com, 
	penguin-kernel@...ove.sakura.ne.jp, stephen.smalley.work@...il.com, 
	linux-kernel@...r.kernel.org, mic@...ikod.net
Subject: Re: [PATCH v39 02/42] SM: Infrastructure management of the sock security

On Fri, Jun 21, 2024 at 6:24 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 6/21/2024 1:31 PM, Paul Moore wrote:
> > On Fri, Dec 15, 2023 at 5:18 PM Casey Schaufler <casey@...aufler-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@...l-moore.com>
> >> Reviewed-by: Kees Cook <keescook@...omium.org>
> >> Reviewed-by: John Johansen <john.johansen@...onical.com>
> >> Acked-by: Stephen Smalley <stephen.smalley.work@...il.com>
> >> Signed-off-by: Casey Schaufler <casey@...aufler-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?
>
> I'm happy to do it. Would you like a separate patch set for this, or
> should I add it to the stacking mega-set?

Separate patchset please, in my mind this is more about improving the
consistency of the LSM interface ;)

-- 
paul-moore.com