Re: [qubes-users] Valid Concerns Regarding Integrity of Whonix Project

['Xaver' via qubes-users]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, February 15, 2019 10:58 PM,  wrote:

> Dear Patrick,
>
> I appreciate your answer and understand your point of view. On the other 
> side, the issue raised by the law in Australia (and GCHQ asked for that too, 
> like the request of ghost user in all the "encrypted" conversations) is an 
> important security concern and should be taken into consideration in the 
> thread/trust model not only with Whonix, but with all the HW, SW, 
> infrastructure and personnel. As of today, it is not.

While this threat is certainly a concern it is nothing new. Although new in 
Australia, many other countries have had similar laws and/or don't have any 
laws that would prevent the govts from forcing a person to do pretty much what 
ever they want. With ever evolving threats it would be near impossible to keep 
up. Once a mitigation is found for one, two more emerge. How do you combat 
adversaries that have near unlimited resources? Trust model/concerns have been 
considered in https://www.whonix.org/wiki/Trust. (Has anyone bothered to read 
it?)

>
> Existing thread models are currently not considering this form of attack. 
> Same way as the existing thread models, including those of Qubes, TAILS, 
> Whonix and others, are not covering the thread of being forced on the border 
> to GB or US to hand over all the keys to all your digital devices under the 
> thread of imprisonment. There is no Hidden OS functionality mentioned, and no 
> known development in this area, even the thread exists and ppl are already 
> successfully exploited by these attacks.

If anyone can come up with a mitigation to an adversary putting a gun to a 
developers head and asking nicely for their private key - id like to hear it. 
How exactly does someone overcome an impossible situation? How do you you cover 
a - do as is say or die- threat model? Holy shit! It was here all along!  
https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny

>
> This is but not an issue of Whonix. It is an issue of not addressing the new, 
> emerging attacks clearly. The FMECA, which is constantly not updated, becomes 
> obsolete, and continuously useless. From my personal experience, if people 
> are sub-aware that some FMECA points could be very difficult to address and 
> solve reasonably, they tend to avoid to put it in to the FMECA and start to 
> care.
>
> Concerns related with that Ausie law and similar activities of some entities, 
> are based on reality. Before the law was here, it was more difficult to 
> successfully reach forced cooperation. Usually it was through blackmail, 
> convincing, threads or similar activities, to forge the canaries and insert 
> the dirt in the code or HW. There was still quite good space for an effective 
> resistance of the personnel, if one wanted. The personnel was protected by 
> law. The kind of moral part today is killed there completely. Today they just 
> come and bring you the lawful request and you must comply with it and fulfill 
> the request, or go directly to jail ( I think it is 5 years?), and at the 
> same time you are bound not to tell anyone, by any means be it your corporate 
> employer, your teammate, brother or development project partner. They 
> effectively created from every citizen a potential agent, which cant deny to 
> become one if requested.

Yes, before the law other means would be necessary to compel a developer to 
backdoor software in **Australa**. Now the laws says the govt can force a 
person, or go to jail. Some would choose jail (then the cats out of the bag. 
Everyone would then know why they went to jail. common sense). Others might not 
have much of a choice. Regardless, this and other emerging attacks has been 
consider and covered (not necessarily whonix specific)

* https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny

* https://www.whonix.org/wiki/Trust#Trusting_Debian_GNU.2FLinux

* https://www.whonix.org/wiki/Trust#Trusting_Tor

* https://www.whonix.org/wiki/Trust#Evil_Developer_Attack

>
> Quite easy countermeasures were possible, if the devs (in this case), were 
> anonymous. But they are not so much, right? Therefore are open to this 
> particular attack that just emerged. How and when will it be added to the 
> thread model and covered, together with other new emerging threads, by 
> respective tams, is the only question to be answered.

Already covered.

My questions: When will the people who bring these issues up (valid issues) 
realize this is a shared burden - both devs and community. Why didn't the OP 
feel compelled to put forth the effort to research and understand this problem 
before crying wolf? This issue is not new. This same issue (developers 
backdooring) had been discussed and beaten into the ground countless times.

Here is what is comes down to. Developers can be forced to alter/backdoor 
software in **many** countries. It makes no difference how 

Re: [qubes-users] Installing snaps in appvms?

[Stumpy]

On 1/9/19 8:02 PM, Stumpy wrote:

On 1/9/19 7:54 PM, Stumpy wrote:

On 1/9/19 7:32 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Jan 09, 2019 at 07:11:50PM -0500, Chris Laprise wrote:

On 01/09/2019 06:41 PM, Stumpy wrote:

On 1/8/19 7:59 PM, 'awokd' via qubes-users wrote:

Stumpy wrote on 1/9/19 12:07 AM:

On 1/8/19 7:04 PM, Stumpy wrote:

I thought I had snap installed but the app i installed via
snap now does not seem to be working? I installed snapd in
dom0 then tried installing a snap package in one of appvms
but I am getting errors. If i try to run a snap from dom0:
qvm-run gfx /snap/bin/xnview

I get:
Running '/snap/bin/xnview/ on gfx
gfx: command failed with code: 1

when i try to run it within the appvm i get:
user@gfx:~$ xnview
Can not open
/var/lib/snapd/seccomp/profiles//snap.xnview.xnview (No such
file or directory)
aborting: No such file or directory

thoughts? please?



oh, and if i try to reinstall the app I get:
user@gfx:~$ sudo snap install xnview
snap "xnview" is already installed


Nothing should be installed to dom0. You'd have to install snapd in
a template, and possibly the snap package. You might want to create
a Standalone VM and install everything in there, instead of
templates & AppVMs.




Thanks, I had thought I had to install on dom0 as well, perhaps not,
though when I try to:

sudo snap install xnview from the template I get:
user@debian-9:~$ sudo snap install xnviewmp
error: cannot install "xnviewmp": Get 
https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: 


dial tcp: lookup search.apps.ubuntu.com on 10.137.3.254:53: dial udp
10.137.3.254:53: connect: network is unreachable

So i was thinking that doing a qubes-dom0-update something so it could
get through? For the life of me i cant figure out what I did on my 
other

computer to make it work but it works fine there.


I forgot to mention, it is installed in the appvm:


user@debian-9:~$ sudo apt-get install snapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
snapd is already the newest version (2.21-2+b1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


ideas?



Only apt is configured to access servers through the special Qubes 
proxy.
Since templates have networking turned off by default, that means 
nothing

else can download packages or data.

In the short term, you can try enabling networking temporarily for the
template while you install snap packages. Just set the netvm in the
template's settings.

In the long term, Qubes users may benefit from a special 
accommodation of
snap, which has become a versatile and important way to install 
software.

Support could include access through the update proxy and even special
storage capabilities. Would be a good idea to open an enhancement 
issue for

this. :)


There is some progress on this already:
https://github.com/QubesOS/qubes-issues/issues/2766

The current state is: you can install "qubes-snapd-helper" package in
_template_, to be able to install snaps in qubes _based on that 
template_.



- -- Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlw2kq8ACgkQ24/THMrX
1yzNvwgAhc0/O9VIzBGH1WDg8l+1sH3yLxxySFannO2ihUUXbUA80cf4+uxrxk/1
Rg+jR0XfdBXD91h817luvs3mIdqwcluq1YHxbGIb0J/vALPLHRhZ8YLasXSdpDIG
MyiVTk1ogAOG6jH30245V/GRPWALJmysYnW4DUki3ZefG/EyCFHWi7lpJZ9XS00F
QbVv7MoDx6GbHiSfHMzYk016fSaEAFlXGUUXczSHgDpJjumP6+MfVkz0l4diYbm5
wGOPIknWLBBSQMMOS0IoaB1iq1hYbZNULt6/gaOOFBIC2I9D2m4Q8KHKeDz95qln
HEzk2d5IJJlv8M1xpoNyzS0+IJNHMQ==
=hL/D
-END PGP SIGNATURE-

Thanks Marek! I thought there was something, I will recheck what I 
have done and make sure I tried the snapd helper in the right place.




That got it Yeah!! Thank you soo much.
Made notes on how it got done this time :)



appologies for digging up such an old thread but I am back to having 
issues with snaps. I installed qubes-snapd-helper in the template awhile 
ago and then in my appvm I tried to install xnviewmp, foobar2000, and 
firefox quantum but to get foobar2000 started I have to run:


sudo snap install wine-platform
sudo snap install foobar2000
sudo snap connect foobar2000:wine-platform-plug 
wine-platform:wine-base-stable

sudo snap connect foobar2000:removable-media

though perhaps I just need the last two lines because it keeps telling 
me that wine and foobar2000 are installed.


for firefox, I haven't figured it out, sometimes I 

Re: [qubes-users] How does Qubes DNS resolving work?

[unman]

On Fri, Feb 15, 2019 at 08:12:35AM +0100, ashleybrown...@tutanota.com wrote:

> > Please don't top post. Take a minute to make it easier for other users.
> > As is clear in another thread, there is a clear warning about DNS on the
> > GUI firewall - I find it hard to believe that anyone could miss this.
> >
> I am new to mailing lists. What does top-post mean? Do you mean don't post 
> the reply at the top of the message and instead at the bottom like this?
> 

That's right, just like that.
It's also acceptable to interleave comments within the text:

> Can you give an example?
Of course, here is one.
> When would you want to do that?
When you want to comment on a number of distinct issues within the post.

It's also good to cut out extraneous material - as I have done here.
Some people cut *all* the previous posts, and that makes it very
difficult to follow what is going on.

Welcome to the lists.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190216023016.4q265tvlk3yobxox%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 some updates always skipped

[Sergio Matta]

Em sexta-feira, 15 de fevereiro de 2019 23:03:12 UTC-2, Sergio Matta  escreveu:
> > Some updates show as always skipped after each qubes-dom0-update run.
> > 
> > How to fix this? 
>   
> Maybe "sudo qubes-dom0-update --best --allowerasing" can solve your problem, 
> if not maybe they are already installed, try "sudo dnf clean packages" or 
> reinstall "sudo qubes-dom0-update --action=reinstall anaconda-core ... and 
> the others

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d67c9cee-2085-4b3e-8c60-701bbab72b2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 some updates always skipped

[Sergio Matta]

> Some updates show as always skipped after each qubes-dom0-update run.
> 
> How to fix this? 
  
Maybe "sudo qubes-dom0-update --best --allowerasing" can solve your problem, if 
not, tell us what packages are not installing. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/545ef562-68ca-4f66-92ca-dfbb9b51091b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Dom0 some updates always skipped

['Evastar' via qubes-users]

https://i.imgur.com/qnH5JNh.png
Some updates show as always skipped after each qubes-dom0-update run.
How to fix this?
Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/QxIpP_inmY6stdgTWQFLvcE_R40B82m6h6rwr2a55v9k-TNwf-T0bkwWD11P8x1HbP5VXIhsj9V14Qf439yCCTkY1dJaMmo0tKeZ0-7pWGc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Purism Librem 15 v4

[Matt DeVillier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Purism Librem 15 v4 HCL attached. All devices functions fully working (full 
IOMMU w/VT-d, etc),
factory shipped firmware (coreboot 4.8.1-Purism-4)

cheers,
Matt

-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v2.5.11
Comment: https://openpgpjs.org

wsFcBAEBCAAQBQJcZ0syCRAru3dqNbl4/QAAz+oQAMVAW+R6ot+rtrGU3XuV
jbNuzskJaOqUO7T0YvZnpnI1vwODmcPkS+/svUITOSOrTYifBHZHSHUgthAh
EJuhMmKTDuVVb06eGCkA3EJBbXNS6rjVSi4dZBscvlHu+ius6SBjSorRSS6b
NOjtgRFuyZ/bkYp/sBxeTQV1zXQR8MdGWVZowgRcV3Zu+xkP7Kqm6nXg4MX8
bhKfyTNZdt4dQcMA6NvPBRE1Go8JQHJuiqsoyV7FGBV5HK8VZM8cTOH7MqFE
7H/W10SzVPsHR3f+Dy2aD6JcWGVKi8ydde5UYgf3DCm1NgktrRMJ5JN5vYJj
2HanshR0zu6H+81uhjIQnVU+GZWeSs8bsVDOg4FlZ2hEf75I6XCGqNClPdk/
7m6CZn3jy534woEoNRB7EI3aHoUgw4VDXyiR9zW6uJ4MyFX97rGlkAL5QmSF
ghcnGD8aX3BOwLeDcbA0XNhQNApYBChEzvGW2zzyt87gTSSgoPgBQsn0SrqS
ZCfXxoJG//nhISfXWZd+7dvmGl9e0TxJ5Ksa5yjnDAK5s5VVEfEtRv1C/EPG
WxHjrzpmijjCjQNNZam15G3wZ1TwYbe4B5HQkBcR38JRFpaH+zriDCjUwX8e
fLEI7hu5HU9acDsh0Jv7rcLG3nAXKhF/KG9+CQ0L0tUI5d5uSvMk5rPLtACR
8Giu
=B0FE
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c4e7c2bca49380532dd7cf571488a67d%40puri.sm.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Purism-Librem_15_v4-20190215-182240.yml
Description: Binary data

Re: [qubes-users] Black screen when booting Qubes 4.0.1 installer via usb

['awokd' via qubes-users]

Dan Grant wrote on 2/15/19 4:53 PM:


Turns out there's a hardware issue with this laptop so a replacement is being 
sent. I'll test this again when I get the new one after confirming the general 
issue has been resolved.



I suspect I'll see the same thing, but at least I'll know for sure.



Thanks much awokd!



No problem, good luck!

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bb2ef71e-85dd-fa1d-c122-57cce4a7cca2%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] dom0 update skippet

['Evastar' via qubes-users]

Some updates show as always skipped after each qubes-dom0-update run.
How to fix this? i.imgur [DOTCOM] / qnH5JNh [dot] png
Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/KIZrVIgG14vA4NI65GMpqeh8QHDWjeh8VKPEciLmSTocwfd6Bd25nh-2cN0Itc6L3Rr70BLNkPxTn5o3LzRQ7sWrMPZfJsK1hvqq3-yop84%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] [warn] last whonix-gw update, ipv6 and possible VPN leak!

['Evastar' via qubes-users]

> FWIW, I'm not sure when Qubes started enabling ipv6 by default. I > thought 
> R4.0 was going to support ipv6 but leave it disabled by default? > Thanks for 
> fix. I found it! BTW, I have the same question! I never enable ipv6 and it's 
> my old vpn vm! Maybe I'm compromised? All work like a charm until today when 
> I found that leak. Must I disable each vm ipv6 manually now? How to do this 
> in one batch? Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/BUeyvl_-QqCmhf5Atpjs0oLpUay86VkrK69i9Isi6rZQ48AwqDKjxiDWA2J296twDnHOpgmoNHNOBlfHprhAd_gMImVm1O6_paHWTyKBEqg%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Valid Concerns Regarding Integrity of Whonix Project

[qubes-fan]

Dear Patrick, 

I appreciate your answer and understand your point of view. On the other side, 
the issue raised by the law in Australia (and GCHQ asked for that too, like the 
request of ghost user in all the "encrypted" conversations) is an important 
security concern and should be taken into consideration in the thread/trust 
model not only with Whonix, but with all the HW, SW, infrastructure and 
personnel. As of today, it is not.

Existing thread models are currently not considering this form of attack. Same 
way as the existing thread models, including those of Qubes, TAILS, Whonix and 
others, are not covering the thread of being forced on the border to GB or US 
to hand over all the keys to all your digital devices under the thread of 
imprisonment. There is no Hidden OS functionality mentioned, and no known 
development in this area, even  the thread exists and ppl are already 
successfully  exploited by these attacks. 

This is but not an issue of Whonix. It is an issue of not addressing the new, 
emerging attacks clearly. The FMECA, which is constantly not updated, becomes 
obsolete, and continuously useless. From my personal experience, if people are 
sub-aware that some FMECA points could be very difficult to address and solve 
reasonably, they tend to avoid to put it in to the FMECA and start to care. 

Concerns related with that Ausie law and similar activities of some entities, 
are based on reality. Before the law was here, it was more difficult to 
successfully reach forced  cooperation. Usually it was  through blackmail, 
convincing, threads or similar activities, to forge the canaries and insert the 
dirt in the code or HW. There was still quite good space for an effective 
resistance of the personnel, if one wanted. The personnel was protected by law. 
The kind of moral part today is killed there completely. Today they just come 
and bring you the lawful request and you must comply with it and fulfill the 
request, or go directly to jail ( I think it is 5 years?), and at the same time 
you are bound not to tell anyone, by any means be it your corporate employer, 
your teammate, brother or development project partner. They effectively created 
from every citizen a potential agent, which cant deny to become one if 
requested.

Quite easy countermeasures were possible, if the devs (in this case), were 
anonymous. But they are not so much, right? Therefore are open to this 
particular attack that just emerged. How and when will it be added to the 
thread model and covered, together with other new emerging threads, by 
respective tams, is the only question to be answered.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/LYnNVQl--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

['awokd' via qubes-users]

ashleybrown...@tutanota.com wrote on 2/15/19 7:12 AM:


I am new to mailing lists. What does top-post mean? Do you mean don't post the 
reply at the top of the message and instead at the bottom like this?



Much better, thank you. If you want to make sure there is no network 
communication from an AppVM, don't connect it to a NetworkVM in the 
first place. :) But like Unman said, there's a note at the bottom of the 
GUI firewall tab regarding DNS and ICMP. Those can be fine tuned with 
"qvm-firewall [qubename]" in a dom0 terminal.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/39d46c68-9183-8d6c-b201-ff8fd4e8045e%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [warn] last whonix-gw update, ipv6 and possible VPN leak!

[Chris Laprise]

On 2/15/19 4:14 PM, 'Evastar' via qubes-users wrote:

Hello,

Seems after last whonix update my old VPN VM begin leaking traffic. 
After investigation I found that it's because ipv6 primary connection to 
whonix-gw. I guess that whonix-gw now supporting ipv6. It leak traffic 
through ipv6 connection to whonix and ignore my default old ipv4 setup. 
"qvm-features VM ipv6 0" fixed this issue! But I'm not sure about all my 
others vpns and leaking with ipv6. How I must fix this at vpn setup (on 
load) to be 100% sure that it never happen again?


The Qubes-vpn-support / qubes-tunnel firewalls have had ipv6 anti-leak 
for some time now. Also, the scripted section of the Qubes vpn doc has 
had it as well when I added it last July. But it looks like the Network 
Manager section should be updated to also include it, since that section 
now suggests firewall settings.


FWIW, I'm not sure when Qubes started enabling ipv6 by default. I 
thought R4.0 was going to support ipv6 but leave it disabled by default?


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aca8c323-6704-a7c9-406a-b6ce3f9634d7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] [warn] last whonix-gw update, ipv6 and possible VPN leak!

['Evastar' via qubes-users]

Hello,

Seems after last whonix update my old VPN VM begin leaking traffic. After 
investigation I found that it's because ipv6 primary connection to whonix-gw. I 
guess that whonix-gw now supporting ipv6. It leak traffic through ipv6 
connection to whonix and ignore my default old ipv4 setup. "qvm-features VM 
ipv6 0" fixed this issue! But I'm not sure about all my others vpns and leaking 
with ipv6. How I must fix this at vpn setup (on load) to be 100% sure that it 
never happen again?

P.S. Thanks for Qubes

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ZbFxX8Bzwmmq6cCYAZnq5M2qsNHhqj6ACMOA8fSO9BtxQaTguKDbCbLiFjsKnOFutrk_aY9yYoD0uhwQlxrGdmuQRftDB-I2JsFb_2RWrwQ%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes for enterprise usage

[tggrps]

Hi all,

Did anyone try to use Qubes for enterprise use cases? e.g. for securing access 
to sensitive resources? How did that end up?

Last time I looked at Qubes, it didn't have enterprise manageability features 
and required users to be familiar with Linux, which is not always the case with 
enterprise users. The HCL is also a bit of a concern as enterprise laptops 
might not well support Linux (audio/video/docking stations/wifi/power 
management...).

Details about your experience with Qubes today for enterprise users (either 
power users or simple users) would be helpful!

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/de19e075-0278-4b3a-aaa3-6f6801839687%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Effectiveness of the VM compartimentation

[Chris Laprise]

On 2/15/19 8:47 AM, nosugarmaxta...@gmail.com wrote:

On Friday, 15 February 2019 16:37:17 UTC+11, Chris Laprise  wrote:

On 2/14/19 10:02 PM, nosugarmaxta...@gmail.com wrote:

Hi all,

Right now I use Qubes for a bit of fun - setting up VPN's - chaining them, 
trying to get HVM's up and running, just messing about. I do plan to totally 
phase out my other OS's for it, but theres one thing that keeps going through 
my mind.. how isolated are the VM's from each other actually?

I know Qubes is 'reasonably' secure, but how secure? Could a whistle blower 
have a whonix VM open handling sensitive materials while at the same time have 
a personal VM with ISP connection and google/facebook/work sites open, with no 
issue at all? If the whistleblower would only be able to use the machine for 
sensitive purposes due to leak potentials, etc, wouldn't this make using Qubes 
pointless?


Of the myriad remote attacks that can be used against traditional
operating systems, basically one type is thought to be effective against
Qubes in general: Side-channel attacks.

https://en.wikipedia.org/wiki/Side-channel_attack

The best way to mitigate these is to not run public key crypto in
trusted VMs at the same time untrusted VMs are running (although this
can be a problem when VMs like sys-net and sys-usb are considered).
Also, test your hardware to see if its susceptible to rowhammer.

In contrast, even a physically isolated system can be less secure than a
Qubes system. This is because the devices and drivers used for
interfacing (SD cards, DVDs, USB drives - even occasionally) are much
more complex and vulnerable than the interfaces on a Qubes VM. And if a
Qubes VM does become compromised, chances are much better that the core
system and firmware will remain safe.

https://blog.invisiblethings.org/2014/08/26/physical-separation-vs-software.html

Finally, assuming that attacks will succeed at least occasionally (and
Qubes is built with this assumption for guest VMs): How recoverable is
the situation? A Windows system that had its firmware compromised will
continue to run malware even after the OS is wiped and re-installed. A
Qubes system OTOH probably has intact firmware and malware can be
removed by removing the affected VM.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


Thanks for the reply, Chris.

So, apart from the rare chance of a side-channel attack. One should be able to 
surf safely in Whonix, or a private VPN'd VM, while being able to surf regular 
sites such as this google hosted mail group on another without overlap, or the 
data from Whonix hitting a non-torified machine?



Yes, I believe the isolation in that context to be excellent, especially 
since Qubes 4.0 now uses hardware isolation for VMs (PVH mode instead of 
PV). PV mode had allowed some containment issues to arise in the past, 
but hardware virtualization capability has become widespread enough (and 
better supported in Xen) such that the new PVH mode could be used for 
better isolation.


-

As for side-channel attacks, they are thought to be rare and difficult 
to execute but I wouldn't count on it remaining that way. Tor Project 
appears to be testing constant-time crypto to avoid some of the worst 
side-channels:


https://trac.torproject.org/projects/tor/ticket/18896

Other improvements in side-channel resistance will come not from crypto 
code but from better hardware such as RAM and CPUs. I believe you can 
get somewhat better resistance already by using AMD instead of Intel 
CPUs, as AMD appear to take fewer shortcuts and fare better against 
Spectre and Meltdown, for example. ECC RAM support is also more 
prevalent in AMD products, and this provides some protection against 
rowhammer.


In the long term, some of us are hopeful that open source hardware could 
address these nagging issues, as well as the issue of possible backdoors 
in hardware and firmware. We have some advocates here for OpenPOWER, 
although Qubes cannot yet run on it.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/230ec3ac-e064-0566-3c16-f64313f0d1e7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Black screen when booting Qubes 4.0.1 installer via usb

[Dan Grant]

 On Wed, 13 Feb 2019 17:32:14 -0600 'awokd' via qubes-users 
 wrote 




Dan Grant wrote on 2/13/19 7:20 AM: 

 

> I am able to comment out the mapbs and noexitboot lines in the 
> [qubes-verbose] section of EFI/BOOT/BOOTX64.cfg, but it is not at all clear 
> what is meant in step 2 of this section: 

> 

> https://www.qubes-os.org/doc/uefi-troubleshooting/#change-installer-kernel-parameters-in-uefi
>  

> 

> what the following means exactly: 

> 

> "Edit your xen config (xen.cfg/BOOTX64.cfg) changing the kernel key to add 
> your kernel parameters on the boot entry of your choice" 

> 

> Specifically this bit: "...changing the kernel key to add your kernel 
> parameters on the boot entry of your choice" 

> 

> Does it mean something more than commenting out the mapbs and noexitboot 
> lines in the [qubes-verbose] section? 

 

Not for what you're trying to do- just commenting those lines out should 

have done it. 

 

> ps - I'm attempting to install on a new System76 Galago Pro laptop with 
> Insyde HxBios firmware, 8th gen I5 chip, & 32GB RAM 

> 

 

Does it have an nvidia card? Those cause problems sometimes.



Otherwise, check this out- might be complex to get Qubes installed on that 
laptop: 

https://www.mail-archive.com/qubes-users@googlegroups.com/msg13362.html. 








re: video card - No nvidia card. System76's tech specs page shows "Intel® UHD 
Graphics 620".



re: your link - GAH! I spent hours searching for info just like that, and 
somehow I missed it... :(



Turns out there's a hardware issue with this laptop so a replacement is being 
sent. I'll test this again when I get the new one after confirming the general 
issue has been resolved.



I suspect I'll see the same thing, but at least I'll know for sure.



Thanks much awokd!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/168f213a5e4.c7e8400423229.4287070139156571725%40xq42.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Effectiveness of the VM compartimentation

[nosugarmaxtaste]

On Friday, 15 February 2019 16:37:17 UTC+11, Chris Laprise  wrote:
> On 2/14/19 10:02 PM, nosugarmaxta...@gmail.com wrote:
> > Hi all,
> > 
> > Right now I use Qubes for a bit of fun - setting up VPN's - chaining them, 
> > trying to get HVM's up and running, just messing about. I do plan to 
> > totally phase out my other OS's for it, but theres one thing that keeps 
> > going through my mind.. how isolated are the VM's from each other actually?
> > 
> > I know Qubes is 'reasonably' secure, but how secure? Could a whistle blower 
> > have a whonix VM open handling sensitive materials while at the same time 
> > have a personal VM with ISP connection and google/facebook/work sites open, 
> > with no issue at all? If the whistleblower would only be able to use the 
> > machine for sensitive purposes due to leak potentials, etc, wouldn't this 
> > make using Qubes pointless?
> 
> Of the myriad remote attacks that can be used against traditional 
> operating systems, basically one type is thought to be effective against 
> Qubes in general: Side-channel attacks.
> 
> https://en.wikipedia.org/wiki/Side-channel_attack
> 
> The best way to mitigate these is to not run public key crypto in 
> trusted VMs at the same time untrusted VMs are running (although this 
> can be a problem when VMs like sys-net and sys-usb are considered). 
> Also, test your hardware to see if its susceptible to rowhammer.
> 
> In contrast, even a physically isolated system can be less secure than a 
> Qubes system. This is because the devices and drivers used for 
> interfacing (SD cards, DVDs, USB drives - even occasionally) are much 
> more complex and vulnerable than the interfaces on a Qubes VM. And if a 
> Qubes VM does become compromised, chances are much better that the core 
> system and firmware will remain safe.
> 
> https://blog.invisiblethings.org/2014/08/26/physical-separation-vs-software.html
> 
> Finally, assuming that attacks will succeed at least occasionally (and 
> Qubes is built with this assumption for guest VMs): How recoverable is 
> the situation? A Windows system that had its firmware compromised will 
> continue to run malware even after the OS is wiped and re-installed. A 
> Qubes system OTOH probably has intact firmware and malware can be 
> removed by removing the affected VM.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Thanks for the reply, Chris.

So, apart from the rare chance of a side-channel attack. One should be able to 
surf safely in Whonix, or a private VPN'd VM, while being able to surf regular 
sites such as this google hosted mail group on another without overlap, or the 
data from Whonix hitting a non-torified machine?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/959953e2-7216-4af2-9251-10f1a433b82f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Valid Concerns Regarding Integrity of Whonix Project

[Patrick Schleizer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* I was advised in private e-mail by @mig5 about this new law before
it took effect beforehand, and @mig5 offered to step aside because of
it. It was my decision to not to change anything. Below I will explain
why.

* I might have reacted in a better way by protectively discussing this
subject in public but that is really hard without nonproductive
discussions and without badmouthing @mig5 in unintended ways.

* @mig5 doesn't moderate Whonix's forums. That thread wasn't deleted
by @mig5.

* I've not researched that Australian law. And I like to avoid it. If
I had to bet, I guess their interpretation is reasonable. For
practical purposes explained below it wouldn't matter.

* From a security enthusiast perspective it's a reasonable question.
No one or only a few have the complete picture.

* The issue with one asking this question are the hidden presuppositions
.

* The presupposition is that the server location is somehow secure.

** That's not true.

** Assume a regular commercial server host.

** I don't know any people working there.

** I couldn't even find the place without navigation software.

** Just because it's from the Whonix project, doesn't mean server
security magically is a lot better than server security of let's say,
facebook. (And these are even known to have a front- and backdoor.)

* Regarding the server, it's easy to demand better security. Easy to
demand, that I pay for it rather than using a sponsored server, or to
demand other security enhancements. I'd be happy to do all of this,
but then please also provide reliable funding for it.

* We have a wiki page dedicated explaining all the attack vectors that
are related to the risks introduced since we are forced to trust
humans. [1]

* Whonix, same as Qubes, operates already on the assumption that the
infrastructure is compromised.

** The wiki page has a chapter "Should I Trust This Website?". [2] The
short answer is "no".

** Similarly the Qubes project has a chapter "What does it mean to
“distrust the infrastructure”?" [3]

** If a server administrator (such as mig5) were compelled to replace
an Whonix download, the OpenPGP verification of the file (iso, ova or
libvirt image) would fail (when using the project OpenPGP signing key
for OpenPGP signature verification).

** If a server administrator was compelled to also replace the OpenPGP
signature of that file, all the usual rules would apply: users should
verify the validity of the OpenPGP key by looking for it published in
different places, etc. The same advice provided by the Qubes project
for their isos.

** The Whonix server doesn't host the source code. A server
administrator cannot "insert code" into the Whonix project.

** Github is an organization with many Australian engineers. The same
threat applies there - perhaps even more so, in that Australian
engineers could be coerced into modifying git repository data directly
- - not just of Whonix, but Qubes too - and be unable to even tell their
boss.

** In such a situation, the threat of coercion or interference is
indeed real. The protection against that, seems to be all the usual
things: cryptography, ‘many eyes’, etc.

** The same argument could be made against developers, server
administrator or similar from USA and perhaps other countries as well?

** UK has Investigatory Powers Act, similar?

** Tor Project might have Australian developers and/or server
administrators, too? The point is that if you go down that road, there
really is no end. Whonix not special in this regard.

* As bad as that new law might be, I don't see that anything relevant
changed.

** Whatever circumstances do apply to @mig5 now, might have applied to
@mig5 before that new law as well.

** Even without that law directly applying to me, and while I've never
been in any territory of the USA, and while their laws may formally
not apply worldwide, yet USA laws are enforced worldwide. And as a
non-USA citizen even outside of USA, legal defense is even more
difficult than for USA citizen inside USA.

* What I witnessed over time is, that many users assume that security
focused projects are already very mature in all aspects and nothing
much needs to be done. This assumption is wrong.

** We don't have reproducible / deterministic builds; we don't have
automatic verification of deterministic builds; our repositories
aren't using multisig.

** We could use more code reviewers, auditors, unit tests, automated
tests, and whatnot.

** We don't have a volunteer server admin. [6]

** port Whonix package build process to Qubes package build process [7]

** See also our FAQ entry "Is the Linux User Experience Comparable to
Commercial Operating Systems?" [4]

** I'd like to tackle all of these issues.

* I am not really eager to build Whonix packages, Non-Qubes-Whonix
downloads, maintain whonix.org server, hold Whonix signing keys.

** Fun: development, source code, testing, design, answering good
questions

** Not 

[qubes-users] How to get qubes-users ml archive

['u1...@elude.in' via qubes-users]

Tutanota interface can't display messages by thread and this was driving
me crazy when reading mailing list messages so I switched to elude.in
which seems to work like a charm:

* clearnet and darknet address
* IMAP/POP and SMTP support
* works perfectly in Qubes Whonix with Thunderdird + TorBirdy (latest
version)

Super!

I was reluctant to switch because I didn't want to lose some of the
downloaded messages to which I want to reply.

Then I realized a way to import the qubes-users mailing list archive and
I'm here to share.

https://www.mail-archive.com/qubes-users@googlegroups.com/ and Google
Groups don't have a neat way to export the archive but this cool bash
script does the trick.
https://git.scuttlebot.io/%25nkOkiGF0Dd321GmNqs6aW%2BWHaH9Uunq4m8dVfJuU%2Bps%3D.sha256


Usage:

mkdir qubes-users-messages
ggscrape qubes-users download qubes-users-messages

The download process is long but goes smoothly.

Once the messages are downloaded they can be imported in a Thunderbid
folder with the addon ImportExportTools v.3.3.2

https://freeshell.de/~kaosmos/importexporttools-en.html

(download link at the bottom of the page)


I've noticed that, because of Google spam-protection, the original
sender address of each message is masqueraded but I don't think this is
an issue when replying.

-- 
1900

GPG public key:
https://pgpkeys.urown.net/pks/lookup?op=get=0x13EB9494632EF12B

Reddit:
https://www.reddit.com/user/19hundreds

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e9ddda66-832a-bfa0-2b1b-981c7c5e2edb%40elude.in.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature