Re: [PATCH 4/7] man/man7/unix.7: SCM_SECURITY: Generalize to other LSMs, not just SELinux

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

Hi Günther,

> Date: 2026-10-27 23:30:59+0100
> From: Günther Noack <gnoack3000@gmail.com>
>
> Hello Alejandro!
> 
> On Tue, Oct 27, 2026 at 10:46:14PM +0100, Alejandro Colomar wrote:
> > > Date: 2026-10-27 09:54:51+0100
> > > From: Günther Noack <gnoack3000@gmail.com>
> > >
> > > On Mon, Oct 26, 2026 at 11:41:13PM +0100, Günther Noack wrote:
> > > > I'm still leaning towards documenting it as a buffer with
> > > > implementation-defined contents which are provided by a LSM.  How
> > > > these buffer contents are interpreted is depending on the LSM in use
> > > > anyway.
> > > 
> > > To make a more concrete and constructive wording proposal:
> > > 
> > > 
> > > SCM_SECURITY
> > > 
> > >   Receive the security context (the security label) of the peer
> > >   socket, as provided by the active Linux Security Module (LSM).  The
> > >   received ancillary data is a byte buffer.
> > > 
> > >   The exact format of the security context buffer is defined by the
> > >   active major LSM.  For example, SELinux returns a SELinux label as a
> > >   string (including a terminating null byte).
> > 
> > Let's pause the discussion of the specific text for now.
> > 
> > I have questions about the exact format used by each LSM.  For example,
> > you say that SELinux guarantees a string.  Does it count the '\0' as
> > part of the data size?  Or is it guaranteed to exist but not counted?
> > 
> > Same question for the other LSMs.
> 
> Yes, SELinux counts the '\0' as part of the buffer size for the
> SCM_SECURITY security context.

Ok.

> 
> Examples:
> * If the label is "foo", it'll return {'f', 'o', 'o', '\0'} with payload size 4.
> * If the reader calls recvmsg() but preallocates too little space in
>   the msg_control buffer, this can get truncated though, and then it
>   won't end with '\0':
>   {'e', 'x', 'a', 'm', 'p'} with payload size 5 (truncated)

Ouch!  So, no string guarantees here either, actually.

> Other LSMs:
> 
> * Smack excludes the null byte for SCM_SECURITY (smack_to_secctx())
>   (but irritatingly it does count the null byte when a label is
>   returned through SO_PEERSEC (smack_socket_getpeersec_stream()).
>   Both functions are in security/smack/smack_lsm.c.

And as we've seen, no string guarantees, IIUC.

> 
> * AppArmor excludes the null byte for SCM_SECURITY as well.
>   Implementation is in apparmor_label_to_secctx(), where it populates
>   the struct lsm_context *cp using:
> 
>     len = aa_label_asxprint(&cp->context...)
> 
>   and then sets
> 
>     cp->len = len;
> 
>   The function aa_label_asxprint() returns the length without trailing
>   null byte, as can be seen in its implementation.

How does it behave if there's not enough space?  Does AppArmor guarantee
a string?


Cheers,
Alex

> SELinux, Smack and AppArmor are the only LSMs that implement the
> secid_to_secctx() hook, which is the hook that defines the payload
> contents.  (For reference, the higher level common SCM logic like the
> truncation is in net/core/scm.c.)
> 
> All reasoning is based on reading the code (with some AI assistance to
> point me to the right places). I have not tried it out in a running
> system, but it seems to check out.
> 
> –Günther

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]