Great! 
Right. Understood.
And we should also look to independently make the best choices for the package before putting code in Patrickâs hands.
Right. Understood.
[quote=ânrgaway, post:19, topic:872â]3) I know you are trying to play the âdevils advocateâ here which is fine but one thing I am noticing in some of you recent posts is the narrow-focus on the qubes-whonix package for security hardening. While I agree that this is important I think it may also be just as important to expand this to other packages installed as well.
For instance we can spend a lot of time making sure every byte of code in qubes-whonix can not initiate some type of indented compromise or fingerprint, 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).[/quote]
Right.
I did generalize the concept in my discussion for all of Whonixâs packages.
And I think I mentioned other Linux packages as well.
What got this discussion initially started was the âenable-iptables-loggingâ script, but it has expanded further in scope, and now the âenable-iptables-loggingâ script is basically just being referenced as an original example of the greater code security concept in question.
So this qubes-whonix package audit thread context is becoming somewhat inadequate for this discussion now. Partly why I recently established a new tracker ticket for this issue to try to abstract away.
Patrick mentioned not thinking that the presence of extra test code/scripts in Whonix being a viable threat vector, since we can easily know if they are invoked or not, citing that for Bash code we would notice the script strings or would raise red flags if using creative methods.
Iâm not convinced of this, personally, and think I may have an innocent looking approach to invoke such test scripts. And Iâm no expert at covert code exploits at all, so realizing the limits of my own expertise, and seeing ways to pull this off, I take an even more conservative approach, than just basing my conclusions on the certainty in my own personal expertise. Again, this conservative mindset goes double for me when keeping good peopleâs mission critical anonymity in mind around the world.
Also, while integrity of anonymity & security is the primary concern when auditing a platform like Qubes + Whonix, I was also looking to make the process of doing so more time-efficient.
I view test code/scripts as often working against this purpose. Because, often, test code/scripts do things counter to the goals of the production code (in order to test systems in alternate non-production states). This is the nature of test code/scripts. To modify the normal intended production of systems.
Philosophically, and often concretelyâŚ
PRODUCTION CODE == INTENDED SAFE PRODUCTION SYSTEM STATE
TEST CODE == ALTERED POTENTIALLY UNSAFE NON-PRODUCTION SYSTEM STATE
Thatâs why I was simply suggesting, since were dealing with real live anonymity systems here, to exclude such test code/scripts by default, but offer them as user optional add-on packages if need be.
Also, no one can audit all the other code used beyond the Whonix project. And, I donât currently have the time to audit all of Whonix-proper itself or Qubes-proper itself. Hopefully, Iâll get more time for diving into the code of Whonix and Qubes in general down the line.
I do AT LEAST want to ensure that my administration of the Qubes + Whonix project involves auditing the code contributions that are specific to Qubes + Whonix, now that we arenât just porting stock Whonix with stock Qubes anymore, but rather establishing a newly blended third inter-project platform of sorts.
Patrick also threw out a point about how default included tests for Whonix-proper may have more fundamental utility, like in situations where peopleâs internet is down. Canât deny the principle of such scenarios. But can still advocate for security conservatism and minimalism.
So, with resistance experienced to this concept, and my personal audit-time capacity being much smaller than all of the packages involved, I thought Iâd try to establish something first with the qubes-whonix package and then maybe expand out from there.
Like I mentioned, with regards to code for Qubes + Whonix, Iâm personally okay with us simply omitting all test code/scripts. Or alternatively, as Patrick said he didnât mind us doing, we could put any tests into a separate non-default-installed package, maybe âqubes-whonix-testsâ or something else. Either way.
Made this ticket: [b]Login
Personally â with code I havenât personally written â I find it tedious to see production code that makes sense for the intended normal operational functions, but then also see âtest code/scriptsâ existing side-by-side, and then have to go down the rabbit hole hunting for and auditing all the potential ways to confirm whether the test code is invoked by default or not.
Especially since our Qubes + Whonix platform now involves code inside of two separate parent project repos. In my view, it just makes thorough auditing that much more time-inefficient and potentially insecure. Not to mention the lingering security concerns of such non-production code.
But, I think it would be good to establish a precedent for the Qubes + Whonix platform, and not have to debate it with each bit of test code of every single release going forward. Especially as more people start writing code for Qubes + Whonix in the future.
Donât know about the âverify every other installed Debian packageâ part, as this doesnât seem feasible to me. But I do like the overall direction youâre going in here.
Love this idea.
Without further detail of what you mean by this, this statement hits me as a very bad security idea.
AFAIK, the Gateway treats the Workstation more like an untrusted domain. Allowing the Workstation to have direct control over the domain where the Tor networking configuration and real IP exists seems like bad isolation architecture.
I like this idea. This is another layer of some protection, and certainly a good thing.
But, as a caveat, if the VM gets compromised, then such periodic verification results may not be trustworthy, and be simply forged by whatever exploited occurred. But, not all exploits would design themselves to adapt for this, especially non-Whonix specific ones, and so it could still probably catch and warn of some compromises.
Iâm actually involved in developing a new Qubes application that will be doing this for Qubes + Whonix going forward. It would not interfere with this specific implementation though, as it is separate from our Qubes + Whonix codebase. Just work as additional verification to this.
[quote=ânrgaway, post:19, topic:872â]Now in relation to the qubes-whonix package I think the most important thing to concentrate on at this moment are the firewall rules. Not only the only I added, also making sure that the default whonix rules work as expected with qubes. The Whonix firewall rules seems overly complex to me, so therefore I would also like to see:
D) Simplify whonix gateway firewall rules making them more easily human readable. Currently these rules are applied or not applied based on many criteria and sometimes rules can be added from other sources as well. What I would like to see is the whonix_firewall be automatically generated and only show the rules that apply right now. So move existing whonix_firewall rules to whonix_firewall.template; create a script that will generate /usr/bin/whonix_firewall that contains ONLY the rules that will be set (no conditional statements based on ENV, or var, just exactly the rules that will be applied)
If someone changes an option, in the whonix_firewall.template, or configuration files it reads, they would run âgenerate-whonix-firewallâ which would re-create it again. This would allow someone to easily audit the firewall rules and the order of applying them and would not have to worry about some ENV variable being set by accident, or not by accident.
Anyway, thatâs pretty much my thoughts today. In importance of A, B, C and D, I would like to really see âDâ implemented first as currently it is very difficult to know which firewall rules will be applied and there are too many spots that can be modified to change that behaviour with or without the user knowing about it.[/quote]
Simplification is almost always good, especially in key parts of the system.
Iâm not familiar enough with that component of Whonixâs codebase to comment on any potential pitfalls of this proposed undertaking right now.
Firewall simplification sounds good in general to me.
