Apparmor profiles are usually activated after package upgrades but you cannot load profiles while being confined by apparmor. As everything is being confined in this scenario, it is not possible to load apparmor profiles at runtime. It requires a reboot.
Further, the policy explicitly denies access to the mac_admin and mac_override capabilities so even if apparmor itself didn’t prevent loading new profiles, you still won’t have enough privileges.
Not when confined with a full system policy. When trying to do this while confined under the policy, I get this error
ERROR: /sbin/apparmor_parser: Unable to replace "profile". Permission denied; attempted to load a profile while confined?
Currently only the Tor Browser is executable but I can make anything in the home directory executable if you want.
Also, if the user wants to access something that’s restricted (execute something else in /home for example), then they can just add what they want to a “local” file.
Merged. To not block your progress. But I wonder why it’s needed? A simple echo requires that? Writing to tty0 may be ok but reading required too? This may be related to other whonixcheck hardening wrt to output (of kernel messages) for non-root/non-sudo users as discused in Kernel Hardening - security-misc - #213 by madaidan.
Could you please create a new package for this? That makes it easier to test. Once I have it installed in Qubes I might find some issues and just fix in git if I figure out how.
Software installation to the root image in TemplateBasedVMs can be useful but isn’t a too important use case. Apparmor everything would be an additional layer to prevent VM breakout.
However when booting a TemplateVM (“different boot mode”, not really) software installation should be possible. The existing Qubes design makes it easy to compartmentalize installation/update of software vs actually running the software. Happens in different VMs if the user adheres to standard Qubes principles.
I don’t know how to create Debian packages so I won’t be able to yet.
Setting it up isn’t hard. Just follow the instructions in the page linked in the original post and add the init-systemd, apt-get and dangerous-files abstraction to /etc/apparmor.d.
Verify it works by running ps auxZ. You’ll see all processes are confined except kernel processes (the ones in square brackets).
I’m not sure which one to use. Both are fine.
That might make people think it’s only the init process rather than the entire system.
Write access is given anyway with the /var/{,lib,log}/** rw, rule.
Feel free to add them to the dangerous-files abstraction.
Btw, some rules in that abstraction break some apt upgrades e.g. deny /**/initramfs-tools/** w, breaks adding new files to that directory during upgrades so it’s commented out in the apt profile.
etc/initramfs-tools/hooks/apparmor can I rename to apparmor-profile-everything? Reason: the name “apparmor” might be used by some other package (apparmor?) in the future and thereby break things. apparmor-profile-everything is more unique and very very unlikely being used by anyone else in future.