On Thu, Oct 10, 2024 at 2:24 AM Richard Weinberger
<richard@xxxxxxxxxxxxx> wrote:
> Am Donnerstag, 10. Oktober 2024, 00:02:44 CEST schrieb Paul Moore:
> > [CC'ing the audit and LSM lists for obvious reasons]
> >
> > If we're logging the subjective credentials of the skb's associated
> > socket, we really should also log the socket's LSM secctx similar to
> > what we do with audit_log_task() and audit_log_task_context().
> > Unfortunately, I don't believe we currently have a LSM interface that
> > return the secctx from a sock/socket, although we do have
> > security_inode_getsecctx() which *should* yield the same result using
> > SOCK_INODE(sk->sk_socket).
>
> Hm, I thought about that but saw 2173c519d5e91 ("audit: normalize NETFILTER_PKT").
> It removed usage of audit_log_secctx() and many other, IMHO, useful fields.
The main motivation for that patch was getting rid of the inconsistent
usage of fields in the NETFILTER_PKT record (as mentioned in the
commit description). There's a lot of history around this, and why we
are stuck with this pretty awful IMO, but one of the audit rules is
that if a field appears in one instance of an audit record, it must
appear in all instances of an audit record (which is why it is
important and good that you used the "?" values for UID/GID when they
are not able to be logged).
However, as part of that commit we also dropped a number of fields
because it wasn't clear that anyone cared about them and if we were
going to (re)normalize the NETFILTER_PKT record we figured it would be
best to start small and re-add fields as needed to satisfy user
requirements. I'm working under the assumption that if you've taken
the time to draft a patch and test it, you have a legitimate need :)
> What about skb->secctx?
Heh, if there is anything with more history than the swinging fields
in an audit record, it would be that :) We don't currently have an
explicit LSM blob/secid/secctx in a skb and I wouldn't hold your
breath waiting for one; we do have a secmark, but that is something
entirely different. We've invented some mechanisms to somewhat mimic
a LSM security label for packets, but that's complicated and not
something we would want to deal with in the NETFILTER_PKT record at
this point in time.
--
paul-moore.com
