[PATCH v3 17/23] landlock: Log TCP bind and connect denials

[Mickaël Salaün]

On Mon, Jan 06, 2025 at 05:29:51PM -0500, Paul Moore wrote:
> On Mon, Jan 6, 2025 at 9:51 AM Mickaël Salaün <mic at digikod.net> wrote:
> > On Sat, Jan 04, 2025 at 08:23:52PM -0500, Paul Moore wrote:
> > > On Nov 22, 2024 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic at digikod.net> wrote:
> > > >
> > > > Add audit support to socket_bind and socket_connect hooks.
> > > >
> > > > Audit event sample:
> > > >
> > > >   type=LL_DENY [...]: domain=195ba459b blockers=net_connect_tcp daddr=127.0.0.1 dest=80
> > >
> > > The destination address and port is already captured in the SOCKADDR
> > > record for bind() and connect(), please don't duplicate it here.
> >
> > This does not show up when a connect or bind is denied.  I guess this is
> > because move_addr_to_kernel() is called at syscall entry when there is
> > no context, whereas a Landlock denial is created after that.  For this
> > to work, users would have to log a list of syscalls, which would not be
> > usable (nor reliably maintainable) for most users.
> 
> Quick question, can you share the audit filter configuration you are
> using on your dev/test systems (just dump /etc/audit/audit.rules,
> unless you are doing it by hand)?

This file only contains a comment.  auditctl -l says that there is no
rules.

> 
> One can make an argument that if syscall auditing is being explicitly
> denied, then the user has decided that the syscall related information
> is not important to them.  I'm somewhat conflicted on that argument,
> but I believe the argument is at least valid.

I did not disable syscall auditing, I get the type=SYSCALL record for
every Landlock deny event, but there is no SOCKADDR one.  For instance:

type=UNKNOWN[1423] msg=audit(1736258533.147:45): domain=190464446 blockers=net.connect_tcp daddr=127.0.0.1 dest=80
type=UNKNOWN[1424] msg=audit(1736258533.147:45): domain=190464446 creation=1736258533.135 pid=359 uid=0 exe="/root/sandboxer" comm="sandboxer"UID="root"
type=SYSCALL msg=audit(1736258533.147:45): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=5647c6a26b98 a2=10 a3=7ffd2f5f6acc items=0 ppid=356 pid=359 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="curl" exe="/usr/bin/curl" key=(null)ARCH=x86_64 SYSCALL=connect AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=PROCTITLE msg=audit(1736258533.147:45): proctitle=6375726C00687474703A2F2F3132372E31
type=UNKNOWN[1425] msg=audit(1736258533.199:46): domain=190464446

> 
> > I guess this might be different with io_uring too.
> 
> There are other issues with SOCKADDR and io_uring related to how
> io_uring wants to separate the work into different execution contexts.
> In general I wouldn't spend too much time worrying about auditing and
> io_uring right now, there are some general issues that need to be
> resolved in io_uring/audit that are much larger than just Landlock's
> audit usage.

OK.  Anyway, my understanding is that SOCKADDR is just a way to enrich
the syscall record to ease debugging or tracing.  In the case of an
access control, we want to identify an object/subject, and each LSM may
have a different way to identify such an object, and this description
should be enough to identify the relevant part of the object.