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 <[email protected]> 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?= <[email protected]> > > > 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.
