A) Create a whonix-gateway package minimal install. I mean absolutely minimal, only what is required to run and configure it; no gui, nothing not specifically required to run it ... bare bones.
I was wondering about this also. It's hard to decide what's absolutely required and what not for minimal.
Whonix could be created in so many different ways. Even with just instructions only. (That’s how it all started.)
Ideally, most of Whonix’s functionality would be installable from Debian’s repository. I’d love to find (co-)maintainer(s) for every package who ideally review the package, upload to Debian, so I would just be upstream. (Ways to Contribute)
Ideally, Whonix would not be a Debian derivative, but a Debian Pure Blend. (DebianPureBlends - Debian Wiki) Therefore build by Debian servers. Deterministically! Tails devs, don’t attempt this, even though intrigeri is a Debian Developer, because Tails has a 6 week release cycle and because it needs quite some time for packages to migrate from Debian unstable to testing or even stable. It could work better for Whonix. While I think, neither stable nor testing would be really suited for Whonix in the fast changing anonymity world. Rolling Debian distribution would work best. There was an attempt, CUT (Constantly Usable Testing). Unfortunately, it looks like that effort has been abandoned.
Ideally, Qubes would not be a distribution, but an alternative Debian kernel package + other supporting packages. Just as you can install the freebsd kernel as alternative to the linux kernel on Debian, the same would be technically possible with Qubes.
Needless to say, that it’s a hell of a lot work ahead. Likely, this never happens.
B) Allow configuration of Gateway via Workstation
a) This would involve a protocol between gateway and workstation that comes with its own issues.
b) The workstation should not be trusted for that purpose. Changes in the workstation should not allow configuring the gateway in any malicious way such as using colluding bridges.
C) Have a utility on Gateway that periodically checks for un-authorized changes to packages and configuration files. There are a few out there that already do this. Find a unauthorized or unexpected change? shutdown gateway.
This supposed a compromised gateway. But if it was compromised, with today's malware, it can do malicious stuff and make sure you won't find out. (kernel rootkit, skipping certain backdoor files in kernel file system access, etc.) Compromised (malware infected) = game over. No way around that. (For analysis however, someone could write a VM that analyzed the gateway file system or even RAM for malicious things.)
Related, see “Script to System Check Integrity against Debian Package Repository”:
https://lists.debian.org/debian-security/2013/09/msg00053.html
A fine TODO in the Libre Software security world.
There are traffic monitoring tools which can also be used to do same.
Traffic monitoring can work against simpler kinds of malware, but not against sophisticated ones. (That introduce delays to communicate through them or something similarly creative.)
but what about all the other hundreds of Debian packages? Maybe the vim program has some backdoor that opens up some security hole (I sure hope it doesn't).
Yeah. That's a big issue. Those packages are much harder to grasp. Better don't do actual research on how many people audited their code. I am sure, results would be devastating.
Problem is, with C(++) code, backdoors can look the very same as usual security bugs.
Also look up the “Debian OpenSSL debacle”.
Solution?
- Todays programming and script languages have been invented by geeks. Thanks for getting us started. Not by people who understand usability on the top level. Invent brain friendly programming and script languages, that are hard to hide backdoors, use aid from brain researches, do actual usability studies. That would allow a much bigger crowd to program and audit.
- Use as little code as possible written in difficult languages. Minimal code that very few people are capable of auditing (assembler, C(++)).
- Rewrite pretty much everything we got so far.
Very likely to happen during my life time. Most people are happy with stuff as is. Only a minority of the Libre Software community is interested hardcore security. Once a solution works fine for most, there is little incentive to rewrite just to make backdoors much more unlikely.
Simplify whonix gateway firewall rules making them more easily human readable.
Got any specific ideas for that? Looks hard to me. Probably not possible without sacrificing functionality such as stream isolation or configurability.
What I would like to see is the whonix_firewall be automatically generated and only show the rules that apply right now
I find any solution that auto generates code from code difficult. It adds up complexity. Then one cannot just get the code from git and review. They can, but they'd need another process in their head "how would the final result look like when the generator finished". Something to constantly explain and defend.
What about…
sudo iptables --list
? That’s a compiled list, no?
Before making changes to a firewall (any, be it Whonix or otherwise), I run “sudo iptables --list > old”. Then make changes to the firewall script. Then load the new firewall rules. (Or reboot,.) Then store the new rules also within a file. “sudo iptables --list > new”. Then diff them. “diff old new”.