[apparmor] Specific kernel version required specific apparmor-utils version?
John Johansen
john.johansen at canonical.com
Sat Jul 27 09:41:16 UTC 2024
On 7/26/24 05:41, xoip at 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
>
More information about the AppArmor
mailing list