[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy

1 Like
1 Like
1 Like

Thank you! Merged.

Could you please fix the whonix-firewall ALLOWED apparmor messages?

1 Like

Is the sdwdate profile mature enough yet to be enforced?

1 Like

It already is.

1 Like

Merged. :slight_smile:

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/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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]