[GH-ISSUE #5316] apparmor: multiple DENIED entries in audit log after merging #5274 #2954

Open
opened 2026-05-05 09:37:06 -06:00 by gitea-mirror · 5 comments
Owner

Originally created by @ghost on GitHub (Aug 15, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5316

Firejail from git master currently shows multiple entrees in /var/log/audit/audit.log on my arch linux box. I've bisected and this regression stems from commit, which added #5274:

type=AVC msg=audit(1660549572.602:83): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=6723 comm="ps" requested_mask="read" denied_mask="read" peer="firejail-default//&unconfined"
type=AVC msg=audit(1660549572.602:83): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=6723 comm="ps" requested_mask="readby" denied_mask="readby" peer="firejail-default//&unconfined"

@ChrysoliteAzalea If there's anything I can post to help debugging this issue, feel free to ping me.

OS: Arch Linux
apparmor: 3.0.7-1
firejail-git: 0.9.71.r8626.5ab4aeb35-1

Originally created by @ghost on GitHub (Aug 15, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5316 Firejail from git master currently shows multiple entrees in /var/log/audit/audit.log on my arch linux box. I've bisected and this regression stems from [commit](https://github.com/netblue30/firejail/commit/b987cf001af3e3a88d73d49117ddf7ccad0cbc5e), which added #5274: ``` type=AVC msg=audit(1660549572.602:83): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=6723 comm="ps" requested_mask="read" denied_mask="read" peer="firejail-default//&unconfined" type=AVC msg=audit(1660549572.602:83): apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=6723 comm="ps" requested_mask="readby" denied_mask="readby" peer="firejail-default//&unconfined" ``` @ChrysoliteAzalea If there's anything I can post to help debugging this issue, feel free to ping me. OS: Arch Linux apparmor: 3.0.7-1 firejail-git: 0.9.71.r8626.5ab4aeb35-1
gitea-mirror added the
bug
label 2026-05-05 09:37:06 -06:00
Author
Owner

@ChrysoliteAzalea commented on GitHub (Aug 15, 2022):

Sorry, I didn't test the use case with ptrace and signals. The issue is that, while security labels firejail-default and firejail-default//&unconfined are equal in terms of AppArmor permissions, the original profile allowed only ptrace-reading and sending signals only to peers with the former label. This issue happened because the PR replaced the aa_change_onexec to aa_stack_onexec (which guarantees that the process won't have any additional permissions after AppArmor domain transition that it didn't have before, and works with "No New Privileges" enabled).

<!-- gh-comment-id:1214864051 --> @ChrysoliteAzalea commented on GitHub (Aug 15, 2022): Sorry, I didn't test the use case with ptrace and signals. The issue is that, while security labels **firejail-default** and **firejail-default//&unconfined** are equal in terms of AppArmor permissions, the original profile allowed only ptrace-reading and sending signals only to peers with the former label. This issue happened because the PR replaced the **aa_change_onexec** to **aa_stack_onexec** (which guarantees that the process won't have any additional permissions after AppArmor domain transition that it didn't have before, and works with "No New Privileges" enabled).
Author
Owner

@ghost commented on GitHub (Aug 15, 2022):

@ChrysoliteAzalea Thanks for the fix. I've tested it locally and can confirm it fixes the issue. I'll wait a bit with merging #5317 to give other collaborators time to review, although I don't expect any problems.

<!-- gh-comment-id:1214902440 --> @ghost commented on GitHub (Aug 15, 2022): @ChrysoliteAzalea Thanks for the fix. I've tested it locally and can confirm it fixes the issue. I'll wait a bit with merging #5317 to give other collaborators time to review, although I don't expect any problems.
Author
Owner

@NetSysFire commented on GitHub (Feb 5, 2023):

Getting the same on 0.9.72 on Arch Linux after updating, but strangely only with signal-desktop and I figured this issue might be related.

audit[3018085]: AVC apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=3018085 comm="signal-desktop" requested_mask="readby" denied_mask="readby" peer="firejail-default//&unconfined"
audit[3018085]: AVC apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=3018085 comm="ThreadPoolSingl" requested_mask="read" denied_mask="read" peer="firejail-default//&unconfined"

I did not notice anything not working, but this causes a good amount of log spam.

<!-- gh-comment-id:1417166512 --> @NetSysFire commented on GitHub (Feb 5, 2023): Getting the same on 0.9.72 on Arch Linux after updating, but strangely only with signal-desktop and I figured this issue might be related. ``` audit[3018085]: AVC apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=3018085 comm="signal-desktop" requested_mask="readby" denied_mask="readby" peer="firejail-default//&unconfined" audit[3018085]: AVC apparmor="DENIED" operation="ptrace" profile="firejail-default" pid=3018085 comm="ThreadPoolSingl" requested_mask="read" denied_mask="read" peer="firejail-default//&unconfined" ``` I did not notice anything not working, but this causes a good amount of log spam.
Author
Owner

@ghost commented on GitHub (Feb 6, 2023):

@NetSysFire At the moment I can't explain why you're getting this in 0.9.72. It's supposed to be fixed. If I understand it correctly, readby should be allowed according to

82c244f292/etc/apparmor/firejail-default (L34-L36)

Let's reopen this and ask @ChrysoliteAzalea's opinion. FWIW, for me this was fixed by #5317 and I haven't noticed anything like it since. For the time being you could add a rule to your /etc/audit/rules.d/20-dont-audit.rules to temporarily keep signal-desktop from spamming the log. That can grow quickly out of control, besides it being irritating...

Something like the below should do it:

-a always,exclude -F exe=/usr/bin/signal-desktop
<!-- gh-comment-id:1419180143 --> @ghost commented on GitHub (Feb 6, 2023): @NetSysFire At the moment I can't explain why you're getting this in 0.9.72. It's supposed to be fixed. If I understand it correctly, `readby` should be allowed according to https://github.com/netblue30/firejail/blob/82c244f292dcbcf8a9ccffa979a6b464751ab369/etc/apparmor/firejail-default#L34-L36 Let's reopen this and ask @ChrysoliteAzalea's opinion. FWIW, for me this was fixed by #5317 and I haven't noticed anything like it since. For the time being you could add a rule to your /etc/audit/rules.d/20-dont-audit.rules to temporarily keep signal-desktop from spamming the log. That can grow quickly out of control, besides it being irritating... Something like the below should do it: ``` -a always,exclude -F exe=/usr/bin/signal-desktop ```
Author
Owner

@NetSysFire commented on GitHub (Feb 6, 2023):

I sandbox plenty of other stuff and so far only signal-desktop is triggering this. I can not say whether this is a firejail or signal-desktop issue but if you tell me how, I will debug.

<!-- gh-comment-id:1419332311 --> @NetSysFire commented on GitHub (Feb 6, 2023): I sandbox plenty of other stuff and so far only signal-desktop is triggering this. I can not say whether this is a firejail or signal-desktop issue but if you tell me how, I will debug.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2954
No description provided.