Does not work with dom0 kernel. This is expected since by using dom0 kernel it also used dom0 initrd. Therefore apparmor-profile-everything cannot function. The good news about this is, that it does not seem to break anything either.
sudo aa-status
apparmor module is loaded.
16 profiles are loaded.
16 profiles are in enforce mode.
/**/*-browser/Browser/firefox
/usr/bin/apt-get
/usr/bin/man
/usr/bin/whonixcheck
/usr/lib/sdwdate/url_to_unixtime
/usr/lib/security-misc/pam_tally2-info
/usr/lib/security-misc/permission-lockdown
/usr/sbin/haveged
bootclockrandomization
firejail-default
init-systemd
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
system_tor
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/haveged (519)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Linux version 4.19.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
sudo aa-status
apparmor module is loaded.
16 profiles are loaded.
16 profiles are in enforce mode.
/**/*-browser/Browser/firefox
/usr/bin/apt-get
/usr/bin/man
/usr/bin/whonixcheck
/usr/lib/sdwdate/url_to_unixtime
/usr/lib/security-misc/pam_tally2-info
/usr/lib/security-misc/permission-lockdown
/usr/sbin/haveged
bootclockrandomization
firejail-default
init-systemd
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
system_tor
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/haveged (431)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
[user@dom0 ~]$ sudo xl console whonix-ws-15
.[30m.[47mWelcome to GRUB!
.[37m.[40m.[37m.[40m.[37m.[40m.[3;35H [ grub-xen.cfg 424B 100% 1.53KiB/s ].[3;1Herror: no such device: /boot/xen/pvboot-x86_64.elf.
Reading (xen/xvda,gpt3/boot/grub/grub.cfg
.[H.[J.[1;1H.[1;36H [ grub.cfg 5.67KiB 100% 8.15KiB/s ].[1;1Herror: file /boot/grub/fonts/unicode.pf2' not found. error: no suitable video mode found. .[H.[J.[1;1H Booting Whonix GNU/Linux’
The binary the wrapper script executes would have to be whitelisted. We can’t just whitelist the wrapper.
We could probably make a list of programs to use hardened_malloc with and whitelist them but then that would also allow any malicious LD_PRELOAD tricks on those programs.
Or, maybe we can make an issue on the apparmor gitlab repo about adding specific variables that can be whitelisted when using environment scrubbing if that’s even possible.
This one will not come quickly: the environment scrubbing isn’t actually performed by AppArmor but by the system c library. AppArmor sets the same flag that’s used when setuid/setgid programs are executed, and when the program starts, libc notes the flag and scrubs environment before going very far.
Providing granularity when scrubbing the environment is something we want to do but I don’t think it’ll happen for a while.
The good news is that you could steal the environment scrubbing routine from glibc, add it as a constructor to your libhardened_malloc.so, and modify AppArmor policy to stop setting the secure exec flag when you want to use this library. That way you could still get a mostly-scrubbed environment and use the different allocator. It might not be as easy as this fine-grained scrubbing feature but you could be using it a lot sooner.
I think the bottom part is suggesting we modify hardened_malloc to scrub the environment for us instead of using apparmor for it.
It means to make the apparmor policy execute those binaries without scrubbing the environment as hardened_malloc would handle it (with the proposed solution).
I’d recommend just linking those programs against it. I don’t want to add this.
Linking programs against it is something that is done at compile time AFAIK which isn’t a viable solution for most apps so we can’t have both environment scrubbing and hardened_malloc. Unless we add it to /etc/ld.so.preload and use hardened_malloc globally (with exceptions added for broken programs).
So not that @setharnold is wrong current environment scrubbing is handled by the loader as Seth described, and it is entirely insufficient.
However there are indeed plans for apparmor to pick up environment variable scrubbing. It can be done in the kernel, and we actually have a basic prototype for it but it isn’t a prioritized work item and there is still a lot of work to do on before it can land.
That way while apparmor-profile-everything is enabled, root could enable hardened malloc but not configure an arbitrary (malicious) /etc/ld.so.preload?