All of these are already allowed.
1 Like
Aren’t these just ALLOWED because the profile is still in complain mode and not yet in enforce mode? If the profile was in enforce mode, I guess these would become DENIED?
Why would the log mention ALLOWED? If apparmor profiles would log everything every time something was allowed, that would overwhelm logs. So even if allowed, that log message should be made gone somehow?
1 Like
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