[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aae5d7de-d3ff-4a67-a8f6-fea293bee0f6@schaufler-ca.com>
Date: Fri, 21 Jun 2024 15:24:20 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.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,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v39 02/42] SM: Infrastructure management of the sock
security
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?
Powered by blists - more mailing lists