LSM: Replace secctx/len pairs with lsm_context

Several of the Linux Security Module (LSM) interfaces use a pair of
pointers for transmitting security context data and data length. The
data passed is refered to as a security context.  While all existing
modules provide nul terminated strings, there is no requirement that
they to so. Hence, the length is necessary.

Security contexts are provided by a number of interfaces. The interface
security_release_secctx() is used when the caller is finished with the
data. Each of the security modules that provide security contexts manages
them differently. This was safe in the past, because only one security
module that provides security contexts is allowed to be active. To allow
multiple active modules that use security contexts it is necessary to
identify which security module created a security context. Adding a third
pointer to the interfaces for the LSM identification is not appealing.

A new structure, lsm_context, is created for use in these interfaces.
It includes three members: the data pointer, the data length and
the LSM ID of its creator. The interfaces that create contexts and
security_release_secctx() now use a pointer to an lsm_context instead
of a pointer pair.

The changes are mostly mechanical, and some scaffolding is used within
the patch set to allow for smaller individual patches.

This patch set depends on the patch set LSM: Move away from secids:
	https://github.com/cschaufler/lsm-stacking.git#lsmprop-6.12-rc1-v4

https://github.com/cschaufler/lsm-stacking.git#context-6.12-rc1-v2

Revisons:
	v2: Rebase for static calls in LSM infrastructure

Casey Schaufler (6):
  LSM: Ensure the correct LSM context releaser
  LSM: Replace context+len with lsm_context
  LSM: Use lsm_context in security_inode_getsecctx
  LSM: lsm_context in security_dentry_init_security
  LSM: secctx provider check on release
  LSM: Use lsm_context in security_inode_notifysecctx

 drivers/android/binder.c                | 25 +++++----
 fs/ceph/super.h                         |  3 +-
 fs/ceph/xattr.c                         | 12 ++---
 fs/fuse/dir.c                           | 35 +++++++------
 fs/nfs/dir.c                            |  2 +-
 fs/nfs/inode.c                          | 16 +++---
 fs/nfs/internal.h                       |  8 +--
 fs/nfs/nfs4proc.c                       | 16 +++---
 fs/nfs/nfs4xdr.c                        | 22 ++++----
 fs/nfsd/nfs4xdr.c                       | 22 ++++----
 include/linux/lsm_hook_defs.h           | 16 +++---
 include/linux/nfs4.h                    |  8 +--
 include/linux/nfs_fs.h                  |  2 +-
 include/linux/security.h                | 41 +++++++++------
 include/net/scm.h                       | 12 ++---
 kernel/audit.c                          | 33 ++++++------
 kernel/auditsc.c                        | 27 +++++-----
 net/ipv4/ip_sockglue.c                  | 12 ++---
 net/netfilter/nf_conntrack_netlink.c    | 16 +++---
 net/netfilter/nf_conntrack_standalone.c | 11 ++--
 net/netfilter/nfnetlink_queue.c         | 22 ++++----
 net/netlabel/netlabel_unlabeled.c       | 44 +++++++---------
 net/netlabel/netlabel_user.c            | 10 ++--
 security/apparmor/include/secid.h       |  7 ++-
 security/apparmor/secid.c               | 31 +++++------
 security/security.c                     | 70 +++++++++++--------------
 security/selinux/hooks.c                | 52 ++++++++++++------
 security/smack/smack_lsm.c              | 55 +++++++++++--------
 28 files changed, 325 insertions(+), 305 deletions(-)

-- 
2.46.0

On Mon, Oct 14, 2024 at 08:14:44AM -0700, Casey Schaufler wrote:
> LSM: Replace secctx/len pairs with lsm_context
> 
> Several of the Linux Security Module (LSM) interfaces use a pair of
> pointers for transmitting security context data and data length. The
> data passed is refered to as a security context.  While all existing
> modules provide nul terminated strings, there is no requirement that
> they to so. Hence, the length is necessary.
> 
> Security contexts are provided by a number of interfaces. The interface
> security_release_secctx() is used when the caller is finished with the
> data. Each of the security modules that provide security contexts manages
> them differently. This was safe in the past, because only one security
> module that provides security contexts is allowed to be active. To allow
> multiple active modules that use security contexts it is necessary to
> identify which security module created a security context. Adding a third
> pointer to the interfaces for the LSM identification is not appealing.
> 
> A new structure, lsm_context, is created for use in these interfaces.
> It includes three members: the data pointer, the data length and
> the LSM ID of its creator. The interfaces that create contexts and
> security_release_secctx() now use a pointer to an lsm_context instead
> of a pointer pair.
> 
> The changes are mostly mechanical, and some scaffolding is used within
> the patch set to allow for smaller individual patches.

Hey Casey,

so this set is not bisectable.  Applying just patch 1 will no compile, right?
What is your plan for getting past that?  Squash some or all of them into one?
Or are you planning a wider reorg of the patches down the line, once the
basics of the end result are agreed upon?

-serge

On 10/14/2024 2:29 PM, Serge E. Hallyn wrote:
> On Mon, Oct 14, 2024 at 08:14:44AM -0700, Casey Schaufler wrote:
>> LSM: Replace secctx/len pairs with lsm_context
>>
>> Several of the Linux Security Module (LSM) interfaces use a pair of
>> pointers for transmitting security context data and data length. The
>> data passed is refered to as a security context.  While all existing
>> modules provide nul terminated strings, there is no requirement that
>> they to so. Hence, the length is necessary.
>>
>> Security contexts are provided by a number of interfaces. The interface
>> security_release_secctx() is used when the caller is finished with the
>> data. Each of the security modules that provide security contexts manages
>> them differently. This was safe in the past, because only one security
>> module that provides security contexts is allowed to be active. To allow
>> multiple active modules that use security contexts it is necessary to
>> identify which security module created a security context. Adding a third
>> pointer to the interfaces for the LSM identification is not appealing.
>>
>> A new structure, lsm_context, is created for use in these interfaces.
>> It includes three members: the data pointer, the data length and
>> the LSM ID of its creator. The interfaces that create contexts and
>> security_release_secctx() now use a pointer to an lsm_context instead
>> of a pointer pair.
>>
>> The changes are mostly mechanical, and some scaffolding is used within
>> the patch set to allow for smaller individual patches.

The next lines in cover letter are:

	This patch set depends on the patch set LSM: Move away from secids:
		https://github.com/cschaufler/lsm-stacking.git#lsmprop-6.12-rc1-v4

	https://github.com/cschaufler/lsm-stacking.git#context-6.12-rc1-v2


> Hey Casey,
>
> so this set is not bisectable.  Applying just patch 1 will no compile, right?
> What is your plan for getting past that?  Squash some or all of them into one?
> Or are you planning a wider reorg of the patches down the line, once the
> basics of the end result are agreed upon?

You shouldn't have any trouble with the lsmprop patches in place.

>
> -serge
>

On Mon, Oct 14, 2024 at 04:29:37PM -0500, Serge E. Hallyn wrote:
> On Mon, Oct 14, 2024 at 08:14:44AM -0700, Casey Schaufler wrote:
> > LSM: Replace secctx/len pairs with lsm_context
> > 
> > Several of the Linux Security Module (LSM) interfaces use a pair of
> > pointers for transmitting security context data and data length. The
> > data passed is refered to as a security context.  While all existing
> > modules provide nul terminated strings, there is no requirement that
> > they to so. Hence, the length is necessary.
> > 
> > Security contexts are provided by a number of interfaces. The interface
> > security_release_secctx() is used when the caller is finished with the
> > data. Each of the security modules that provide security contexts manages
> > them differently. This was safe in the past, because only one security
> > module that provides security contexts is allowed to be active. To allow
> > multiple active modules that use security contexts it is necessary to
> > identify which security module created a security context. Adding a third
> > pointer to the interfaces for the LSM identification is not appealing.
> > 
> > A new structure, lsm_context, is created for use in these interfaces.
> > It includes three members: the data pointer, the data length and
> > the LSM ID of its creator. The interfaces that create contexts and
> > security_release_secctx() now use a pointer to an lsm_context instead
> > of a pointer pair.
> > 
> > The changes are mostly mechanical, and some scaffolding is used within
> > the patch set to allow for smaller individual patches.
> 
> Hey Casey,
> 
> so this set is not bisectable.  Applying just patch 1 will no compile, right?
> What is your plan for getting past that?  Squash some or all of them into one?
> Or are you planning a wider reorg of the patches down the line, once the
> basics of the end result are agreed upon?

Sorry, I may have misread that.  secids make my eyes glaze over.

On 10/14/2024 2:35 PM, Serge E. Hallyn wrote:
> On Mon, Oct 14, 2024 at 04:29:37PM -0500, Serge E. Hallyn wrote:
>> On Mon, Oct 14, 2024 at 08:14:44AM -0700, Casey Schaufler wrote:
>>> LSM: Replace secctx/len pairs with lsm_context
>>>
>>> Several of the Linux Security Module (LSM) interfaces use a pair of
>>> pointers for transmitting security context data and data length. The
>>> data passed is refered to as a security context.  While all existing
>>> modules provide nul terminated strings, there is no requirement that
>>> they to so. Hence, the length is necessary.
>>>
>>> Security contexts are provided by a number of interfaces. The interface
>>> security_release_secctx() is used when the caller is finished with the
>>> data. Each of the security modules that provide security contexts manages
>>> them differently. This was safe in the past, because only one security
>>> module that provides security contexts is allowed to be active. To allow
>>> multiple active modules that use security contexts it is necessary to
>>> identify which security module created a security context. Adding a third
>>> pointer to the interfaces for the LSM identification is not appealing.
>>>
>>> A new structure, lsm_context, is created for use in these interfaces.
>>> It includes three members: the data pointer, the data length and
>>> the LSM ID of its creator. The interfaces that create contexts and
>>> security_release_secctx() now use a pointer to an lsm_context instead
>>> of a pointer pair.
>>>
>>> The changes are mostly mechanical, and some scaffolding is used within
>>> the patch set to allow for smaller individual patches.
>> Hey Casey,
>>
>> so this set is not bisectable.  Applying just patch 1 will no compile, right?
>> What is your plan for getting past that?  Squash some or all of them into one?
>> Or are you planning a wider reorg of the patches down the line, once the
>> basics of the end result are agreed upon?
> Sorry, I may have misread that.  secids make my eyes glaze over.

They make my skin crawl, and have since I first saw them circa 1986.
I would love to eradicate them, but they're like bad tattoos, showing
up in embarrassing places for which removal would be too painful.