[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Issue T181: Audit of Proposed qubes-whonix 9.6-1

Qubes-Whonix
#1

[b]Issue T181: Audit qubes-whonix 9.6-1

Posted by @WhonixQubes

February 16, 2015

https://phabricator.whonix.org/T181[/b]

Audit of qubes-whonix 9.6-1 package release, developed by @nrgaway, is already underway and nearing completion by @Patrick and @WhonixQubes.

Would like it to be signed off by both @Patrick and @WhonixQubes.

[hr]

Audit of Proposed qubes-whonix 9.6-1

[hr]

Here is a thread for relevant discussion, tickets, links, info, etc for auditing the proposed version 9.6-1 of the “qubes-whonix” package for the Qubes + Whonix platform.

[hr]

Original development source repositories are here:

Relevant issue tickets to this audit are here: https://phabricator.whonix.org/tag/Qubes

#2

@nrgaway

Regarding: /usr/lib/qubes-whonix/enable-iptables-logging

https://github.com/nrgaway/qubes-whonix/blob/master/usr/lib/qubes-whonix/enable-iptables-logging
https://github.com/nrgaway/qubes-whonix/blob/9.6-1/usr/lib/qubes-whonix/enable-iptables-logging

#!/bin/bash -e
# vim: set ts=4 sw=4 sts=4 et :

# Check /var/log/kern.log for logging results

LOG_IP4=1
LOG_IP6=0

# for IPv4
if [ "$LOG_IP4" == "1" ]; then
    iptables -t raw -A OUTPUT -p icmp -j TRACE
    iptables -t raw -A PREROUTING -p icmp -j TRACE
    modprobe ipt_LOG
fi

# for IPv6
if [ "$LOG_IP6" == "1" ]; then
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-reply -j TRACE
    modprobe ip6t_LOG
fi

# Redirect local port to remote via socat
# ---------------------------------------
# apt-get install socat
# socat TCP4-LISTEN:8082,fork,mode=0666,user=root,group=root TCP4:10.137.255.254:8082
#
# Works
# localhost/loopback maps localhost port 8082 to localhost port 8888
# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 8082 -j REDIRECT --to-ports 8888

What is the purpose of this ICMP traffic logging script?

And where is this script called from?

#3

[quote=“WhonixQubes, post:2, topic:872”]@nrgaway

Regarding: /usr/lib/qubes-whonix/enable-iptables-logging

https://github.com/nrgaway/qubes-whonix/blob/master/usr/lib/qubes-whonix/enable-iptables-logging
https://github.com/nrgaway/qubes-whonix/blob/9.6-1/usr/lib/qubes-whonix/enable-iptables-logging

#!/bin/bash -e
# vim: set ts=4 sw=4 sts=4 et :

# Check /var/log/kern.log for logging results

LOG_IP4=1
LOG_IP6=0

# for IPv4
if [ "$LOG_IP4" == "1" ]; then
    iptables -t raw -A OUTPUT -p icmp -j TRACE
    iptables -t raw -A PREROUTING -p icmp -j TRACE
    modprobe ipt_LOG
fi

# for IPv6
if [ "$LOG_IP6" == "1" ]; then
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-reply -j TRACE
    modprobe ip6t_LOG
fi

# Redirect local port to remote via socat
# ---------------------------------------
# apt-get install socat
# socat TCP4-LISTEN:8082,fork,mode=0666,user=root,group=root TCP4:10.137.255.254:8082
#
# Works
# localhost/loopback maps localhost port 8082 to localhost port 8888
# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 8082 -j REDIRECT --to-ports 8888

What is the purpose of this ICMP traffic logging script?

And where is this script called from?[/quote]

It is not called from anywhere. I manually start it in a terminal when debugging firewall issues. I have not needed to use it in some time, but I left it in case network issues come up and that can then be used to help determine the issue.

On another note; in regards to all the above tickets… How do I manage them. I can not see a way in the issue tracker to list tickets related to me that are UN-resolved. I need to be able to quickly see a status of UN-resolved issues so I can keep up with the discussion and not have to keep 10 browser tabs open.

I need the ability to assign tickets to myself; the ones I need to action on so the code gets implemented and not forgotten about and the ability to mark as resolved.

Ideally I would like to be able to see only UN-resolved qubes-whonix related issues or issues assigned to me only.

I’m sure this is already possible, but some advice on how to accomplish this would be appreciated.

EDIT: Patrick assigned me as an admin so I can self-assign tasks.

#4

[quote=“nrgaway, post:3, topic:872”][quote author=WhonixQubes link=topic=961.msg6994#msg6994 date=1424040896]
@nrgaway

Regarding: /usr/lib/qubes-whonix/enable-iptables-logging

https://github.com/nrgaway/qubes-whonix/blob/master/usr/lib/qubes-whonix/enable-iptables-logging
https://github.com/nrgaway/qubes-whonix/blob/9.6-1/usr/lib/qubes-whonix/enable-iptables-logging

#!/bin/bash -e
# vim: set ts=4 sw=4 sts=4 et :

# Check /var/log/kern.log for logging results

LOG_IP4=1
LOG_IP6=0

# for IPv4
if [ "$LOG_IP4" == "1" ]; then
    iptables -t raw -A OUTPUT -p icmp -j TRACE
    iptables -t raw -A PREROUTING -p icmp -j TRACE
    modprobe ipt_LOG
fi

# for IPv6
if [ "$LOG_IP6" == "1" ]; then
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-request -j TRACE
    ip6tables -t raw -A PREROUTING -p icmpv6 --icmpv6-type echo-reply -j TRACE
    modprobe ip6t_LOG
fi

# Redirect local port to remote via socat
# ---------------------------------------
# apt-get install socat
# socat TCP4-LISTEN:8082,fork,mode=0666,user=root,group=root TCP4:10.137.255.254:8082
#
# Works
# localhost/loopback maps localhost port 8082 to localhost port 8888
# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 8082 -j REDIRECT --to-ports 8888

What is the purpose of this ICMP traffic logging script?

And where is this script called from?
[/quote]

It is not called from anywhere. I manually start it in a terminal when debugging firewall issues. I have not needed to use it in some time, but I left it in case network issues come up and that can then be used to help determine the issue.[/quote]

Got it.

It would probably be best to strip developer test scripts and code like this out from public releases.

In order to make the software leaner, less complex, more auditable, and trusted.

#5

[quote=“nrgaway, post:3, topic:872”]On another note; in regards to all the above tickets… How do I manage them. I can not see a way in the issue tracker to list tickets related to me that are UN-resolved. I need to be able to quickly see a status of UN-resolved issues so I can keep up with the discussion and not have to keep 10 browser tabs open.

I need the ability to assign tickets to myself; the ones I need to action on so the code gets implemented and not forgotten about and the ability to mark as resolved.

Ideally I would like to be able to see only UN-resolved qubes-whonix related issues or issues assigned to me only.

I’m sure this is already possible, but some advice on how to accomplish this would be appreciated.

EDIT: Patrick assigned me as an admin so I can self-assign tasks.[/quote]

I see that you are getting the hang of some things with the tracker today.

Regarding only seeing Open tickets…

The best I know at the moment is this link will at least show you Qubes tagged tickets that are still in Open status (not Closed).

https://phabricator.whonix.org/tag/qubes

There is supposedly a more advanced “Query” system where you might be able to drill down further. Haven’t explored that much yet myself.

[hr]

EDIT:

Qubes tag page just got messed up this morning due to a new software version update.

Also, maybe you’re not subscribed to get notified of all new Qubes tickets?

I think adding yourself as a “Member” to the Qubes project/tag may help notify you?

https://phabricator.whonix.org/project/members/17

#6

FYI:

Still looking through the qubes-whonix 9.6-1 code this morning.

Should be through it all within hours.

#7

Moved and answered the question on how to sort tickets here:
https://phabricator.whonix.org/T178

That should hopefully do? I think we can make phabricator work for us. Would wonder if not. It’s uses by much bigger projects (facebook).

#8

[quote=“WhonixQubes, post:4, topic:872”][quote author=nrgaway link=topic=961.msg6997#msg6997 date=1424069012]

It is not called from anywhere. I manually start it in a terminal when debugging firewall issues. I have not needed to use it in some time, but I left it in case network issues come up and that can then be used to help determine the issue.
[/quote]

Got it.

It would probably be best to strip developer test scripts and code like this out from public releases.

In order to make the software leaner, less complex, more auditable, and trusted.[/quote]

Okay, Its been removed

#9

I don’t think those need to be removed. I am in favor of having great dev tools available.

If we had unit tests, we could put them into:

As far I know, this is also allowed by debian policy.

For test scripts, we could put them into:

Or so.

Alternatively, a separate package could be created.

#10

[quote=“Patrick, post:9, topic:872”]I don’t think those need to be removed. I am in favor of having great dev tools available.

If we had unit tests, we could put them into:

As far I know, this is also allowed by debian policy.

For test scripts, we could put them into:

Or so.

Alternatively, a separate package could be created.[/quote]

The proposition of having great dev/test tools available is something I agree with.

My concern is primarily with security auditing.

Dev/test tools often tend to do things that go against optimal anonymity posture in mission critical anonymity environments (like logging additional network traffic, for example).

More scripts and code means there is more to audit and makes it less simple and more time consuming to do so well.

For example, with the single “enable-iptables-logging” script, I had to check all around the “qubes-whonix” package, the other ITL “qubes” repos, and the other Whonix packages to confirm it absolutely wasn’t being invoked somewhere, despite the practicality of it not being so. Even still, with only my cursory grep check, it is still possible for this to still be invoked by obfuscated means that I have not searched for. So that’s one example.

By extra tools like this remaining in as defaults, every thorough audit of a code update would want to keep each and every one of these tools in mind (which is quite hard not to forget about after a while).

If it simply wasn’t there, there would be zero potential concerns or extra time wasted on auditing it.

And their default presence places a similar burden on every new person wanting to audit the package codebase, for each single extra tool and future update.

So, I do support the notion of having great extra dev/test tools available.

However, I generally don’t think they should be included as defaults, due to the added burden of complexity in auditing for potential default interactions with other code. Especially in anonymity systems.

So, yes, let’s make such tools available, but I’d like to see them not included by default.

So, maybe as a separate package(s) that can be optionally downloaded/installed? …and therefore be provably not invoked by any obfuscated or unchecked default means.

And I’m not trying to single any individual out here. Rather, I’m putting my evil hat on, looking for exploitable attack surface in the development of Whonix, and trying to get rid of such possibilities/vectors. I see the inclusion of such extra tools as a potential vector for such attack, even if it is another future developer who decides to contribute some obfuscated means to another component in Whonix, Qubes, Tor, Debian, etc, in order to take advantage of something seemingly harmless.

Does this approach sound okay for a separate package for such extra test tools?

Maybe it would make sense to have a generalized single package where all such extra non-default tools for Whonix could be placed? Then the default Whonix could be that much more of a lean and mean auditable machine. :smiley:

#11

So I’m now satisfied with my cursory audit of the proposed “qubes-whonix” 9.6-1 package version.

I have now looked through the entire code in the @nrgaway and @Whonix GitHub repos for the “qubes-whonix” package up to the following commits…

My cursory review and stamp of approval – for what its worth – should not be taken as any kind of in-depth or professional security audit by others following along.

OK stamp given from me. :smiley:

After any remaining issues of Patrick’s are resolved, I assume the .deb for the Whonix APT repo can be produced, uploaded, and made available for when the new ITL compiled Whonix templates come online?

[hr]

I would like to establish a more formal coordination process, with more time available for community awareness and audits before moving to release, for future versions. Will be following up on hammering out the details of this topic later.

[hr]

Thanks for your development work @nrgaway and auditing/finalizing work @Patrick. :slight_smile:

I have a few things to wrap up on a lagging project with my day job this week, then I’ll be back to finishing public leak testing and the new documentation for this platform.

#12

I don’t have a strong opinion where they should go. Other packages from Debian also come with lots of documentation, examples and unit tests. Example: apt-file list config-package-dev
Unit tests are important. If there is obfuscated means to start them undetected, then the package must be a mess or a sloppy review. And users doing undocumented stuff, such as running scripts from /usr/share/pkg-name/test/xxx… Well, I don’t think we can protect the user from shooting their own feet.

What I think what would be a bad idea, would be a giant package with unit tests for stuff like sdwdate mixed with qubes-whonix. Because sdwdate is general purpose package for any distribution. Then that giant package would look like a mess for anyone we ask to contribute unit tests for their newly written stuff for.

[hr]

Will answer/closer the review ticket. (https://phabricator.whonix.org/T181)

#13

Right. I’m aware it is currently the norm for test code and scripts to be shipped in production software, including anonymity systems.

So it is going on more of an ideal notion of optimization to not ship them as defaults in production anonymity systems.

I wouldn’t have any issue with making them available as optional add-on packages.

Generally, probably true a majority of the time. However, I think there are probably means not covered by messy packages or sloppy reviews where test code/scripts can be invoked. Coordinating across multiple packages or applications could be an example of this. And, while I’m not an expert in these arts, I remember hearing of all kinds of examples where code can be strategically written to look normal but invoke unforeseen consequences.

Yup, I agree with this.

My main concern is with:

  • Simplifying the auditability of the codebase.
  • Removing attack surface for would-be evil developers.

Yeah, I can see that a cross-package tests bundle would not be a good idea for the reason you mentioned.

How about instead…

Making isolated “-tests” packages for each individual package, which are not installed by default?

So, for example, “qubes-whonix” would have a corresponding “qubes-whonix-tests” package.

Also, personally speaking, my main concern here is with “qubes-whonix”.

Since I’m a maintainer of the project, will use it as part of my own personal OS, and have limited time/resources as being one individual to audit every piece of code I use.

So while I do think it would be a good idea for all of Whonix to isolate test code/scripts to separate packages that aren’t shipped, by default, in production…

I’d be personally satisfied at this point, if this ideology were just applied to “qubes-whonix”.

#14

What I also find useful is to have tests installed by default. For example the /usr/lib/anon-dist/chroot-scripts-pre.d/20_sanity_checks is useful sometimes to ask users who have issues to run it. Otherwise you’d have to ask them to install an extra package (which may not be possible) or they’d even want to install it from source. Which adds extra complexity.

I had in mind perhaps during package builds to run - if existing - /usr/share/pkg-name/unit_test and to fail closed.

I am not convinced this applies here. Sure this applies to simple bash scripts or rather C(++) code where a “&” or “+” can make a difference between safe code and remotely exploitable?

Making isolated "-tests" packages for each individual package, which are not installed by default?
Not sure if -tests is the right name.

I am not exited about this. Also not because if you change the interface (variable names, calling arguments, function names, etc.) you easily forget to update the unit test. Or as someone who just reviews a single package and thinks unit tests don’t even exist. But I wouldn’t mind about a single more -tests package. Should be up to the package maintainers indeed.

#15

I agree that tests can help users out and can have some value as default installed when internet connection is down, depending upon specific package and tests in question.

I guess I gravitate towards a conservative perspective when concerning the codebase of anonymity systems, of not including extra code, scripts, features that may run counter to preserving security/anonymity. And also generally assume that either I may have audited less than perfect or that there are means beyond my expertise to pass my scrutiny for invoking such extra code. With people’s mission critical anonymity on the line, I guess I naturally prefer to take these conservative views of defaulting towards simplifying auditing and stripping out non-production code/scripts.

For example…

When auditing this current “qubes-whonix” package version, would it have been an issue if the “enable-iptables-logging” script had been invoked and executed by default?

If an issue, how did you check to ensure that it was not invoked and executed by default?

#16
When auditing this current "qubes-whonix" package version, would it have been an issue if the "enable-iptables-logging" script had been invoked and executed by default?
Maybe. I didn't review for correctness. This means, I haven't toughly thought through all the firewall rules. Things I did were checking the absence of binary files, not wiping / during installation, not setting up remote access and the like.
If an issue, how did you check to ensure that it was not invoked and executed by default?
To run /usr/lib/qubes-whonix/enable-iptables-logging you somehow need to use these strings. Maybe it's split into /usr/lib/qubes-whonix and enable-iptables-logging. Perhaps while both of them are variables. And then run as [font=courier]$cmd[/font] .Without using these strings in one or another combination, it is not possible to run that script by default. Well, one could go creative and make something like [font=courier]a="[u]/[/u]"; b="${a}[u]u[/u]"; c="${b}[u]s[/u]"; d="${c}[u]r[/u]"[/font] and thereby construct that string, but then doing such strange things would raise a red flag.

For the most part shell scripts are almost as easily readable “as plain text”, as you’d manually entered these commands into a shell.

Related, if there where less hacks, more fixed upstream, the qubes-whonix package could be greatly simplified:
https://www.whonix.org/forum/index.php/topic,841.msg7019.html#msg7019

#17

Maybe. I didn’t review for correctness. This means, I haven’t toughly thought through all the firewall rules.[/quote]

Right. I was in the same position… Maybe.

I hadn’t thought of all the ways such rules could be potentially not good for anonymity.

And of course the test script could have been something more invasive (“for testing or debugging purposes”) than a traffic logger.

To run /usr/lib/qubes-whonix/enable-iptables-logging you somehow need to use these strings.[/quote]

Right. And, so did you also check for Whonix related code inside the Qubes package repos for the invocation of these strings?

Wouldn’t this also be a plausible method for slipping in some anonymity breaking/weakening code, by including something in Whonix that modifies anonymity integrity, as a disabled “test script”, but then invoke it from another place like the Qubes packages, so the code still passes inspection with each project and gets included into the production codebases.

So my point is… By having invasive “tests scripts” included extra, which can potentially modify the intended production integrity of anonymity, for “testing or debugging purposes”, then we certainly have to be aware if they are ever being invoked by default for user’s machines, right?

And, even if we can be reasonably sure they aren’t invoked from code inside the direct package or Whonix repo, isn’t it plausible that such test code/scripts could be invoked from another place, like say the Qubes packages? Even if not present right now, then what about invoking them later via future changes to third party packages?

However, if… Whonix by default were to isolate out the non-production purposed test code/scripts, then we wouldn’t have to even have to think about monitoring for the prospect of their invocation beyond Whonix’s own packages. But if these extra non-production scripts are included by default, what’s in place that would stop them from being enabled by default from elsewhere and potentially being quite harmful to Whonix users anonymity?

[hr]

[Note: Again, not to call @nrgaway into question personally at all. He’s doing some great stuff for Qubes and Whonix! Just trying to analyze everything with a skeptical eye in an unbiased way. The core issue goes beyond any example code being discussed now. Would look at things the same way even if RMS was coding for Qubes + Whonix.]

#18

I think may have come up with a Bash code approach for covertly invoking extra test scripts that could appear completely innocent and not be caught in review.

And… If the concerns raised in my last post (https://www.whonix.org/forum/index.php/topic,961.msg7046.html#msg7046) are plausible attack vectors, where contributing test scripts to Whonix packages that would be bad for security/anonymity, and then invoking them from outside packages (such as Qubes), then… I think it would be even much easier to use my potential approach to compromise Whonix by changing its default production behavior/configuration.

And, no doubt that any other non-Whonix software package could directly invoke its own code that harms security/anonymity. But, these direct approaches could be more easily caught by the maintainers/reviewers/community of the other software packages.

However, working from across another outside package to invoke a non-production “test script” in Whonix might be trivially easy to do in a covert way, if done right.

I’ll probably work on demonstrating this covert “innocent” approach I came up with more soon.

#19

[quote=“WhonixQubes, post:18, topic:872”]I think may have come up with a Bash code approach for covertly invoking extra test scripts that could appear completely innocent and not be caught in review.

And… If the concerns raised in my last post (https://www.whonix.org/forum/index.php/topic,961.msg7046.html#msg7046) are plausible attack vectors, where contributing test scripts to Whonix packages that would be bad for security/anonymity, and then invoking them from outside packages (such as Qubes), then… I think it would be even much easier to use my potential approach to compromise Whonix by changing its default production behavior/configuration.

And, no doubt that any other non-Whonix software package could directly invoke its own code that harms security/anonymity. But, these direct approaches could be more easily caught by the maintainers/reviewers/community of the other software packages.

However, working from across another outside package to invoke a non-production “test script” in Whonix might be trivially easy to do in a covert way, if done right.

I’ll probably work on demonstrating this covert “innocent” approach I came up with more soon.[/quote]

A few comments from me :slight_smile:

  1. Patrick has the ability to create a patch and / or add, remove files from my upstream version which will allow him to control any aspect of a release. The qubes-whonix package will be using Patrick’s repo version to build and not the upstream version (mine).

  2. I have removed this script in the version that is going to be used to build the 9.6 template

  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).

What I am trying to say here is I think we should look at also trying to verify every other installed Debian package as well since that is that route would be easier disguise. With the Whonix-Gateway package being so large at the moment, this would be very difficult to achieve. Here are my suggestions on how to accomplish this as I believe you should not complain without a solution :slight_smile:

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.
B) Allow configuration of Gateway via Workstation
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. There are traffic monitoring tools which can also be used to do same.

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.

Thoughts, opinions or comments most welcomed :slight_smile:

#20
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. (https://www.whonix.org/wiki/Contribute#Maintainer)

Ideally, Whonix would not be a Debian derivative, but a Debian Pure Blend. (https://wiki.debian.org/DebianPureBlends) 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?

  1. 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.
  2. Use as little code as possible written in difficult languages. Minimal code that very few people are capable of auditing (assembler, C(++)).
  3. 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…

? 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”.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]