I’m not sure why this is happening but the denials you’re facing are certainly already allowed, many of them in the base abstraction.
1 Like
Merged.
Cannot reproduce anymore. Perhaps I missed journalctl -b or --boot.
1 Like
apparmor-profile-everything profile comment:
TODO: Create auditd(/journald?) profile and remove audit_*.
Therefore no longer required or lower priority since Whonix will be no longer installing auditd by default?
1 Like
Are you sure uninstalling auditd is a good idea? It’s pretty useful for debugging and uninstalling it would break e.g. apparmor-info unless I’m missing something?
1 Like
The audit lines in systemd journal are independent. auditd wasn’t installed on Whonix-Workstation. Only on Whonix-Gateway. Was only a Depends: in anon-gw-anonymizer-config. No other mentions of it in Whonix source code anywhere. Was only installed to debug ⚓ T537 monitor what changes /var/lib/tor/lock access rights. Since that issue doesn’t happen anymore. rip out that debugging code since causing issues (A start job is running for security auditing service - #3 by Patrick). I am confident we won’t notice a difference.
1 Like
Suggestion: "Tor Control Panel" on Gateway without root reminds me of upgrade-nonroot. Would it be better for security if we got rid of that for sake of apparmor-profile-everything?
Also interesting in context of:
1 Like
How would it be better? It doesn’t seem like a risk to me.
1 Like
1 Like
1 Like
Thank you! Merged.
Could you please fix the whonix-firewall ALLOWED apparmor messages?
1 Like
https://github.com/Whonix/whonix-firewall/pull/9
Is the sdwdate profile mature enough yet to be enforced?
1 Like
It already is.
1 Like
Merged. 
1 Like
This caused confusion:
Why a drop-in cannot be used? Is there an upstream bug report for this?
1 Like
I’m not sure. It unexplainably broke when testing.
Which upstream?
The root issue is with the no_new_privs bit. It prevents a process from gaining further privileges. AppArmor respects this and prevents a process from transitioning to another AppArmor profile that grants increased permissions: linux/security/apparmor/domain.c at 3cee6079f62f4d3a37d9dda2e0851677e08028ff · torvalds/linux · GitHub
Since a lot of sandboxing options force this enabled (e.g. seccomp), we have to disable a lot of things for this to work. Theoretically, one could transition AppArmor profile and then set no_new_privs, but I don’t know how to do this. Will update Systemd sandboxing fails when using a full system apparmor policy · Issue #14277 · systemd/systemd · GitHub
1 Like
systemd about not honoring the drop-in disabling no new privs.
1 Like
I’m not sure if it’s actually an issue within systemd. I’ll investigate more.
1 Like