Page MenuHomePhabricator
  • No repositories found for this query.

Today

Patrick added a comment to T876: remove browser starter in xfce task bar.

That might work. Seems like a lot effort just to implement this.

Sat, Nov 17, 2:17 PM · Whonix, usability
Algernon added a comment to T876: remove browser starter in xfce task bar.

I guess the only solution would be two separate packages of the desktop config for the gateway and the workstation. Maybe also some kind of postinst script which detects when it is run on the gateway and changes the xml. However, such a starter is also present on a default Xfce installation without a browser so it is more or less default behaviour.

Sat, Nov 17, 11:04 AM · Whonix, usability
Patrick triaged T876: remove browser starter in xfce task bar as Normal priority.
Sat, Nov 17, 9:26 AM · Whonix, usability
Patrick triaged T875: fix fail closed mechanism as Normal priority.
Sat, Nov 17, 6:12 AM · whonix-ws-firewall, whonix-gw-firewall, Whonix 15, Whonix

Mon, Nov 12

Patrick closed T373: Qubes templates: graphical updater (Apper) broken as Resolved.

Apper no longer installed by default.

Mon, Nov 12, 8:47 AM · Qubes, usability, enhancement, Whonix
Patrick placed T373: Qubes templates: graphical updater (Apper) broken up for grabs.
Mon, Nov 12, 8:43 AM · Qubes, usability, enhancement, Whonix

Thu, Nov 8

Patrick changed the status of T721: deb.debian.org instead of us.debian.org and use https by default from testing-in-next-build-required to Open.

Reverted. Main reason:
https://forums.whonix.org/t/https-ssl-tls-by-default-broke-apt-cacher-ng-apt-package-caching-during-build/6276

Thu, Nov 8, 12:32 PM · anon-apt-sources-list, Whonix, Whonix 15
Patrick changed the status of T721: deb.debian.org instead of us.debian.org and use https by default from Open to testing-in-next-build-required.
Thu, Nov 8, 10:02 AM · anon-apt-sources-list, Whonix, Whonix 15
Patrick updated the task description for T721: deb.debian.org instead of us.debian.org and use https by default.
Thu, Nov 8, 9:56 AM · anon-apt-sources-list, Whonix, Whonix 15
Patrick updated the task description for T721: deb.debian.org instead of us.debian.org and use https by default.
Thu, Nov 8, 9:46 AM · anon-apt-sources-list, Whonix, Whonix 15
Patrick updated the task description for T721: deb.debian.org instead of us.debian.org and use https by default.
Thu, Nov 8, 9:45 AM · anon-apt-sources-list, Whonix, Whonix 15
Patrick renamed T721: deb.debian.org instead of us.debian.org and use https by default from deb.debian.org instead of us.debian.org to deb.debian.org instead of us.debian.org and use https by default.
Thu, Nov 8, 9:44 AM · anon-apt-sources-list, Whonix, Whonix 15

Wed, Nov 7

Patrick edited projects for T855: automate /var/lib/tor permission fix, added: Whonix 14; removed Whonix 15.
Wed, Nov 7, 5:04 AM · Whonix 14, whonix-legacy, Whonix
Patrick closed T855: automate /var/lib/tor permission fix as Resolved.
Wed, Nov 7, 5:04 AM · Whonix 14, whonix-legacy, Whonix
Patrick added a comment to T855: automate /var/lib/tor permission fix.

^ I hope this won't be causing issues in future such as when user/group changes from debian-tor to something else (very unlikely?) or when advanced users change user/group ownership for some reason (very unlikely?).

Wed, Nov 7, 5:04 AM · Whonix 14, whonix-legacy, Whonix
Patrick updated subscribers of T855: automate /var/lib/tor permission fix.
Wed, Nov 7, 5:04 AM · Whonix 14, whonix-legacy, Whonix
Patrick renamed T855: automate /var/lib/tor permission fix from whonixcheck check /var/lib/tor folder permission to automate /var/lib/tor permission fix.
Wed, Nov 7, 5:04 AM · Whonix 14, whonix-legacy, Whonix

Mon, Nov 5

Hutchy68 added a comment to T809: mediawiki fixes.

Tracker updated at https://github.com/jthingelstad/foreground/issues/182

Mon, Nov 5, 2:19 PM · Whonix, website

Sun, Oct 28

TNTBOMBOM added a comment to T804: ParrotOS's Firejail Code.

No problem, but needs to add the commands manually to firetools in the GW.

Sun, Oct 28, 6:35 AM · Whonix 16, Whonix
HulaHoop added a comment to T804: ParrotOS's Firejail Code.

I disagree. Firetools makes administration easier and has a place on both VMs.

Sun, Oct 28, 4:49 AM · Whonix 16, Whonix

Fri, Oct 26

TNTBOMBOM added a comment to T804: ParrotOS's Firejail Code.

firejail is enough for Whonix-GW
firejail + firetools for Whonix-WS

Fri, Oct 26, 9:21 AM · Whonix 16, Whonix
Patrick closed T874: Remove Whonix non-free,contrib in the repository as Invalid.

Was discussed before.

Fri, Oct 26, 9:17 AM · Whonix

Thu, Oct 25

0brand closed T858: test if Qubes-Whonix TemplateMVs can upgrade in timesync-fail-closed mode (should not be possible) as Resolved.

Yes (closeable), updates were not possible in timesyc-fail-closed mode. Nothing more to do with this ticket.

Thu, Oct 25, 10:56 PM · Whonix 15, Whonix, qubes-whonix
TNTBOMBOM triaged T874: Remove Whonix non-free,contrib in the repository as Normal priority.
Thu, Oct 25, 1:32 PM · Whonix

Wed, Oct 24

Patrick assigned T858: test if Qubes-Whonix TemplateMVs can upgrade in timesync-fail-closed mode (should not be possible) to 0brand.

Yes. To simulate being in timesync-fail-closed mode:

Wed, Oct 24, 1:12 PM · Whonix 15, qubes-whonix, Whonix
Patrick closed T468: package paxrat for offical debian.org repository as Resolved.

https://packages.debian.org/stretch/paxrat

Wed, Oct 24, 10:08 AM · Whonix, bountysource, bounty, grsecurity, sponsor-B

Sat, Oct 20

0brand added a comment to T858: test if Qubes-Whonix TemplateMVs can upgrade in timesync-fail-closed mode (should not be possible).

Got it. Set firewall_mode=timesync-fail-closed in sys-whonix and reload whonix_firewall. When that is done both whonix-ws-14 and whonix-gw-14 upgrades fail.

Sat, Oct 20, 11:40 AM · Whonix 15, qubes-whonix, Whonix
0brand added a comment to T858: test if Qubes-Whonix TemplateMVs can upgrade in timesync-fail-closed mode (should not be possible).

Not sure how to test this. I read through T533 and found this command but it does not restrict Apt traffic.

Sat, Oct 20, 3:13 AM · Whonix 15, qubes-whonix, Whonix

Oct 17 2018

Patrick renamed T812: use onion sources list exclusively for apt-get updating by default from use onion sources list for apt-get updating by default to use onion sources list exclusively for apt-get updating by default.
Oct 17 2018, 1:08 PM · anon-apt-sources-list, Whonix, Whonix 15

Oct 15 2018

toxdosvyqydtexlr added a comment to T872: mouse does not work in Whonix-Workstation 14 KVM.

By running packages from your distro there is a higher chance that bugs are more visible for more people and more likely to be fixed.

Oct 15 2018, 1:41 AM · Whonix, Whonix 14, KVM

Oct 13 2018

TNTBOMBOM added a comment to T804: ParrotOS's Firejail Code.

@HulaHoop that doesnt mean we dont install firejail by default.

Oct 13 2018, 7:00 PM · Whonix 16, Whonix
HulaHoop added a comment to T80: direct SSL certificate pinning for check.torproject.org and torproject.org (curl method).

We can now grab the browser tarball from the TPO onion instead which makes this ticket obsolete. Close if you concur.

Oct 13 2018, 2:47 PM · Whonix 15, Whonix, whonixcheck, tb-updater, security
HulaHoop added a comment to T567: research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs.

Proposed implementations for multi-Tor suggested here:

Oct 13 2018, 12:44 AM · Whonix 15, research, Whonix, user documentation
HulaHoop added a comment to T567: research: Single Tor-Gateway with Multiple Workstations vs Multiple Tor-Gateways mapped 1:1 to Workstation VMs.

The short story is that things get worse very quickly, but there is hope.
The analysis below assumes only the adversary that runs guards and not the local adversary like the host OS or the Whonix processes themselves.
In my analysis I assume a hypothetical adversarial guard bandwidth of 10% of the entire network. This is an arbitrary number since we don't know the real number, but it serves to show the trends as we increase the guards per client and number of clients per user. I do the kind of analysis we do in the Conflux[1] paper which is very relevant here, especially Table 3 and its discussion in section 5.2. I update the numbers and extend that analysis for the scenarios you have described.

  1. 1 guard/client, 1 client/user. The adversary (i,e, the compromised guard) will have the ability to observe 10% of the clients and hence 10% users. This is the situation today.
  2. 2 guards/client, 1 client/user. This is worse than 1 above. There is now a 18% probability that only one of the guards is compromised per client and a 1% chance that two guards are compromised per client. The probability of at least one bad guard is hence 19%. There really is not a real distinction between one or two bad guards from the user perspective since in both situations the client will go through a malicious guard in a short period of time, since the guard is picked uniformly at random from the guard set.
  3. 1 guard/client, 2 clients/user. The observable clients again increase to 19% from the base 10% in 1 above. This means that if the user split her app (or group of apps) across the clients then there is a 19% chance that at least one of the app (groups) is compromised. However, for each client there is still only a 10% chance that a malicious guard is present. Is this configuration better than scenario 2 above? Perhaps, but let's look at the following scenario first.
  4. 2 guards/client, 2 clients/user. The observable clients increases to 54%. This means that there is a 54% chance that at least one bad guard is present. This is worse than all the other scenarios above. However, if we fix apps (or groups of apps) to particular clients then we can compare to scenario 2 where the app group/client is analogous and the same analysis holds. Then, for each client there is again a 19% chance that there is a malicious guard present. If we compare to 3 above we can see that if we only use 1 guard/client then we can drop the exposure back down to 10% for that client and hence app group.

    Taking the above into account we can get good results by keeping the guard set size to 1 and users spin up one client for each app. Then we can achieve at most 10% of apps compromised at *any given time* but not simultaneously. We can call this scenario (which is an extension of scenario 3) the 1 guard/app scenario (1G/A). See the appendix for more tweaks to decrease guard exposure.

    If we want to consider 1G/A, then the next question for your user base is that is it better to either 1) have some portion of your apps compromised at *all* times (scenario 1G/A) or 2) have *all* your apps compromised some portion of the time (scenario 1). Tor tends to bend towards option 2, but then they have not considered the option of multi-client usage since it doesn't improve the situation in a non-compartmentalized setting, unlike the Whonix situation. I believe that option 2 is flawed because you never know if you are in fact currently compromised or not. It might be better to go ahead with assuming that you are compromised and mitigating that compromise to some portion of your network activity than all or nothing, which is what option 1 provides.

    I hope that answers your questions. Please do not hesitate to get in touch again if you would like to discuss further. I think this is a very interesting problem area and would be happy to contribute to improving the situation.

    Best regards, Tariq Elahi

    [1] http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf

    Appendix We can do better if we allow a user's clients to look at each other's lists to exclude guards that are already picked. The benefit would be that once the bad bandwith has been assigned it can no longer affect subsequent guard selections. However, clients looking at each other's memory space will compromise your vision of process containment. A zero knowledge/oblivious method for comparing guard lists might work to avoid this problem, and indeed the adversarial response will be weak since the best they can do is spread their bad bandwidth over many relays and at best return to the original exposure rate (e.g. 10%) but now with added costs of running many more relays.
Oct 13 2018, 12:42 AM · Whonix 15, research, Whonix, user documentation
HulaHoop closed T872: mouse does not work in Whonix-Workstation 14 KVM as Invalid.

Sorry not reproducible on my end. May be related to the fact that you are running a non-standard setup with custom compiled binaries. By running packages from your distro there is a higher chance that bugs are more visible for more people and more likely to be fixed.

Oct 13 2018, 12:37 AM · Whonix, Whonix 14, KVM

Oct 12 2018

toxdosvyqydtexlr added a comment to T872: mouse does not work in Whonix-Workstation 14 KVM.

made no difference.

Oct 12 2018, 1:17 PM · Whonix, Whonix 14, KVM
Patrick added a comment to T873: Remove Ricochet from Whonix.

https://forums.whonix.org/t/remove-ricochet-from-whonix/5009

Oct 12 2018, 9:58 AM · Whonix, Whonix 15
HulaHoop closed T869: Install Firejail by default inside Whonix as Resolved.

Closing. duplicate of:

Oct 12 2018, 12:21 AM · Whonix 15, firejail, Whonix
HulaHoop closed T873: Remove Ricochet from Whonix as Invalid.

There is nothing dead about it. I jsut explained this on the forum. It is perfectly workable and openprivacy is owrking on creating a P2P asynchronous chat solution over its protocol.

Oct 12 2018, 12:15 AM · Whonix, Whonix 15
HulaHoop added a comment to T869: Install Firejail by default inside Whonix.

It's on the roadmap but a little far off until ParrotOS changes can be combined with the upstream package. It will make maintenance and turning it on by default much more easier.

Oct 12 2018, 12:12 AM · Whonix 15, firejail, Whonix