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 [off-list ref] wrote:

quoted

On Sat, Jan 04, 2025 at 08:23:52PM -0500, Paul Moore wrote:

quoted

On Nov 22, 2024 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= [off-list ref] wrote:

quoted

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

quoted

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.