System log entries - apparmor and /usr/bin/man

[aerodinamica]

I am running Proxmox VE 9.0.5 on a newly built computer. Everytime I run 'man' to read the manual for some command, I get six entries (with six different pid's) like these in the system log:

kernel: audit: type=1400 audit(1755596132.009:125): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=4172 comm="man" capability=21 capname="sys_admin"

This does not happen with an older computer running VE 8.4.9. Any ideas? Why would man need sys_admin capabilities?

 

[dakralex]

Hi!

Have you set up any man pager with the MANPAGER environment variable (echo $MANPAGER)? Either way, the audit message doesn't say much, but I can only guess that it could be about the seccomp(...) syscalls that man does make at startup to confine any children processes (like pagers, groff formatters, ...), but fails to set them because those need SYS_ADMIN capabilities. Do the other log messages tell more about the actual error? What is the output of a strace -Z man man > /dev/null?

NOTE: strace can potentially output information that you wouldn't want the whole forum to see, but with -Z it only outputs failed syscalls. Either way, check what information is posted before submitting.

 

[dakralex]

FYI, one rather insecure way to mitigate this is to disable the apparmor profile for now with aa-disable /usr/bin/man or another slightly better solution is to use aa-logprof (in apparmor-utils package) which allows modifying the apparmor profile with interactive suggestions, but the latter should also be used with caution if one's not familiar with apparmor rules.

 

[aerodinamica]

Hi!

Thanks for your suggestions. MANPAGER is not set. Overall, this is a rather standard, "vanilla" Proxmox 9 installation. I haven't made any major modifications since I want this node to be easily replaceable.

There are no other log entries, and the man command itself works just fine.

The strace returns loads of ENOENTs, some EINVALs and also this group of seccomp calls twice:

seccomp(SECCOMP_SET_MODE_STRICT, 0x1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC_ESRCH, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER|SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV, NULL) = -1 EFAULT (Bad address)

I guess they might be related to apparmor since there are six of the EFAULTs, but that is a long shot.

Edit: Also found this in the manpage for seccomp. SYS_ADMIN seems familiar...

In order to use the SECCOMP_SET_MODE_FILTER operation,
either the calling thread must have the CAP_SYS_ADMIN
capability in its user namespace, or the thread must
already have the no_new_privs bit set.