On 7/26/24 05:41, x...@posteo.de wrote:
I'm testing linux 6.10.1.
apparmor-utils version is 3.0.8
auditd and apparmor are enabled.
create usr.bin.mpv profile and activate with "aa-complain usr.bin.mpv".
aa-status show its fine.
to clarify it shows that it is loaded, in complain mode, and attached to
/usr/bin/mpv
but when i want to check logs with aa-logprof.
logs are readed by i never asked to allow or denied anything.
/var/log/audit/audit.log
type=AVC msg=audit(1721996490.702:8607): apparmor="ALLOWED" operation="recvmsg" class="net" profile="/usr/bin/mpv"
pid=822 comm="mpv/vo" family="unix" sock_type="stream" protocol=0 requested_mask="r>
is this the full message? It looks truncated. It might not be the actual output
does depend on kernel version.
type=SYSCALL msg=audit(1721996490.702:8607): arch=c000003e syscall=47 success=yes
exit=60 a0=3 a1=74f341ffef10 a2=40000040 a3=0 items=0 ppid=821 pid=822 auid=1000
uid=1000 gid=1000 euid=1000 suid=10>
type=PROCTITLE msg=audit(1721996490.702:8607): proctitle="mpv"
Do i need newer version of apparmor-utils?
maybe, there is a bug here that we need to track down
https://gitlab.com/apparmor/apparmor/-/wikis/Kernel_Feature_Matrix
says at 5.0 kernel "no userspace requirements."
so the answer is complicated. We should have multiple tables.
AppArmor strives to maintain compatibility both in he userspace and in the
kernel. There are limits however
Features require both a kernel that supports them and a userspace. It doesn't
necessarily have to be new, but they need to be supported by both.
AppArmor uses an abi system to facilitate this at the policy level. The kernel
supports multiple abis and the userspace supports multiple abis, they both do
mappings to make sure things work.
The particular issue you are encountering looks to be a log parsing issue. The
tools need to be able to parse the log, if they can't because it a feature they
don't know about or because the log has entries it doesn't understand.
3.0.8 understands socket mediation, and fine grained mediation support for unix
sockets. This leads me to believe this particular log message has something
that 3.0.8 can't parse.
checking in 3.0.8, 4.0.2, and current dev head, the parse for the log line
fails with
Event type: AA_RECORD_INVALID
Audit ID: 1721996490.702:8607
Operation: recvmsg
Profile: /usr/bin/mpv
Command: mpv/vo
PID: 822
Network family: unix
Socket type: stream
Protocol: ip
Class: net
Epoch: 1721996490
Audit subid: 8607
it fails to parse
requested_mask="r>
which is indeed malformed. There should be a trailing "
If that was fixed 3.0.8 would be able to handle this event
which kernel and auditd version are you using?
greetings xoip
