Oh, I didn’t think of that. Removing apparmor-profile-everything won’t work as those files are already protected but I didn’t think of protecting the apparmor binaries/libraries. We’ll need to figure out exactly which files apparmor uses. But, this will break apparmor updates. We could just only allow apparmor updates when apparmor is disabled.
Alternatively (or both for defense in depth), we can make the initramfs hook check if the needed files are there and if not, shuts down.
Files/folders AppArmor uses that I know of:
Work in progress but might be good enough for now, see TODO (expires in 90 days):
https://paste.debian.net/hidden/c49a90d2/
Does not sound great. Sounds like a blacklisting approach. Hard to get complete and hard to maintain long term.
Sounds much better.
The alternative is finding every single file and folder used by every package in the debian repos and manually adding rules for them so apt can actually install them.
Stuff like this (apt) needs to be a blacklist.
Why?
Apt won’t be able to update itself?
Because:
The alternative is finding every single file and folder used by every package in the debian repos and manually adding rules for them so apt can actually install them.
We need apt to be able to install programs in whatever directories they need so we need to grant access to all of /lib, /etc, /bin etc.
Also, I think it would be a good idea for whonixcheck to check for any unconfined processes and warn the user about it if any are found. Grepping ps auxZ output should be fine for this.
I’m not a tech guy, so forgive me if this is a horrible concept. But would publishing a locked down version, with a Full MAC policy and that is not meant to be updated by the user, a viable option? Something along the lines of Tails releases. Have a standard Whonix OS, that we all use now and is updated, and a OS that is only updated for TOR Browser releases and other critical updates?
Publishing more Whonix versions will make releases take far more effort and will give only a small subset of users these security enhancements.
Updates are very important. We can’t force users to use outdated software with known vulnerabilities.
The current policy already allows updating and it’s (mostly) fine. The problem is just locking this down further so it can’t be abused easily but even then, only an advanced and very targeted attack can really abuse this.
Sounds impossible.
Yes. The real APT should have unlimited write access to all the usual folders it writes to.
The real APT itself would not be executable by user. Restricted by apparmor. And restricted APT would filter insane commands. Only restricted APT would be allowed to call real APT.
(From user perspective, just a regular APT call. Wrapper magic.)
This does not seem reliable / stable. Better keep it simple. As little application / package specific as possible.
Removal of apparmor-profile-everything, apparmor and other essential packages could be added to a list packages_refuse_removal or so. And then restricted APT would refuse to remove these.
For example, essential packages list can be auto generated using using dpkg-query.
dpkg-query -Wf '${Package} ${Essential}\n'
(dpkg-query -Wf '${Package} ${Essential}\n' | grep yes, but the parsing needs to be better.)
Enumerating packages we don’t want removed seems like a much more reliable / long term stable approach to me than listing the individual file names shipped by these packages. Also these packages we don’t want removed have dependencies. Messing with these could also break things.
For example we could add linux-image-amd64 to packages_refuse_removal. linux-image-amd64 only. Since that is a “top level package”. We would not add linux-image-4.19.0-6-amd64 since that is a dependency of linux-image-amd64. Protecting the dependencies of “top level packages” such as linux-image-amd64 from being removed would include protecting the specific current kernel package.
For that, we’d need to simulate apt output before running it. APT supports --simulate. Also --quiet=2 to make it easier machine readable. For easier parsing. We could parse that. For example:
apt-get --simulate --quiet=2 purge linux-image-4.19.0-6-amd64
NOTE: This is only a simulation!
apt-get needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don’t depend on the relevance to the real current situation!
Purg linux-image-amd64 [4.19+105+deb10u1]
Purg linux-image-4.19.0-6-amd64 [4.19.67-2+deb10u2]
That one restricted APT should abort since it contains linux-image-amd64.
Maybe there are further apt command line parameters to make parsing even easier.
If we added non-qubes-whonix-workstation-xfce among other “Whonix top level packages” to packages_refuse_removal, that would go a long way. Would keep the system in a sane state with no critical packages removes. Just need to identify other “loose” packages such as linux-image-amd64 which is not a dependency of non-qubes-whonix-workstation-xfce.
It is. That’s why we need to blacklist.
That sounds like a far better idea.
Glad you like it!
I couldn’t stop myself and implemented most of what I said in my previous post regarding restricted APT. Took the liberty to add to git.
Please have a look. I think I can do a good job wrt rapt, not so much inventing the apparmor stuff. Let me know any other requirements for rapt, I’ll see what I can do or send pull requests.
It looks great!
Whenever running it with the update command or no command at all (just ./rapt), I get this error:
E: Command line option --simulate is not understood in combination with the other options
Also, in the top comment, it says “apparmor-profile-anondist” when it should be “apparmor-profile-everything”. That was my mistake.
A compromise would be having a static full system MAC mode in GRUB that’s not meant to support arbitrary application installs for it to be more maintainable and not an entire separate spin.
Fixed.
There might still be a ton of test cases… This also deserves unit tests for common apt commands.
What about exit codes for rapt? Usually, forward the exit code by real apt. But in case of rapt error out…? Start with exit code 150 (or else)? Then for each failure case exit with a different exit code?
http://tldp.org/LDP/abs/html/exitcodes.html
That would be useful for the unit testing. To check if it exit with errors as expected for that test case.
Please let me know
So I can implement and test.
More boot modes…? But it could get a bit convoluted. This was as far as it was discussed earlier:
Alright. So for future when apparmor-profile-everything is ready…
And later if no-root gets implemented…
(Didn’t think much yet about the wording. Open for suggestions. Can be done when time has come.)
Now we have more suggestions which could be different boot modes.
[0] No apt package installation, removal, upgrades. Similar to “read-only root”. Not really “real” read-only root.
I am not sure “no arbitrary package installation” gives us any more flexibility / features than “read-only root”. At the same time “no arbitrary package installation” is probably more difficult to implement than “read-only root”. Or perhaps better called “no APT”.
I don’t know what @madaidan thinks about a “no APT” or “no writing to /etc/ /usr/bin” or “non-admin” boot mode.
Perhaps this is the same as “noroot boot mode”? Perhaps the “noroot boot mode” should have a more restrictive full system apparmor profile?
Probably best to develop this on plain Debian? (Non-Whonix) Worry about Whonix integration later. Does this work on Debian yet?
There is a lot of bad things a compromised root can do with mount such as remounting apt / rapt with a script of its choice. Not sure how this could be contained? Can you let the “system” use mount but any “users” (those using serial console, virtual terminal or ) not using mount?
Since initrd is unconfined for now… Are there things in initrd (processes) which are still lingering after boot and unconfined? Writing to the initrd (in memory, not disk image after booting is done shouldn’t have bad effects and is blocked anyhow?
Thinking about this to prevent choice proliferation:
What would be the use case for a root system with apparmor everything?
You might as well make no-apt synonymous with apparmor-everything because there is no functional advantage to having apt on a system with apparmor-everything (unless you are editing system policy and adding support for more programs).
These are the only boot combinations that make sense to me:
persistent + full-root (DANGER!)
persistent + no-root
persistent + no-root [apparmor-profile-everything]
live + root (*)
live + no-root
live + no-root [apparmor-profile-everything]
(*) I am not sure there’s any useful usecase for having full root in live mode since you can install stuff in no-root mode without needing the full root access.
On the contrary. This mode would be useful if a user wants to install and use arbitrary packages from a safe source without risking full system compromise in case the software has a vuln. Apparmor-everything would make this impossible I think.