I’ll need to update security-misc to get the profile but updating it would require access to the home directories which should be denied. And besides, the profile for permission-lockdown cannot be enforced during installation due to the confinement (messing with apparmor profiles while confined would be a disaster).
Also, apt runs under its own profile, not the global one.
Allow apt to run run permission lockdown under permission lockdown profile?
Move permission lockdown to the very bottom of postinst. At the point the autogenerated debhelper apparmor code will be ready. Should work?
Can remove if have to.
It was nice to secure existing users right after installation but apparmor everything is more important. Would require relogin or reboot.
No the permission lockdown profile is not enforced until after a reboot which by that time, permission lockdown will have already run during installation. If you’re confined via apparmor, you cannot load any new profiles. Otherwise, that’d be an easy bypass of apparmor (you can just unload your own profile).
Usually apparmor profiles (changes) are activated during postinst and don’t require reboot. For example /var/lib/dpkg/info/apparmor-profile-torbrowser.postinst includes:
if aa-enabled --quiet 2>/dev/null; then
apparmor_parser -r -T -W "$APP_PROFILE" || true
fi
I am certain that apparmor profile activation and apparmor profile changes are activated after package upgrades. Did this many, many times already during testing apparmor fixes. Trying apparmor fixes (modifying profile files) doesn’t require me to reboot after each change. (Often I get it wrong and don’t (fully) fix the issue. Have to edit the file more. And run aa-enforce again and again until I got it right.)
Any postinst script in the source code has this:
true "INFO: debhelper beginning here."
#DEBHELPER#
true "INFO: Done with debhelper."
It is possible to place code after the auto generated debhelper code. Root can always run
sudo aa-enforce /etc/apparmor.d/profile-name
It is possible to update the rules which existing profiles have already load or to load entirely new profiles. No reboot required. The only thing that I wouldn’t know how to do is completely unloading profiles - that may require reboot indeed. As a workaround/attack it may be possible to make a profile all permissive and then run aa-enforce.
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?
I can make a compromise. /opt can be read-write for the user’s own programs while /usr/bin and other will be read-only.
Question: What about software installation to home folder?
(Related to noexec - (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?)
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.
I’m not sure why it’s needed. Nor why it’s only needed when using a full system policy.
Here are the newer profiles:
init-systemd - Debian paste error
apt-get - Debian paste error
the dangerous-files abstraction - Debian paste error
It would be great if anyone could test. Especially on platforms I can’t test on like Qubes.
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.
Qubes might be a great fit for this anyhow.In Qubes TemplateBasedVMs the root image is non-persistent.
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.
madaidan via Whonix Forum:
Something generic like “Full System AppArmor Policy”.
apparmor-profile-everything?
full might be more correct but everything more catchy.
apparmor-profile-init?
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.
Empty package created.
Could you add please the files there?
Perfect. I’ll create a pull request in a minute.
Could you please add the license header?
Oops. I forgot again.