apparmor="DENIED" when "zypper install kernel-default"

When “zypper install kernel-default-5.14.21-150500.55.59.1.x86_64.rpm

/var/log/audit/audit.log shows:
type=AVC msg=audit(1714521833.284:790): apparmor=“DENIED” operation=“file_inherit” profile=“zgrep” name=“/dev/pts/1” pid=10355 comm=“zgrep” requested_mask=“wr” denied_mask=“wr” fsuid=0 ouid=0

What cause this issue for kernel-default installation? How to fix this issue?

I cannot reproduce it. You will need to provide much more information than a single line. What is your openSUSE distribution? How you log in (GUI, text mode console, SSH)? How you become root? Where the file that you install comes from? Why you install local file instead of using packages from the repository?

Finally - does it cause any real problems?

You need to find the root cause first. As long as you are the only one seeing it - either you troubleshoot and identify the root cause yourself or you provide exact steps allowing someone else to reproduce it.

At the top it says: leap-15.5.

OK, what happens here - AppArmor revalidates on exec whether program is allowed to access opened file descriptors passed by parent. And zgrep profile does not have any explicit provision for the usual standard terminal devices like /dev/pts/N.

What was most puzzling to me - it looked like zgrep should have failed when simply called from shell session. It turned out to be more complicated. AppArmor allows access to a file if it was opened by unconfined program and it remembers across exec the profile (or lack thereof) used to originally open this file. So in usual case of using zgrep interactively the program that originally opened /dev/pts/N (in case of GUI it is terminal emulator) is not confined and this file descriptor gets inherited by all descendants so AppArmor does not restrict access to it.

What follows - to get this error on kernel installation this zypper must be invoked from within a (descendant) of a confined program and /dev/pts/1 must have been explicitly (re-)opened by this confined program. Which is certainly not a usual case and needs much more information to troubleshoot than a single command line out of context.

1 Like

Thanks for your input.
After stop apparmor, the issue is gone.