mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2954
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
@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
@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).
@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.
@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.
I did not notice anything not working, but this causes a good amount of log spam.
@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,
readbyshould be allowed according to82c244f292/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:
@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.