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

[cooloutac]

I read that whonix thread.  Still not sure why whonix doesn't have a canary.  
What could it hurt?  Any aspect of the project could be compromised for any 
reason.   Thats the same as people saying I have nothing to hide so why worry.  
In the other thread Patrick says US laws affect all countries.

And don't feel bad.  Patrick banned me from the forums too once a long while 
ago.  I told him I'd never post there again and never did. lol.

I was constantly having issues with whonix.   You are a target just for using 
it.  You really have to pay attention when you are updating it.

Sill never understood why the user qubes-whonix left the project in flamboyant 
fashion claiming it was just a "cool experiment" and its "security was not 
taken seriously" ...

I stopped using whonix after the annoying clock issue.  And then couldn't be 
troubled to install the latest version and just removed it instead. 

I'm sure it has its purposes and some people need it.  But I don't.  The 
websites I use qubes for ban tor or it just has no benefit.  Anonymity is 
different then privacy.

-- 
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/db18e185-a602-4b05-8111-0cae75355cdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[cooloutac]

I stopped using whonix a while ago.   I wasn't huge on tor to begin with.  I 
was more in line with how Joanna originally felt about it.The only time I 
used tor was to check security certificates.  Then after the issue that 
happened a year or two ago started using it as updatevm.   But whonix kept 
giving me so many problems,  is so darn slow,   and was constantly feeling 
sketchy to me I stopped using it after the latest issues with clock, and then 
the latest version I didn't even bother troubling with. 

I'm sure it has valid use cases but personally for me I have no need for it.  
Most sites I go to on the computer I don't need tor or tor is not even allowed. 
  And I still feel anonymity and privacy are two diff things.

-- 
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/285461a6-d787-427e-bcbe-e005cdf306b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[unman]

On Sun, Feb 17, 2019 at 08:50:01PM +0100, r...@posteo.net wrote:
> On 2/17/19 10:49 PM, jrsmi...@gmail.com wrote:
> > Reading through the post questioning the trustworthiness of Whonix, I can't 
> > tell whether we can continue trusting/using Whonix or not.  Can someone 
> > (preferably in a position to speak for QubesOS), please state, in a 
> > straightforward and unambiguous manner, spell this out for us?
> 
> Personally, I don't trust Whonix. The decision to not trust Whonix is
> not based on the sysadmin/aussie issue that came up recently on the
> list. I'm simply not convinced that they are capable of designing and
> writing secure software. Furthermore, there is no reason to use whonix
> in the first place, especially when you are using Qubes. Creating a tor
> netvm is rather straight forward (and a dispvm that includes the Tor
> Browser if you like to use that as well). If there is enough interest, I
> can also write up a summary on how to do that in Qubes.
> 
> Regards

Have you looked at the qubes-tor package and www.qubes-os.org/doc/torvm?
- that page is removed from the menu but still available.
The qubes-tor package is OK but with some tweaking makes a solid
replacement for Whonix gw - certainly for live images and machines with
limited RAM.
imo the decision to deprecate that package and then remove all reference
to it from the docs was a mistake.

unman

-- 
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/20190220021241.ormtmw7yzgwiwmre%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup of files in a qube without networking to an internet service

[unman]

On Tue, Feb 19, 2019 at 03:41:23PM +, lik...@gmx.de wrote:
> Hi,
> 
> assume there are files stored in a qube without networking. Furthermore 
> assume there's a secured backup server located in the internet. This server 
> is only a storage of client-side (before data is sent over the wire) 
> encrypted files.  What options do you imagine to backup those files (skip the 
> client-side encryption) to the server?
> 
> I can imagine the following options:
> 1. enable temporary the network with firewall restricted to the server for  
> the (previously offline) qube
>  Advantage: no inter-vm copying of files.
>     Disadvantage: firewall rules must be setup correctly to avoid to bypass 
> any other traffic like icmp/dns etc. I can imaging a potential information 
> leakage due to enabling network access.
> 2. copy files temporary to another qube (dvm?) with a firewalled internet 
> connection
>     Advantage: files not being backed up can stay secured in the non-network 
> cube. Leakage of data is reduced in comparison to 1.
>     Disadvantage: can take time and needs additional disk ressources
> 
> I've learned that you should always find at least 3 options, otherwise you 
> haven't thought hard enough. Which options am I missing?
> 
> Which option would you prefer and why?
> 
> Best, Pete

3. Create encrypted (compressed) backup in offline qube.
qvm-copy backup to online disposableVM.
Copy encrypted file to backup server.

Advantage: All files secured in non-network qube.
Disadvantage: ???

Is inter-vm copying of files really an issue? Free space such an issue?
Using compressed backups should help mitigate this as a serious issue,
but that problem would extend to *all* your Qubes use.

unman

-- 
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/20190220004623.q5vg6vwzhg3r5fv6%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

['awokd' via qubes-users]

r...@posteo.net wrote on 2/19/19 11:49 PM:


Clock synchronization over Tor is not rocket science and pretty much
straight forward.


True, but do the clocks in your client AppVMs differ from each other and 
your main system's time? If not, they can possibly be correlated. 
Rolling your own solution is great if you are comfortable with that, but 
I think it's a bit reckless to suggest as a blanket approach to people 
who may not be aware of the consequences. Agreed, YMMV!


--
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/1d204f0d-d4b1-e440-b174-86d9434fa37a%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[r...@posteo.net]

On 2/19/19 6:45 PM, 'awokd' via qubes-users wrote:
> ashleybrown...@tutanota.com wrote on 2/19/19 4:05 PM:
>>
>>
>>> Creating a tor
>>> netvm is rather straight forward (and a dispvm that includes the Tor
>>> Browser if you like to use that as well). If there is enough interest, I
>>> can also write up a summary on how to do that in Qubes.
> 
>>
>> Please, it would be greatly appreciated. Especially on how to ensure
>> no clear traffic happens and that it only goes over tor.
> 
> What you're describing is one of the primary goals of Whonix. 

Right. I have no trust in their capability to design and write secure
software nonetheless.


> They have
> also done a lot of work around anonymizing applications and time sync,
> which I doubt the procedure above will cover. Unless you know and are
> prepared to address the possible anonymity compromising details of the
> individual applications and distribution you are planning on using (see
> https://phabricator.whonix.org/maniphest/query/all/ for ones they've
> considered), it's likely safer to stick with Whonix. See also
> http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Trust
> for a longer discussion on Whonix and trust.

Clock synchronization over Tor is not rocket science and pretty much
straight forward. Furthermore, if you need to ensure that separate Tor
paths are used for particular applications, you can either simply use
separate Tor netvms or depend on handcrafted, error prone circuit
isolation in Whonix. I'd prefer the former, simpler option but YMMV.

Regards

-- 
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/5e965953-a746-642d-3834-3579243ed7e9%40posteo.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] QSB #47: Insecure default DisposableVM networking configuration

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #47:
Insecure default DisposableVM networking configuration.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #47 in the qubes-secpack:



Learn about the qubes-secpack, including how to obtain, verify, and read it:



View all past QSBs:



```

 ---===[ Qubes Security Bulletin #47 ]===---

 2019-02-19

Insecure default DisposableVM networking configuration

Summary


In Qubes OS, one can attempt to limit the network access of a qube by
either completely disconnecting it from any NetVM or by setting its
firewall rules to disallow access. A malicious qube can circumvent these
limits by launching a DisposableVM [1], which, in the default
configuration, would have unrestricted network access.

Moreover, even when a non-default DisposableVM is configured to have no
network access (or limited access), other DisposableVMs started from
_that_ DisposableVM can have full network access (unless explicitly
configured otherwise).

While limiting network access in this manner should not be considered to
be an effective leak-prevention mechanism [1], we still consider this
type of potentially ineffective network isolation to be a problem.

Details


In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the
`template_for_dispvm` property set to "True". The DisposableVM inherits
all of its settings from the DVM Template, including the `netvm`
property and firewall rules. Neither the network settings nor any other
settings of the calling qube are considered. This design is intentional,
as it allows much more flexibility over the previous model. For example,
one could create different DVM Templates for different purposes, such as
opening links (internet access), viewing documents (offline), printing
(drivers installed), etc. Each DVM Template has appropriate network
settings for its purpose.

The important part of this design is the `default_dispvm` qube property.
The value of this property is the DVM Template that will be used when
starting new DisposableVMs from that qube. In the default configuration,
Qubes OS has one default DVM Template, which has unrestricted network
access. The default DVM Template is the default value of the global
`default_dispvm` property, which is accessible via "Global settings" in
the Qube Manager or via the `qubes-prefs` tool. This global property
serves as the default value for the `default_dispvm` property for every
qube. If the user creates a non-default DVM Template with limited
network access, the user must also set the `default_dispvm` value
(either globally or on a per-qube basis) in order for any new
DisposableVM to be based on this non-default DVM Template.

In the Whonix configuration shipped with Qubes, this issue is avoided by
creating a separate DVM Template that uses the Whonix Gateway
(`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM
Template is set to itself. This DVM Template is the value of the
`default_dispvm` property for every Whonix Workstation.

This problem is partially mitigated when restoring a backup from Qubes
3.2. For each qube that has the `dispvm_netvm` property set to "none", a
separate DVM Template named `disp-no-netvm` is created. This DVM
Template has no direct network access. However, this DVM Template itself
has the default value for its own `default_dispvm` property, so
DisposableVMs started from it or from DisposableVMs based on it would
have full network access.

Vulnerable systems
==

This issue affects only Qubes 4.0. In Qubes 3.2, the network settings of
DisposableVM are inherited from the calling qube's settings (more
specifically, from its `dispvm_netvm` property, which defaults to the
`netvm` property's value).

The Whonix configuration shipped with Qubes 4.0 is not affected by this
issue. If you have installed Whonix using a method other than the
recommended `qubesctl` command [4], you should review the settings of
your Whonix qubes. Specifically:

 - whonix-ws-14-dvm should have `netvm` set to sys-whonix
 - whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm
 - anon-whonix and any other Whonix Workstations should have
   `default_dispvm` set to whonix-ws-14-dvm

See the Whonix documentation [4] for details.

Systems in which the default DVM Template is disconnected from the
network (by settings its `netvm` property to "none") are not affected by
this issue.

Resolution
==

To mitigate this problem, we are implementing two changes:

1. When a DisposableVM is started, automatically set its
   `default_dispvm` to the

Re: [qubes-users] [Qubes-R4.0.1-x86_64] installation issue: unable to mount live-rw

['awokd' via qubes-users]

'awokd' via qubes-users wrote on 2/19/19 10:15 PM:

Matthias Kolja Miehl wrote on 2/19/19 7:27 PM:

On 02/18/2019 09:59 PM, 'awokd' via qubes-users wrote:

Matthias Kolja Miehl wrote on 2/18/19 8:47 PM:

[   11.036716] localhost dracut-mount[849]: mount: wrong fs type, bad
option, bad superblock on /dev/mapper/live-rw,




I set up a new partition table (msdos) with gparted for the USB stick
and then copied the iso:



After this change I get the same 'live-rw' mount error.


You shouldn't have to create a partition table since dd will copy a new 
one over, but either way sounds like this wasn't it. Other suggestions 
(I suspect you may have already tried some of these):


- Try toggling USB boot to legacy or EFI in UEFI config
- Burn Qubes to a physical DVD and use that to boot instead if possible
- Look for clues in earlier messages from rdsosreport.txt


Another one:
- Verify hash on your downloaded ISO


--
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/91e8bb63-02d4-bff0-0e93-e3746e4a7988%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [Qubes-R4.0.1-x86_64] installation issue: unable to mount live-rw

['awokd' via qubes-users]

Matthias Kolja Miehl wrote on 2/19/19 7:27 PM:

On 02/18/2019 09:59 PM, 'awokd' via qubes-users wrote:

Matthias Kolja Miehl wrote on 2/18/19 8:47 PM:

[   11.036716] localhost dracut-mount[849]: mount: wrong fs type, bad
option, bad superblock on /dev/mapper/live-rw,




I set up a new partition table (msdos) with gparted for the USB stick
and then copied the iso:



After this change I get the same 'live-rw' mount error.


You shouldn't have to create a partition table since dd will copy a new 
one over, but either way sounds like this wasn't it. Other suggestions 
(I suspect you may have already tried some of these):


- Try toggling USB boot to legacy or EFI in UEFI config
- Burn Qubes to a physical DVD and use that to boot instead if possible
- Look for clues in earlier messages from rdsosreport.txt

--
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/c377a3d3-7310-3371-6476-da19222d20f6%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

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

[mig5]

Hi,

I'm the 'mig5' referred to in the original post.

A couple things keep appearing in this and the other thread that need 
debunking. 

Constant reference to 'the dev', 'dev handing over keys', etc.

I'm not a dev on the Whonix project.

Patrick already covered this in his reply - really all that needed to be said, 
but seems people didn't read it.

Here are again some concise points:

1) The Whonix server doesn't host the source code. That's at Github. I have no 
access to it. I, myself, have as much chance of adding a backdoor to the Whonix 
source code, as the original poster - the same chance we both have at sneaking 
a backdoor into the Linux kernel upstream. As Australians say: 'bugger all!'.

2) There are no signing keys, or master keys, stored on the server. I can't 
'hand over' the keys used to sign the Whonix binaries, apt packages etc. I 
simply don't have them.

3) Packages are not built or signed on the server. This happens somewhere else 
with no involvement from me, and then those are uploaded to the (already 
assumed compromised) server.

4) Therefore, the only threat is the ability to tamper with the binaries/apt 
packages once they're uploaded - both of which would immediately compromise the 
cryptographic verification. You *do* verify your binaries against the 
signature, check that the signing/master key has been published in different 
places, etc, right? It's the same instructions Qubes, and other projects like 
Tor, Tails, Debian, provide.


5) **The threat of tampering with the binaries, doesn't require a sysadmin, let 
alone an Australian one**. Anyone hacking the Whonix website/wiki/forum, or 
something in Linux itself (remember attacks like Shellshock etc), or someone 
with physical access to the server (which I don't have), would result in the 
same compromise. This was already the case, and is the same risk affecting all 
upstream components you rely on when you run Whonix: (Debian infrastructure, 
Tor Project infrastructure, Github Mozilla infrastructure for TB's Firefox 
base, Qubes if you use it with Whonix, etc).

I trust the OP has sent equivalent emails to all the above, as well as the 
hardware providers/firmware developers of the device they use, because if 
you've decided you need to trust the Whonix infrastructure, you need to also 
trust all the above too (at all times, since forever, and forever more), 
otherwise it's a moot point.

To reiterate:

1) the ways in which the server could already be compromised, don't even 
require the sysadmin, regardless of their nationality. Assume it's already 
compromised (as Qubes says about their own infrastructure)
2) tampering with the binaries/apt packages would be evident by them no longer 
verifying properly, cryptographically - the same defense that all projects, 
including Qubes, rely on.
3) the sysadmin can't modify the source code and has no access to signing or 
master keys

> honest risk assessment of the new situation in Australia (it is new, simply 
> is) needs to be done correctly

Done, see above.

I greatly appreciate the OP's concern, if genuine. It's a dreadful law and I 
hope it's repealed. I think it's great that people want to discuss it - more of 
that needs to happen. Especially in Australia.

But the OP looks to have made a critical error in assuming (without merely 
asking first) that one of the above points is not the case. Further confusion 
has persisted about 'the dev' when in fact the sysadmin is not a Whonix dev. 
These are wrong assumptions. There is no new threat that didn't already exist, 
and that doesn't even require a sysadmin to carry out.

Cheers
Mig

-- 
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/0ad2b18b-ce3c-ced7-14ef-4df245fa04cb%40mig5.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Re: No audio problem in Qubes 4

[Jon deps]

On 2/8/19 10:35 AM, Shahin Azad wrote:

Hi,

After a fresh install on this device, I hear no sound from neither speakers nor 
headphones. Pulse audio volume control (on dom0) has correctly selected the 
audio card, and blue line indicators, already are showing the sound signals. 
But I hear no sound of the speakers. The software I use to test the audio are 
Firefox and VLC from the Fedora 29 template. I also tried the Debian 9 
template, and the problem remains.

Also, the microphone input indicators shows that the microphone successfully 
receives the signals.




.sure this is obvious but of course the  Template  have no internet 
connection by default,  perhaps you  changed the netvm  to sys-firewall 
as you do see   an internet  stream or   probably best to test it in a 
connected AppVM "qube"


--
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/4156c053-7620-6f2d-fc89-be9a0c96a0dc%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes: Unable to connect to VPN

[Jon deps]

On 2/14/19 5:55 PM, Otto Kratik wrote:

Just reviving a thread of mine from a few months ago with a related follow-up 
question.

When trying to connect to a VPN using openvpn from a Debian-9 AppVM within 
Qubes, I could connect but instantly lost DNS resolution which rendered the 
connection unusable.

Installing he package 'resolvconf' and adding the following lines to the .ovpn 
script supplied by the VPN provider:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


...solved the issue and I was able to achieve full connectivity through the VPN.


Now, when trying to *disconnect* from that VPN using Ctrl-C from command line 
(or any other method) I am able to end the connection, but the DNS assignment 
does not appear to automatically reverse/undo and revert to the default
DNS servers provided by sys-net within Qubes, namely 10.139.1.1/2. And as a 
result I once again cannot connect to any websites due to lack of functioning 
DNS lookup.

Having done a bit of research I've tried using commands like:

sudo ifconfig tun0 down
sudo ip link delete tun0


..but in both cases I get a response that 'tun0 does not exist' or something 
similar.

Is there any extra step needed to completely drop the VPN connection and revert 
to using normal sys-net connectivity, without requiring a restart of the AppVM 
itself?

If I manually examine /etc/resolv.conf within the AppVM it still shows the 
default sys-net DNS entries as expected, so there must be some additional
command needed to fully end the connection and revert to normal.

What am I missing?



https://www.qubes-os.org/doc/vpn/

I believe it would be helpful  if you indicate  which method  you have 
used to create the VPNper the URL  there 



perhaps it is more obvious to 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/37bfa956-5206-a16f-1689-1321d4e78bec%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [Qubes-R4.0.1-x86_64] installation issue: unable to mount live-rw

[Matthias Kolja Miehl]

Hello awokd,

thank you for your help!

Unfortunately, the suggested changes did not solve the issue or change
the error that is displayed.


On 02/18/2019 09:59 PM, 'awokd' via qubes-users wrote:
> Matthias Kolja Miehl wrote on 2/18/19 8:47 PM:
>> [   11.036716] localhost dracut-mount[849]: mount: wrong fs type, bad
>> option, bad superblock on /dev/mapper/live-rw,
> 
> https://github.com/QubesOS/qubes-issues/issues/2744#issuecomment-336635241
> suggests multiple installation images. Can you delete all partitions
> from the USB drive and dd it again?

I set up a new partition table (msdos) with gparted for the USB stick
and then copied the iso:
--
# dd if=Qubes-R4.0.1-x86_64.iso of=/dev/sde && sync
9166848+0 records in
9166848+0 records out
4693426176 bytes (4.7 GB) copied, 1188.31 s, 3.9 MB/s
--

The result:
--
$ lsblk
[...]
sde8:64   1  58.9G  1 disk
├─sde1 8:65   1   4.4G  1 part
└─sde2 8:66   1  27.7M  1 part
--
$ gparted
/dev/sde iso9660 Qubes-R4.0.1-x86_64 size:58.88GiB
/dev/sde2 fat16 ANACONDA size:27.71MiB
--

After this change I get the same 'live-rw' mount error.


>> My laptop's internal SSD has a GPT and an empty unformated primary
>> partition that covers the whole disk.
> 
> Delete this partition too.

I set up a new partition table (GPT) and no partitions for the SSD with
gparted. This change in combination with the above resulted in the same
'live-rw' mount error.


>> 0.00] Secure boot could not be determined
> 
> Make sure it is disabled in UEFI config.

I verified that Secure Boot has been disabled in the BIOS during all my
attempts. I found it under "Security -> Secure Boot".

I am currently going through the BIOS to check whether there are any
other settings that might cause the issue.


Thanks a lot for your time :)
Matthias

-- 
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/f795c62a-a3df-ae2f-1658-adfad015a699%40w3hs.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to install usb-keyboard in 4.0

['awokd' via qubes-users]

scoobyscra...@gmail.com wrote on 2/18/19 11:49 PM:

I have a sys-net qube which was created during the installation.

I get the same error when I try to create a USB qube:
sudo qubesctl state.sls qvm.sys-usb

Wish those salt commands would give more detailed error messages. Not 
sure what else to suggest. Maybe search the Qubes issues out there to 
see if anyone else has encountered the same thing, and file a new one if 
not?


--
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/f281dc63-b588-9b01-9555-4fa163ed0128%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] backup of files in a qube without networking to an internet service

[Chris Laprise]

On 2/19/19 10:41 AM, lik...@gmx.de wrote:

Hi,

assume there are files stored in a qube without networking. Furthermore 
assume there's a secured backup server located in the internet. This 
server is only a storage of client-side (before data is sent over the 
wire) encrypted files.  What options do you imagine to backup those 
files (skip the client-side encryption) to the server?


I can imagine the following options:
1. enable temporary the network with firewall restricted to the server 
for  the (previously offline) qube

  Advantage: no inter-vm copying of files.
     Disadvantage: firewall rules must be setup correctly to avoid to 
bypass any other traffic like icmp/dns etc. I can imaging a potential 
information leakage due to enabling network access.
2. copy files temporary to another qube (dvm?) with a firewalled 
internet connection
     Advantage: files not being backed up can stay secured in the 
non-network cube. Leakage of data is reduced in comparison to 1.

     Disadvantage: can take time and needs additional disk ressources

I've learned that you should always find at least 3 options, otherwise 
you haven't thought hard enough. Which options am I missing?


Which option would you prefer and why?


Another disadvantage of #1 is that connecting the net to the source qube 
exposes it to attack.


Had you thought about using qvm-backup? Also, I'm working on a fast 
incremental backup tool that's suitable for Qubes:


https://github.com/tasket/sparsebak

--

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/cfdd9ce7-b95b-f26a-5cf9-19e0df29d70d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

['awokd' via qubes-users]

ashleybrown...@tutanota.com wrote on 2/19/19 4:05 PM:




Creating a tor
netvm is rather straight forward (and a dispvm that includes the Tor
Browser if you like to use that as well). If there is enough interest, I
can also write up a summary on how to do that in Qubes.




Please, it would be greatly appreciated. Especially on how to ensure no clear 
traffic happens and that it only goes over tor.


What you're describing is one of the primary goals of Whonix. They have 
also done a lot of work around anonymizing applications and time sync, 
which I doubt the procedure above will cover. Unless you know and are 
prepared to address the possible anonymity compromising details of the 
individual applications and distribution you are planning on using (see 
https://phabricator.whonix.org/maniphest/query/all/ for ones they've 
considered), it's likely safer to stick with Whonix. See also 
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Trust 
for a longer discussion on Whonix and trust.


--
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/369d71c9-d570-b5cc-bb3d-9a0e5e5006fa%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[ashleybrown480]

> Personally, I don't trust Whonix. The decision to not trust Whonix is
> not based on the sysadmin/aussie issue that came up recently on the
> list. I'm simply not convinced that they are capable of designing and
> writing secure software. Furthermore, there is no reason to use whonix
> in the first place, especially when you are using Qubes. Creating a tor
> netvm is rather straight forward (and a dispvm that includes the Tor
> Browser if you like to use that as well). If there is enough interest, I
> can also write up a summary on how to do that in Qubes.
>
> Regards
>

Please, it would be greatly appreciated. Especially on how to ensure no clear 
traffic happens and that it only goes over tor.

-- 
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/LZ5VKmW--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] backup of files in a qube without networking to an internet service

[liked2]

Hi,

assume there are files stored in a qube without networking. Furthermore assume 
there's a secured backup server located in the internet. This server is only a 
storage of client-side (before data is sent over the wire) encrypted files.  
What options do you imagine to backup those files (skip the client-side 
encryption) to the server?

I can imagine the following options:
1. enable temporary the network with firewall restricted to the server for  the 
(previously offline) qube
 Advantage: no inter-vm copying of files.
    Disadvantage: firewall rules must be setup correctly to avoid to bypass any 
other traffic like icmp/dns etc. I can imaging a potential information leakage 
due to enabling network access.
2. copy files temporary to another qube (dvm?) with a firewalled internet 
connection
    Advantage: files not being backed up can stay secured in the non-network 
cube. Leakage of data is reduced in comparison to 1.
    Disadvantage: can take time and needs additional disk ressources

I've learned that you should always find at least 3 options, otherwise you 
haven't thought hard enough. Which options am I missing?

Which option would you prefer and why?

Best, Pete

--
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/46bf7e50-3cdf-cfe5-8986-e77a3c4e0bb8%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

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

[qubes-fan]

Feb 16, 2019, 4:08 AM by xa...@protonmail.com:

>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, February 15, 2019 10:58 PM, <> qubes-...@tutanota.com 
> > > 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?)
>

I am not talking about magical 100% protection or 10$-wrench-decryption. I 
believe this attack is different by its implications and consequences. Sure 
many govs using different methods today, many of which are but un-lawfull. 
Doing this can ruin any case be it getting to the court. By having these laws 
in place, like the ones in Australia, this attack yesterday unlawful, is lawful 
today. This has high consequences. To ruin any project today it is enough that 
they come and ask you for your keys, or ask to plant a backdoor. If not, you go 
to jail. Project is over, perfectly fit with law. Yesterday it wasn't possible 
so simply, they had to be on border with or cross the law, considering morality 
of the dev constant.


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

As an example, if developer is anonymous, one can point gun at his own head 
only. This should be part of the thread model, mitigations and contingency 
plans. You are again trying to find 100% solution for everything, and if not 
available, you call it impossible situation. It is possible situation and must 
be analyzed separately from other threads with different characteristics.


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

Re: [qubes-users] Preparation for a Qubes Installation: Custom Disk encryption?

[Johannes Graumann]

On Tue, 2019-02-12 at 08:08 -0500, Chris Laprise wrote:
> On 2/12/19 4:40 AM, Johannes Graumann wrote:
> > Gentlepeople,
> > 
> > After playing with it on a secondary machine, I'm looking to
> > transition
> > from my Arch-setup to Qubes.
> > 
> > I am traditionally choosing to encrypt my file systems using
> > serpent
> > (considered the strongest entry into the AES competition with
> > slightly
> > worse speed than the finally choosen Rijndael algorithm) and the
> > following partitioning:
> > - UEFI-required EFI System Partition, 512MB, EFI System
> > - /boot partition (to be encrypted), 512MB, Linux filesystem
> > - SWAP partition (to be encrypted using a random key), size of RAM
> > (`free -m`) + 1 MiB, Linux filesystem
> > - tmp partition (to be encrypted using a random key), 2GB, Linux
> > filesystem
> > 
> > All but the UEFI partition are being encrypted. '/boot' uses a
> > keyfile
> > resident in '/' (appropriate grub configuration) and thus PW-
> > protectded
> > through the encryption of '/'.
> 
> FWIW, if you switch to legacy BIOS boot and your system has a TPM
> you 
> may be able to use the Qubes anti-evil-maid package to guard against 
> firmware & boot tampering. Most Qubes users don't seem to opt for
> it, 
> but I thought you might be interested in the extra security.
> 
> > Questions:
> > 1) Does that make sense (for Qubes)?
> 
> On this topic, the sensibility of encryption options with Qubes is
> about 
> the same as for regular Linux distros. Personally, I don't think 
> switching away from AES is necessary.
> 
> > 2) Am I missing something necessary?
> > 3) Is there documentation on custom disk encryption and if no:
> > where in
> > the installation process would I break out (how) to the CLI to get
> > it
> > done?
> 
> Qubes uses the RHEL/Fedora installation tool called 'anaconda' which
> is 
> documented on the Red Hat and Fedora sites. I don't recall if the 
> anaconda UI lets you specify the cipher, but the 'kickstart' feature 
> does so that might be an option.
> 
> Also note that a non-AES cipher may seem nearly as quick as AES for 
> access times, however it will have an impact on multitasking
> performance 
> since AES is hardware accelerated while the other ciphers are not on 
> most systems.

So after I was pointed by @ADW at 
https://www.qubes-os.org/doc/custom-install/, I'm well set up to tackle
any customization - I'm aware of the hardware acceleration generally
baked in for AES algorithms. Yet the question remains whether swap and
especially tmp partitions make sense from a Qubes-perspective. I assume
that given the RAM management necessary, swap for dom0 may be quite
sensible (is RAM+ 1MB an appropriate size?), but how about tmp? I
realize that the my use case, where I traditionally have browsers etc.
use it as a download directory  that's automatically purged upon
machine shutdown does not make a whole lot of sense for dom0. Is there
anything Qubes-specific to keep in mind when deciding on whether a
separate tmp partition is adding security?

Sincerely, Joh



-- 
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/149dec4d462623703ef5549406c0826f5b79ed13.camel%40graumannschaft.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[nosugarmaxtaste]

Hi Alex,

Let me just start by saying a massive thank you. This guide has been great. I 
have used it for the 8.1 - Oreo - which was just changing:
 'repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
android-x86-7.1-r2' to 'repo init -u 
git://git.osdn.net/gitroot/android-x86/manifest -b oreo-x86.'

With 8.1, mouse support comes out the box and completing the last part of the 
guide actually makes the mouse worse in Oreo. So, disregard that part anyone 
following this guide for 8.1. You can change resolution by affixing 'vga=ask' 
and choosing your desired resolution 
(https://groups.google.com/forum/#!topic/qubes-users/KZm8aGJuiO0).

I have come across one issue, and I am wondering if you could help me. Android 
has installed great, and loads up fine. However, I simply cannot open the 
Settings app, as it crashes every single time. Others who have encountered this 
issue modified it using adb 
(https://stackoverflow.com/questions/3480201/how-do-you-install-an-apk-file-in-the-android-emulator?rq=1),
 but I don't know how to do this with a Qubes HVM. Any help with this?

Thanks in advance :)

-- 
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/66b1a620-8d3a-49b9-aa96-6294d81145cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] openvpn issues

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/19/19 6:26 AM, haaber wrote:
> I set up a new debian AppVM, checked "provides network", and
> installed network-manager, and network-manager-openvpn-gnome.  So
> far so good.

> ...it connects, and receives a large list "route add ..." which is
> strange to me. I don't find these IP adresses anywhere in the
> config files ; they seem to be imposed remotely (?).
Yes, routes can be pushed from the remote server.

> Anyways, I can ping those, but no others (e.g.  no 8.8.8.8). Bad. 
> Any ideas on that?

Remote server can push a default route too.
In this case all* traffic will go that way.

*Except qubes specific DNS resolution

You can ignore the pushed routes, by modifying the openvpn config:
IPv4->Routes


- -- 
Zrubi
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxrxMsACgkQVjGlenYH
FQ1yqBAAkaKXtdh2fcfcuO4gmOY0lp3jH1so5LiaXG0QD5w89kX/179zAUzm4dAz
/l4KmtPxwbkyjaIZBYcI8biGZ/FqLPu+BqkG1EdDALIkOoMiZhU/A6yMITRNiEv5
Q50URnUb+qZlHIcVfWATVZ381D8nwDwFcfk2SVLB9xSZliwNMUw/2e8ysLgk1c+c
Nka0DM2Nwyp1YL1Jpi7UGJWAzOeFT0tVny7WWUmZmBdlLVRo1C/8S1eXPOCyyrc8
Ed8vvJ3C3dSZOHgCB7aFbO1WYjfEnaxNgG4OkBNcgv50ZwAXXi7jMrY/t7Ia2Apx
9fUfDejohvsVTI9o/PrEWQbjjyHgVNNbJ/2J0k5n6FRiwBGZTuq3ezDdyE5yed9g
9dSOCY4Zk0v8vmF/S0s2OAJC1n0cgTcI0A0OlNoS1rQTfWQHfyttVlMcSIGwvVNg
Ujf3BnmYdGxD16w66RD24Aml0xYoaeSr57HzBqttdyTYjSg39aoJRHK04MLK5StH
ycYSizgR0bX7afNv2v7wqMQd0tySZr0xAO9mPS/lSxMOr6Wj06FDDbpmNZPqQj46
E96g7CkJmBW69YUa3O/v6uNS+4vidsSz0Ef9o3L8YA8wgwZgvix3dsnI78dAar2f
Ay+IrwjoURiKmyj0mro/J+WhcWGkt14ligVPklpydbec3xYVt8Y=
=2axt
-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/1c7edaff-47ce-cdb8-11a8-60ce719d0778%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.