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

[Kuniyuki Iwashima <kuniyu@google.com>]

On Sat, 31 Oct 2026 22:06:56 +0100, Günther Noack wrote:
> Hello!
> 
> On Wed, Oct 28, 2026 at 01:45:11PM +0100, Alejandro Colomar wrote:
> > > On Tue, Oct 27, 2026 at 11:59:15PM +0100, Alejandro Colomar wrote:
> > > > > Date: 2026-10-27 23:30:59+0100
> > > > > From: Günther Noack <gnoack3000@gmail.com>
> > > > > 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.
> > > 
> > > Correct.  Callers have to deal with the possibility of truncation,
> > > which strips away the null byte.
> > 
> > Is this true for every LSM?  Do any LSMs guarantee a string even under
> > truncation?
> 
> Yes, it is true for every LSM (as discussed below) and none of the
> LSMs can guarantee a string under truncation.
> 
> 
> > > > > * 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?
> > > 
> > > The truncation case always strips off the null byte at the end of the
> > > buffer.  This is handled **independent of the LSM** in the common
> > > net/core/scm.c layer one level above - it *always* kicks in when
> > > truncation happens.
> > 
> > Hmmmm.  I believe that layer should guarantee a null byte when it
> > truncates the data.  It should be like strscpy(), which guarantees
> > a correct string even on truncation.
> > 
> > This seems to be another bug.
> 
> (Bringing it up below together with the AA/Smack payloads which are
> also not null-terminated.)
> 
> > > To sum it all up in a table: The only case where the null byte is
> > > included in the buffer is in SELinux, when the generic SCM layer does
> > > not need to do truncation:
> > > 
> > >                 normal case                truncation case
> > >   --------------------------------------------------------------
> > >   SELinux       has trailing null byte     no trailing null byte
> > >   AppArmor      no trailing null byte      no trailing null byte
> > >   Smack         no trailing null byte      no trailing null byte
> > > 
> > >   (other LSMs don't have the feature at all)
> > 
> > Thanks for the table!  This seems to me to be 3 bugs: one in AppArmor,
> > the same one in Smack, and one in the upper layer which corrupts the
> > string when truncating.  I wonder if we can do better in the truncation
> > case, or if it's too late for that.
> > 
> > Would you mind CCing the maintainers of the upper layer in
> > net/core/scm.c?
> 
> Adding Eric Dumazet, Paolo Abeni and Willem de Brujin.  (Kuniyuki
> Iwashima is already in CC.)
> 
> Hello maintainers of NETWORKING [SOCKETS]! :)
> 
> We are unsure in this documentation review what
> the intended format of payloads is which are returned by SCM_SECURITY:
> They have previously been documented as zero-terminated strings (for
> the SELinux case), but in the case of truncation and in the case of
> the two other supported LSMs, there implementation does not return a
> trailing zero byte.
> 
> Could you please confirm what the intended interface for SCM_SECURITY
> is?  The two variants we have been discussing are:
> 
> Variant A:
>   The returned payload is a byte buffer whose contents are defined by
>   the respective LSM (and which are not necessarily zero-terminated).

+1, basically each scm data is binary.

I think it's just man page was not updated for other LSMs.


> 
>   Concrete wording proposal for this variant is in:
>   https://lore.kernel.org/all/20261027.4df00f962b98@gnoack.org/
> 
> Variant B:
>   The returned payload is a string which should be zero-terminated.
> 
>   (But in this case, the Smack and Apparmor implementation, as well as
>   the generic truncation are arguably not doing that right.)
> 
> 
> The documentation commit at the top of this dicussion is documenting
> the current implementation, but it becomes lengthy and it feels like
> it could be crisper if we could document the original intent:
> https://lore.kernel.org/all/20261021212256.27961-5-gnoack3000@gmail.com/
> 
> I would appreciate your feedback to un-wedge the review. :)
> 
> Thanks!
> –Günther