mygrep -r Ux | grep apparmor
+ grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3 --exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt --exclude-dir=qubes-src/linux-template-builder/mnt --exclude=changelog.upstream --exclude-dir=.git -r Ux
apparmor-profile-xchat/etc/apparmor.d/abstractions/xchat-based: /usr/lib/firefox-esr/firefox* Ux,
...
apparmor-profile-anondist/etc/apparmor.d/abstractions/base.anondist: /usr/lib/security-misc/permission-lockdown rUx,
A few Ux, uX, cux found in Whonix source code.
Uxshould probably be replaced by at leastCuxor better.uxshould probably be replaced by at leastcuxor better.
Also environment variables scrubing vs non-environment variables scrubbing needs to be reviewed.
Should libraries and binaries be read-only by default and only writable by apt?
It will be harder to install and update your own programs (without using apt) but it will also be harder for malware to compromise a specific program.
documentation:rsbac_handbook:configuration_basics:system_base [RSBAC: Extending Linux Security Beyond the Limits] gives some other good ideas.
As simply a user of Whonix, I would say make Whonix as safe as possible for the general user base. Whonix has so many programs included with it, I’ve never needed to install anything myself. But from what you’ve said the option of installing more software is still there for those that have the need and the knowledge to do it. I just think safety and “peace of mind” is what most Whonix users are looking for, and would go that route. Thanks for all the time to put this together!
That should be all of the ux or Ux rules gone now.
All merged but not tested yet.
It all points to different boot modes. A restricted mode and a mode in which upgrades can be done.
etc/apparmor.d/usr.lib.security-misc.pam_tally2-info and etc/apparmor.d/usr.lib.security-misc.permission-lockdown actually belong to security-misc?
Reverted. Could you please add to security-misc? Also license header required.
^ This is important. Otherwise the profile won’t work.
The line #include <local/bootclockrandomization> will make the profile fail to load.
Above commits makes sure that the postinst script (/var/lib/dpkg/info/bootclockrandomization.postinst) contains the autogenerated debhelper code (bash) to create /etc/apparmor.d/local/bootclockrandomization.
The binaries/libraries will be writable by apt so things like apt-get dist-upgrade and apt-get install will still work. The only thing that would be broken is if you put your own custom programs in /usr/bin without using the package manager.
I think it would be better to put them in apparmor-profile-anondist. The only reason they were created is so we don’t have the unconfined rules in the base abstraction that was made by apparmor-profile-anondist. security-misc is also more focused on hardening the OS in general rather than apparmor profiles.
I always forget that. I’ll try and remember next time.
Some other ideas:
- Disable network access by default and make it opt-in for some AppArmor profiles
- Execute every binary in /usr/bin in a special “application” profile that is more restrictive so the profile doesn’t get bloated by system administration stuff
- Remove the net_admin capability from the main profile and only give things that need it the capability. This can help make sure that IP leaks on the gateway are much harder to do even with root as the firewall cannot easily be disabled.
- Disallow writing to /lib/modules to prevent external modules from being loaded.
- Remove the sys_module capability and only give it to systemd-modules-load so root cannot load their own modules without breaking everything.
- Disallow writing to init (/sbin/init, /lib/systemd/* etc.) to prevent rootkits.
- Scrub the environment of everything.
- Implement some grsec chroot hardening using AppArmor (and maybe a seccomp wrapper) which might make certain sandboxes more secure (firejail uses chroot AFAIK).
security-misc provides applications or functionality. If these get contained using a MAC such as AppArmor, don’t these belong into the same package? The new bootclockrandomization apparmor also wasn’t added there.
apparmor-profile-anondist also has nothing to do with security-paranoid (or however this functionality gets coined). Therefore, if it doesn’t belong into security-misc, does it belong into security-paranoid?
I see. Not too bad. Kinda minority use case. Would still be nice to have (optional) if this was while security-paranoid is enabled if you can think off a solution.
They’re only being contained by AppArmor due to the abstraction in apparmor-profile-anondist. They don’t really provide any security advantage. They’re just a workaround for the holes in the base abstraction.
That’s because that profile had nothing to do with apparmor-profile-anondist.
I can put it in security-misc if you want. It’s not really a big deal.
The only thing I can think of is using sed/str_replace in the initramfs or having multiple apparmor profiles e.g. init-systemd-paranoid.
Please put into security-paranoid (or whatever new package name) since these pam tally2 related apparmor profiles shouldn’t be installed by default for all users due to the potential breakage.
That can’t be done, it will fail without the profile due to the px rule. We could use pux instead to make it fallback to being unconfined but I don’t really like the idea of something potentially executing unconfined.
I doubt there would be any breakage anyway. They’re simple scripts that won’t really be updated much.
If it’s a mandatory profile either way, let’s place them into security-misc.
These snippets
/usr/lib/security-misc/permission-lockdown rpx,
/usr/lib/security-misc/pam_tally2-info rpx,
will be moved to security-misc package as soon as apparmor supports that (abstractions.d / allow adding permissions globally using drop-in .d folder (#50) · Issues · AppArmor / apparmor · GitLab) which might be once Whonix will be based on Debian bullseye. Really non-ideal to have these lines in apparmor-profile-anondist. Would be better if that whole package apparmor-profile-anondist wouldn’t be needed to being with.
Seems better organized to have the apparmor profile of a functionality developed under Whonix umbrella in the same pacakge as s functionality itself.
I remembered to do the licensing and debian packaging this time.
Merged. Will test soonish.
/lib/firmware/ looks like it contains firmware binaries. An attacker might be able to infect the device firmware by replacing files in /lib/firmware/.
That should also be restricted.
Is calling permission-lockdown in security-misc.postinst needed since we have the pam changes?
I think it’s why apt is needing write access to all home directories which is a permission I’d rather not grant.
Not sure.
Allow the global profile to execute permission-lockdown under permission-lockdown profile?