linux-kernel - Re: [PATCH] netfilter: Record uid and gid in xt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241009223409.GE3714@breakpoint.cc>
Date: Thu, 10 Oct 2024 00:34:09 +0200
From: Florian Westphal <fw@...len.de>
To: Paul Moore <paul@...l-moore.com>
Cc: Florian Westphal <fw@...len.de>, Richard Weinberger <richard@....at>,
	netfilter-devel@...r.kernel.org, coreteam@...filter.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	pabeni@...hat.com, kuba@...nel.org, edumazet@...gle.com,
	davem@...emloft.net, kadlec@...filter.org, pablo@...filter.org,
	rgb@...hat.com, upstream+net@...ma-star.at
Subject: Re: [PATCH] netfilter: Record uid and gid in xt_AUDIT

Paul Moore <paul@...l-moore.com> wrote:
> On Wed, Oct 9, 2024 at 5:34 PM Florian Westphal <fw@...len.de> wrote:
> > Richard Weinberger <richard@....at> wrote:
> > > When recording audit events for new outgoing connections,
> > > it is helpful to log the user info of the associated socket,
> > > if available.
> > > Therefore, check if the skb has a socket, and if it does,
> > > log the owning fsuid/fsgid.
> >
> > AFAIK audit isn't namespace aware at all (neither netns nor userns), so I
> > wonder how to handle this.
> >
> > We can't reject adding a -j AUDIT rule for non-init-net (we could, but I'm sure
> > it'll break some setups...).
> >
> > But I wonder if we should at least skip the uid if the user namespace is
> > 'something else'.
> 
> This isn't unique to netfilter and the approach we take in the rest of
> audit is to always display UIDs/GIDs in the context of the
> init_user_ns; grep for from_kuid() in kernel/audit*.c.

Hmm, audit_netlink_ok() bails with -ECONNREFUSED for current_user_ns()
!= &init_user_ns, so audit_log_common_recv_msg() won't be called from
tasks that reside in a different userns.

If you say its fine and audit can figure out that the retuned
uid is not related to the initial user namespace, then ok.

I was worried audit records could blame wrong/bogus user id.