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

[ashleybrown480]

Feb 14, 2019, 3:42 PM by un...@thirdeyesecurity.org:

> On Thu, Feb 14, 2019 at 03:13:00PM +0100, > ashleybrown...@tutanota.com 
> >  wrote:
>
>>
>>
>> Hopefully one day they revert it back to how it was in 3.2. A very common 
>> use-case for the firewall is likely to ensure things like DNS requests do 
>> not happen through the normal means (and instead go over something like Tor 
>> or a VPN). Unfortunately, the current config does not make it very obvious 
>> that someone should block DNS ports. Making it very easy for someone to 
>> shoot themselves in the foot because the interface is not intuitive (it says 
>> it blocks all traffic other than what is specified and then later modifies 
>> this saying "just kidding, we let DNS through")
>>
>> Feb 14, 2019, 2:05 PM by >> ashleybrown...@tutanota.com 
>> >> :
>>
>> > > The magic is in NAT rules (but I had to research this too.) See > >> 
>> > > https://www.qubes-os.org/doc/networking 
>> > > >>  <>> 
>> > > https://www.qubes-os.org/doc/networking 
>> > > >> >> , and "sudo iptables -t 
>> > > nat -L" in sys-firewall and sys-net.
>> >
>> > I previously looked at IP tables and honestly I really do not understand 
>> > it. Can you please explain a little how it works?
>> >
>> > Here is what my nat look like in sys-firewall:
>> >
>> > Chain PR-QBS (1 references)
>> > target prot opt source   destination
>> > DNAT   udp  --  anywhere 10.139.1.1   udp 
>> > dpt:domain to:10.139.1.1
>> > DNAT   tcp  --  anywhere 10.139.1.1   tcp 
>> > dpt:domain to:10.139.1.1
>> > DNAT   udp  --  anywhere 10.139.1.2   udp 
>> > dpt:domain to:10.139.1.2
>> > DNAT   tcp  --  anywhere 10.139.1.2   tcp 
>> > dpt:domain to:10.139.1.2
>> >
>> > So, when I do ping google.com it needs to do a DNS request. Because my 
>> > AppVm /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to 
>> > send to 10.139.1.1. However, no VM on the network actually has this 
>> > address.
>> >
>> > Is that packet modified? I am assuming what happens is the packet is 
>> > forwarded to whoever the internet provider is (in this case sys-firewall). 
>> > Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the 
>> > DNS server.
>> >
>> > I am assuming the IP-Header of each hop is rewritten. So, for example, 
>> > sys-net will rewrite the IP header to be the external IP address for the 
>> > computer and thus it will receive a response to that IP. Assuming this is 
>> > correct how does the original AppVM get the correct response? I assume 
>> > multiple AppVMs are all forwarding these UDP dns requests through 
>> > sys-firewall and then sys-net. And then when sys-net gets a response how 
>> > does it know to send which response to which specific AppVM?
>> >
>> > -- 
>> > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
>> > >> https://tutanota.com >>  <>> https://tutanota.com 
>> > >> >> >
>> >
>> >
>> > Feb 14, 2019, 11:46 AM by > >> qubes-users@googlegroups.com 
>> > >>  > 
>> > qubes-users@googlegroups.com >> >> :
>> >
>> >> >> ashleybrown...@tutanota.com >>  
>> >> >> > ashleybrown...@tutanota.com 
>> >> >> >> >>>  wrote on 2/14/19 6:28 AM:
>> >>
>> >>> When I look at /etc/resolv.conf in the following VMs it says different 
>> >>> things:
>> >>>
>> >>> 1) Normal AppVM:
>> >>>
>> >>> nameserver 10.139.1.1
>> >>> nameserver 10.139.1.2
>> >>>
>> >>> 2) Sys-firewall VM:
>> >>>
>> >>> nameserver 10.139.1.1
>> >>> nameserver 10.139.1.2
>> >>>
>> >>> 3) Sys-net VM:
>> >>>
>> >>> [actual resolvers]
>> >>>
>> >>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
>> >>>
>> >>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That 
>> >>> is not the IP address for any VM on the network. This can  be verified 
>> >>> in Qubes Manager looking at the IP column. In addition, 10.139.1.1 
>> >>> refers to different VMs depending on the VM sending the packets. In 
>> >>> AppVM it routes to sys-firewall. In sys-firewall it routes to sys-net.
>> >>>
>> >>> So, my question is how does all of this work? Where exactly does any 
>> >>> request to 10.139.1.1 route to the actual connected VM. Looking at IP 
>> >>> table rules I do not see where traffic sent to 10.139.1.1 goes to 
>> >>> [sys-firewall IP here] for example. It appears to be doing it all 
>> >>> magically, so where is the magic?
>> >>>
>> >>
>> >> The magic is in NAT rules (but I had to research this too.) See >> >> 
>> >> https://www.qubes-os.org/doc/networking 
>> >> >>  <>> 
>>

Re: [qubes-users] Re: QSB #46: APT update mechanism vulnerability

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14/02/2019 1.27 PM, Vít Šesták wrote:
> On February 14, 2019 6:18:47 PM GMT+01:00, "Marek Marczykowski-Górecki" wrote:
>> On Thu, Feb 14, 2019 at 05:58:09PM +0100, Vít Šesták wrote:
>>> When I update dom0 and then Debian/Whonix without restarting the Qube
>> Manager or Update “widget”*, is it enough? Or I need to restart the
>> updater app (or maybe whole Qubes)?
>>
>> No, you need to restart it - just close its main window. Unlike 3.2,
>> there is no need for additional steps like right-clicking on Q->quit.
>> Similarly, closing updater gui is enough, even if "updates available"
>> icon/widget stays there (the updater gui is a separate process).
> 
> That sounds like something that informed users are able to do, but uninformed 
> users might feel no reason for doing so. It is (obviously) up to you, but I 
> suggest adding this information somewhere near downloads.
> 

PR submitted: https://github.com/QubesOS/qubes-doc/pull/790

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxmXssACgkQ203TvDlQ
MDAefg/+IaYYzdc4HOPT4H90cyzdCMJ6E4su5tv/3TNKhydYPaQcZzvBPhfpOgEu
IB13O41+WgW/nyGv/+S8BWZirmVZP004uY+fP6QnxFsKbWO3afZlNILh9VbNaGyE
U38GOy2umIb5DThMcShl2m8IAHO/OmjJw9Sw7m95vV7fYTNHrVQI1VUXnaQl6i+K
YA4lKBRkZTZdEUk65z4Nk287rylPXYqUD1MmIboUcqv+vHVi9A2nRXFU94WlgG5X
ILStvuaNkHAaG8cUDDX4nduk/xz12NGdEbx4L6NrD02QetWAY7deih5B3X7EvZ5E
BWVS/411LU+oyF9JnxIGgCU3ymzdQkzg2HBZt58X3YmteuqgzZQ0QBxyIhbZqD4K
l0FVRwbzKoLNEPC8EgYk3KrmujiecD86Mxjr4Md+QDj+TlabiK8Jwu7MnDuaudrK
VByKVFSmMX69PMQuMMWFlO662p3JfCKecE3Gi7tErow+BV23Nt7diR5ZYuiGVTvC
sji/p7+JVZEEhWokyVjMvrJ1mLd6EgCNMHfHIycrEcYz06Sz/DTpj+r01owYOrgg
tIP9UPYffwhsxnTljpak8j3tBKsFWIaJS7jxVPvPILpWuLNwE7IEkYBAPWzKKCz2
Zm5bbF1gp9FP+dxv60GrOIBeg4BabHDmtNnWB+qtL0jFZFpi8KM=
=4qP7
-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/484d2644-26d9-ebad-47e6-dc3c56e0102f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Purism Librem 13 v4

[Matt DeVillier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Purism Librem 13 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

wsFcBAEBCAAQBQJcZlzwCRAru3dqNbl4/QAAjsAQAMXVP36rZZ2Jbgb9oJ5Y
Ja2PJeCssGMYxPOg51vDQ0YoNFsaPyWs2nOflmWq3TlfHJiNl07JcjlTeQ3w
dyx3Zf/XBVFH7XYvp0Mqgb8pskMclt7FS4PoPzbxZ2YPvfdiMBcZpYvLrHUs
V2MoJTogvgphPA9+yoDuz9tkavWZpaJ6Xy5V9DU/lmI60izHUjaZPvCGjNmg
RTZZkfI+8ohZHv16BnHAfX1UTj3xGOQNBeJVktYMXJn0p+On4sCOpqkLh5Z+
E1oXDr9XTXUViLsy2VNEmDp56uOXnvoGjIAjK59kAqD3To39kRXi/G4+QVov
VvfRY98ruhoKKiR1512a20IWI8ewj9S1n+Zum9QFjvVMmKA4M6kssSisRzUr
CcdPn5b4OVtJ+n+7pp5XRTw8c4EAP2+0OOFr3iPNBSqgBqGmngh+OtbmDedi
ADIWspPxtKISh1v27HSypGRnGAFbloXsPuT4F47lfWEOgNVXO2+oL/u9AzCx
wK5nOsqPJE2cJZ11yT3ntFJEtecLYkz8Q+MA8Ii/WN3bmwsu2AVjjFrKpY4P
2JFhdtKEtihEwe8w4IdHvh0zYYdIxtvAr45bHhQoyfJ093sxq2DWEZV8S/kC
jPcDXqBi0D7WKacSXXAr87Pp5U0xKuF2Ph6aygqg+WiTKIhLqyk6jzNVkgOn
YTO+
=JSnm
-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/7097616c707ea8344716b77d54ee40ce%40puri.sm.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Purism-Librem_13_v4-20190215-001249.yml
Description: Binary data

Re: [qubes-users] Some VMs on an external disk (unavailable at boot)

[preilly40]

On 2/12/19 7:37 PM, preill...@gmail.com wrote:
> There was a page called this that I referred to. 
> https://www.qubes-os.org/secondary-storage

My mistake.  It's here:

https://www.qubes-os.org/doc/secondary-storage/


-- 
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/5ae65274-7f8f-f01b-abac-cdbec176f5f7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How secure is google-authenticator as 2FA?

[namemyname]

Hi Qubes fellows,On reading content on 2FA, something comfuse me, so I'd like 
to understand better by posting here:one type of OTP,a TOTP like google 
authenticator, bases on a shared secret key, since keycan be seen in mail box, 
it's not quite safe, is it saved in mail box as well?(does it also travel on 
internet? which makes it even worse?) a U2F software can do it's work without 
this app, so it doesn't look like a good choice.If this is the case, why so 
many web mail even some promising ones still chose google-authenticator as 
2FA?Although gmail itself can add yubikey as enhence for TOTP, I don't see how 
that's safer.because with or without press the yubikey button, an U2F software 
can generate same 6-digit-number as password to enter here. Today most of 
webmails would say they use 2FA, but not introduce in detailswhich protocol it 
uses. some claim it use yubikey, so is OTP here that use key pair instead of 
the shared secret key? which is much better.I don't find many webmail use Y
 ubikey as 2FA on OTP,if any of you find something is rather relaible,recommend 
very welcome, 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/201902122145.x1CLj2cr003976%40api2.scryptmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Some VMs on an external disk (unavailable at boot)

[preilly40]

On 2/4/19 4:42 PM, Chris Laprise wrote:
> On 2/4/19 4:12 PM, Stuart Perkins wrote:
>>
>>
>> On Mon, 4 Feb 2019 21:27:44 +0100
>> Stefan Schlott  wrote:
>>
>>> On 2/4/19 5:59 PM, Stuart Perkins wrote:
>>>
 I do not know the official stance or method, but I symbolically
 link from the standard appVM location to my other drive where I
 have the larger appVM's.  Mine is always available so I don't know
 if Qubes would boot if it weren't, but it is a thought...obviously
 the drive would need to be available to start the appVM's located
 thereon.
>>>
>>> This is what I did on Qubes 3.2. On Qubes 4.0, I used the new thin pool
>>> provisioning, so the symlink trick doesn't work anymore...
>>>
>>> Stefan.
>>>
>>>
>>
>> Ah, but if the path must be "provisioned" in order to boot qubes
>> itself, that sounds like a more difficult way to do it.
>>
>
> The workaround would be to have either A) installed Qubes with a
> regular filesystem (without thin LVM) or B) setup a secondary but
> "always available" non-LVM pool on your internal drive. Then symlinks
> can be used.
>
> @Stefan: Would you post this as a feature-request issue? If not, I may
> do so because having Qubes support removable storage pools
> automatically could be valuable to a lot of people.
>

Here are my notes on adding a 2nd disk to Qubes 4.  I think they
correctly document what I did, but it was several months ago.


There was a page called this that I referred to. 
https://www.qubes-os.org/secondary-storage

I don't see that page today.


sudo su -

cryptsetup luksFormat --hash=sha512 --key-size=512
--cipher=aes-xts-plain64 --verify-passphrase /dev/sdb

use blkid to see the new item


add it to  /etc/crypttab

reboot

pvcreate /dev/mapper/luks-c38b8e68-ce41-4474-81c9-226599812715

vgcreate qubes_data /dev/mapper/luks-c38b8e68-ce41-4474-81c9-226599812715

lvcreate -T -n qubes_disk2 -l +100%FREE qubes_data

qvm-pool --add pool_qubes_disk2 lvm_thin -o
volume_group=qubes_data,thin_pool=qubes_disk2,revisions_to_keep=2

# to create vm using this pool
qvm-create -P pool_qubes_disk2 --label blue data


-- 
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/ee88bf92-8b44-4b4e-ffe8-08f3274066f1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Laprise]

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

--
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/5e8f13b0-3ba9-f63c-fb50-974564024bfc%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0, app: Error creating VM

[borrisjonsnob]

On Friday, February 15, 2019 at 12:12:30 PM UTC+11, Borris Johnsnob wrote:
> When upgrading the Fedora 26 -> 28 template for Qubes 4.0 using the following 
> links:
> 
> 
> A. https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/
> 
> B. https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40
> 
> 
> When I got to step 8 in the detailed instructions of link 'A' I went on to 
> follow the steps in link 'B'.
> 
> 
> In the section 'How to switch templates (4.0)' step "3. Base the DVM template 
> on the new template". I get the following error:
> 
> 
> $qvm-create - l red -t fedora29 fedora29-template-dvm
> app: Error creating VM: Got empty response from qubesd. See journalctl in 
> dom0 for details.
> 
> 
> When run 'journalctl' I see the following:
> 
> 
> 
> dom0 qubesd[3049]: permission denied for call b'admin.vm.Create.AppVM' 
> +b'new-template' (b'dom0 -> b'dom0') with payload of 31 bytes
> 
> 
> Can anyone help me please?

Not an issue. I am an idiot. Typo, should have been:

fedora-29

Not:

fedora29

My apologies for wasting anyone's time.

-- 
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/b760d7da-8a87-40d4-85d5-902ffd7a7cf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Effectiveness of the VM compartimentation

[nosugarmaxtaste]

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?

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/a667-beb9-4879-8d06-879a510832a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Is it safe to install Qubes4 on laptop used windows10 before?

[nosugarmaxtaste]

When you format a HDD, whatever OS was on there previously is gone. Be it 
Windows, Qubes, or whatever. None of the windows phone home features will 
survive the format and you can happily install Qubes on the formated HDD. 

I really don't believe Microsoft is able to track your hardware, UUID, if 
you've installed Qubes. Nor would this effect your activities on Qubes anyway?

-- 
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/d228906b-1907-40de-81d7-74ceca04ab5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[nosugarmaxtaste]

'This law was only recently introduced and is already being used to great 
effect according to recent reports.'

Great effect? Where are your sources? I can't take you seriously without proper 
sources. Gut feelings, suspicions, it all means nothing without evidence. 
Should we all bust out the tin foil while we're here, too?

In what ways could Whonix be modified to pose a threat to us? They can't modify 
Tor, and any change they do to the OS is in clear visibility. How will they 
back door it? Any existing case examples?


-- 
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/26996f92-b6f5-4132-a3b3-3d3e6cd1f736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0, app: Error creating VM

[Borris Johnsnob]

When upgrading the Fedora 26 -> 28 template for Qubes 4.0 using the
following links:

A. https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/
B. https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40

When I got to step 8 in the detailed instructions of link 'A' I went on to
follow the steps in link 'B'.

In the section 'How to switch templates (4.0)' step "3. Base the DVM
template on the new template". I get the following error:

*$qvm-create - l red -t fedora29 fedora29-template-dvm*
*app: Error creating VM: Got empty response from qubesd. See journalctl in
dom0 for details.*

When run 'journalctl' I see the following:

*dom0 qubesd[3049]: permission denied for call
b'admin.vm.Create.AppVM' +b'new-template' (b'dom0 -> b'dom0') with payload
of 31 bytes*

Can anyone help me please?

-- 
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/CABtBE2FDB4ymR9F0AXhBOFRdCi%3DMX8_e3pdZ3DKYDwf9baZGzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Anyone using protonmail-bridge

[Todd Lasman]

On 2/14/19 11:55 AM, 22...@tutamail.com wrote:
> Would appreciate any thoughts on your set-up but try the following:
>
> In the appvm that houses your thunderbird and protonmail bridge add 
> protonmails IP(= 185.70.40.151) in the firewall settings. I have managed to 
> get it working by further limiting it to port 443 only.
>
> As I understand the workings of protonmail bridge and Qubes, since the bridge 
> is in the same appvm as your thunderbird, 127.0.0.1 is all done within the 
> appvm so it never crosses the firefall.
>
> I am not sure of your setup but as I have used it as follows:
>
> Thunderbird/protonmail bridge Appvm (firewall limited to 185.70.40.151) -> 
> Firewall -> NetVM
>
> or 
>
> Thunderbird/protonmail bridge Appvm (firewall limited to 185.70.40.151) -> 
> Whonix-GW -> Firewall -> NetVM
>
> I might submit a seperate question but how do you update the bridge in your 
> current Appvm? Protonmail just updated bridge, in the past I have rebuilt my 
> appvm but there must be an easier way to upgrade the bridge?
>
> I hope that helps...
>
Thanks for your help. I'll try this method for getting through the firewall.

Regarding updating the bridge: my email VM is based on a fedora clone.
In that clone, I've just installed the newest version (1.1.1) of the
protonmail-bridge, which I had to download manually from the protonmail
site.


-- 
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/e10bc00b-6bfb-e07c-cf70-96e8fd52c493%40nowlas.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Re: Anyone using protonmail-bridge

[22rip]

Would appreciate any thoughts on your set-up but try the following:

In the appvm that houses your thunderbird and protonmail bridge add protonmails 
IP(= 185.70.40.151) in the firewall settings. I have managed to get it working 
by further limiting it to port 443 only.

As I understand the workings of protonmail bridge and Qubes, since the bridge 
is in the same appvm as your thunderbird, 127.0.0.1 is all done within the 
appvm so it never crosses the firefall.

I am not sure of your setup but as I have used it as follows:

Thunderbird/protonmail bridge Appvm (firewall limited to 185.70.40.151) -> 
Firewall -> NetVM

or 

Thunderbird/protonmail bridge Appvm (firewall limited to 185.70.40.151) -> 
Whonix-GW -> Firewall -> NetVM

I might submit a seperate question but how do you update the bridge in your 
current Appvm? Protonmail just updated bridge, in the past I have rebuilt my 
appvm but there must be an easier way to upgrade the bridge?

I hope that helps...

-- 
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/301ceb43-f861-447d-993b-435cdbcb3284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #46: APT update mechanism vulnerability

[Vít Šesták]

On February 14, 2019 6:18:47 PM GMT+01:00, "Marek Marczykowski-Górecki" wrote:
>On Thu, Feb 14, 2019 at 05:58:09PM +0100, Vít Šesták wrote:
>> When I update dom0 and then Debian/Whonix without restarting the Qube
>Manager or Update “widget”*, is it enough? Or I need to restart the
>updater app (or maybe whole Qubes)?
>
>No, you need to restart it - just close its main window. Unlike 3.2,
>there is no need for additional steps like right-clicking on Q->quit.
>Similarly, closing updater gui is enough, even if "updates available"
>icon/widget stays there (the updater gui is a separate process).

That sounds like something that informed users are able to do, but uninformed 
users might feel no reason for doing so. It is (obviously) up to you, but I 
suggest adding this information somewhere near downloads.

>> *) I don't like calling a „widget“ something that opens a real
>window. It reminds me Android widgets, so I rather imagine the
>something on desktop what is available only when all windows are
>minimized/closed/nonmaximized.
>
>I agree. But right now we have two similar functionalities and I try to
>name them differently. So, I call the new updater "widget", because
>it's
>started from a widget...

Maybe I use it differently than I am supposed to. Alt+F3, “qubes update”*, 
enter. I don't know any widget I can start it from.

>PS was dropping mailing list intentional?

Just accidental…

*) Well, I usually just type some prefix that makes the relevant item first.

-- 
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/0B42755A-8FF3-4E8A-9B91-441E46CF1B94%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Anyone using protonmail-bridge

[Todd Lasman]

For anyone using protonmail-bridge with thunderbird:

What kind of settings are you using to allow sending/receiving through
the firewall? I've allowed protonmail.com and 127.0.0.1 (which is the
address the bridge uses), but when the firewall is activated, I can't
send or receive anything. Turning the firewall off allows normal operation.

Thanks.

Todd


-- 
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/df98d1e9-3170-22a1-4c0c-db01f433154d%40nowlas.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[Otto Kratik]

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?

-- 
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/19fac423-d6ef-4ae1-9ace-b8721552e44f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is it safe to install Qubes4 on laptop used windows10 before?

[Stuart Perkins]

On Thu, 14 Feb 2019 16:12:36 +
unman  wrote:

>On Wed, Feb 13, 2019 at 08:55:01PM +, zxcvw...@scryptmail.com wrote:
>> Hello All,I have a laptop from family that is rarely used,but with windows10 
>> installed on it,arguably the most infamous windows version.If I install 
>> Qubse4.0 on this laptop, would qubes completely wipe windows10 away?  Since 
>> some hardware's ID numbers are registered with microsoft in update 
>> process,and maybe even UUID, would microsoft still be able to track this 
>> laptop when it's online?Second option, is to take off the harddrive with 
>> windows10 and change to a completely new one purely for qubes. with the 
>> concern above still there-the hard ware records---can microsoft track THIS 
>> laptop when it's online?* by installed with windows 10 ---I mean it pressed 
>> the agree button on microsoft agreement when new laptop   switched on, this 
>> stage is offline,  and pressed 'update' button, and fully updated with 
>> microsoft and registered with it, this part is online.Please advise, thank 
>> you
>>   
>
>That's a really good question.
>Certainly MS will have some information about the hardware configuration
>of that laptop. That doesnt mean that MS would be able to track you
>online, but it does raise the issue that IF someone were able to get
>information about the hardware and IF they were able to get information
>from MS THEN they would be able to trace it back to you.
>When you install Qubes there are options to delete existing partitions,
>and if you choose to encrypt Qubes (I seem to recall that) the existing
>partitions will be overwritten, so the old Windows will be gone.
>
>If you are seriously worried about these issues I would recommend
>getting a burner laptop with new drive and look in to the use of
>Whonix-Qubes, or Qubes and Tor. If you are just somewhat concerned then to
>be honest a simple wipe and install of Qubes would be enough.
>
>unman
>

I prefer to go a step farther and use a laptop which can have the bios 
overwritten with coreboot, sans Intel ME.  This limits to laptops of a certain 
age/design, and I currently use a Lenovo T520.  The newest Lenovo laptop which 
ME can be completely removed is the X1 Carbon GEN 1.  After that, the best you 
can do is set the HAP bit...which still relies on some of the "blobs" and the 
early part of the ME.  I have not messed with doing either, and have a "guy" 
who coreboots my bios for me at present.

With the recent revelations about Austrailia's laws and the maintainers of 
Whonix, I would not trust it to provide anonymity.  Nevertheless, coreboot is a 
good start.

-- 
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/20190214103136.5e768a06%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #46: APT update mechanism vulnerability

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Feb 13, 2019 at 04:12:27AM -0800, Vít Šesták wrote:
> Since Qubes 4.0.1 was released [1] before your message and before the DSA 
> [2], I assume it is not a good idea to install Debian and Whonix from the 
> 4.0.1 installation media, is it?
> 
> If it is right, then I suggest adding a note on the download page [3] until 
> 4.0.2 release.

Qubes update tools (qubes manager, updates widget) do include safe apt
upgrade method. So, as long as you update dom0 before updating VMs, it
is safe to use Debian/Whonix from 4.0.1.

> Regards,
> Vít Šesták 'v6ak'
> 
> [1] https://www.qubes-os.org/news/2019/01/09/qubes-401/
> [2] https://www.debian.org/security/2019/dsa-4371
> [3] https://www.qubes-os.org/downloads/
> 


- -- 
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/THMrX1ywFAlxll1oACgkQ24/THMrX
1yxRSQf/XNSo8g5Fv6Yqj6h6GDEIZ2RDeaMYall0SrB58WcYur2zgDY4mzc4suOh
kXNokEhn89f2NXDiidNnpBlLrwvF4FeViRRfmZHy7eGsgIbh5IURFEtoToxKz6gw
Kel+9CzlsGk6y8fnPYutU0IRZvhGQ39MQ9jOd2FLs9kLU1AzIlD/PiZ+wUEZZS2l
dyn9c/a1GeHZPlRSibPHdFMkLIuZpGmfFuspwvuZOqbxg5drOQaktJjKSsDXKhHe
q1EuBQU0PAZ5LtKe44vSqFo2z73GqeReCpJB1VNR9Ep7JIN97MLfZzGtexzFjte+
v8jU3EqjZPGNhJNFA57w1KzYbydQbQ==
=2JNk
-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/20190214162914.GE9610%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is it safe to install Qubes4 on laptop used windows10 before?

[unman]

On Wed, Feb 13, 2019 at 08:55:01PM +, zxcvw...@scryptmail.com wrote:
> Hello All,I have a laptop from family that is rarely used,but with windows10 
> installed on it,arguably the most infamous windows version.If I install 
> Qubse4.0 on this laptop, would qubes completely wipe windows10 away?  Since 
> some hardware's ID numbers are registered with microsoft in update 
> process,and maybe even UUID, would microsoft still be able to track this 
> laptop when it's online?Second option, is to take off the harddrive with 
> windows10 and change to a completely new one purely for qubes. with the 
> concern above still there-the hard ware records---can microsoft track THIS 
> laptop when it's online?* by installed with windows 10 ---I mean it pressed 
> the agree button on microsoft agreement when new laptop   switched on, this 
> stage is offline,  and pressed 'update' button, and fully updated with 
> microsoft and registered with it, this part is online.Please advise, thank you
> 

That's a really good question.
Certainly MS will have some information about the hardware configuration
of that laptop. That doesnt mean that MS would be able to track you
online, but it does raise the issue that IF someone were able to get
information about the hardware and IF they were able to get information
from MS THEN they would be able to trace it back to you.
When you install Qubes there are options to delete existing partitions,
and if you choose to encrypt Qubes (I seem to recall that) the existing
partitions will be overwritten, so the old Windows will be gone.

If you are seriously worried about these issues I would recommend
getting a burner laptop with new drive and look in to the use of
Whonix-Qubes, or Qubes and Tor. If you are just somewhat concerned then to
be honest a simple wipe and install of Qubes would be enough.

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

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 3:35:27 PM UTC, unman wrote:
> On Thu, Feb 14, 2019 at 03:13:50PM +0100, ashleybrown...@tutanota.com wrote:
> > Hopefully one day they revert it back to how it was in 3.2. A very common 
> > use-case for the firewall is likely to ensure things like DNS requests do 
> > not happen through the normal means (and instead go over something like Tor 
> > or a VPN). Unfortunately, the current config does not make it very obvious 
> > that someone should block DNS ports. Making it very easy for someone to 
> > shoot themselves in the foot because the interface is not intuitive (it 
> > says it blocks all traffic other than what is specified and then later 
> > modifies this saying "just kidding, we let DNS through")
> > 
> > Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:
> > 
> > > On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com 
> > > wrote:
> > >
> > >> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
> > >> > >>  wrote:
> > >> > > In 3, if i clicked on "block connections" in the Qubes manager 
> > >> > > firewall section, there was (if memory serves me) an option to block 
> > >> > > DNS and ICMP. 
> > >> > > 
> > >> > > That is not present in R4 (though docs say you can disable DNS and 
> > >> > > ICMP manually)
> > >> > > 
> > >> > > I'm just wondering what the logic behind the removal was? I would 
> > >> > > have thought that a general user who clicks "block connections" on 
> > >> > > Qube would not expect the qube to be able to actually send out and 
> > >> > > receive network packets such as DNS or ICMP. This presents 
> > >> > > information leakage scenarios (default DNS lookups of given qube) 
> > >> > > and also potential egress vectors if a qube is ever compromised (DNS 
> > >> > > tunnelling, ICMP tunnelling). 
> > >> > 
> > >> As I said, I understand the documentation is correct. thats not my 
> > >> question. My question is why was it removed as an option when the 
> > >> firewall box itself in network manager says "Deny network access 
> > >> except..." 
> > >>
> > >> My point is it is counter intuitive. If it says "deny network access 
> > >> exccept..." then there is an expectation that it will deny network 
> > >> access except for what is specified. There used to be tick buttons 
> > >> (allow updates/allow ICMP/allow DNS), which made it clear on the 
> > >> granular control there - but were removed in R4. The underlying 
> > >> subsytems you can still do that, sure. 
> > >>
> > >> Can I suggest that the wording "deny network access except..." is 
> > >> changed to "Deny TCP and UDP access except ..." for the avoidance of any 
> > >> doubt.
> > >>
> > >
> > >
> > > https://github.com/QubesOS/qubes-manager/pull/153 
> > > 
> > >
> 
> Please dont top post - it breaks the thread of the conversation.
> 
> I dont find the current position confusing, since the DNS and ICMP
> position is clearly stated in the NOTE at the bottom of the window.
> 
> Simon, to answer your original question, there are many features in 4.0
> which are aimed at simplifying use of Qubes. I think this is one of
> them.
> The underlying issue is this: if you want to set a firewall rule using a
> named site, then you must not only  set the rule, (and the resolution
> will be set at the upstream firewall), but you must also enable DNS -
> otherwise your qube will not be able to resolve the address, even
> though you have correctly set the firewall rule.
> This adds a layer of complexity which a naive user would not understand.
> 
> The decision was made to keep DNS open in a trade off between usability
> and security.
> There's also an underlying assumption that users who want more will be
> able to negotiate command line tools. This assumption may be misplaced.
> There are many users (not only of Qubes) who consider themselves "power
> users" (never understood what that meant), but dont seem able to
> understand iptables or use anything except a GUI. (Just to be clear, I'm
> not aiming at any contributor here.)
> 
> As for ICMP, it's a moot point whether you should ever block ICMP at
> firewall level. Again, the benefit of having ICMP enabled is that basic
> network mechanisms are enabled, and basic diagnostic tools are
> available. It's a trade off between security and usability.
> 
> As with *all* parts of Qubes, if you dont like the defaults change them
> on your system.
> If you like, propose a change by submitting a PR.
> There's an open issue on exactly this, where Marta outlined the issue and
> invited contributions that would allow the change and also keep clarity
> for naive users (my gloss). No one has yet stepped up.
> 
> unman

Thanks Unman, thats a detailed and logical explanation as to where its gone. It 
makes a bit more sense now. As I said, it wasn't anything to do with 
documentation, more around managing a users expectations. If I have some time 

Re: [qubes-users] qvm-copy-to-vm question

[Todd Lasman]

On 2/14/19 7:12 AM, unman wrote:
> On Wed, Feb 13, 2019 at 08:12:42PM -0800, Todd Lasman wrote:
>> On 2/13/19 3:18 PM, 'awokd' via qubes-users wrote:
>>> Todd Lasman wrote on 2/13/19 1:58 AM:
 I'm not sure if I'm doing this correctly.
 O
 qvm-copy-to-vm destination_qube_name FILE
 All I want to do is copy a file from one qube to the next without
 hassle. Suggestions?
> You can suppress the prompt by setting rules in
> /etc/qubes-rpc/policy/qubes.Filecopy
> So if you have in that file:
> qube1 qube2 allow
> In qube1 you can use qvm-move-to-vm qube2 foo and no prompt will appear.
>
> The prompt appears because either you have not specified a target qube
> or you have not given appropriate permissions.
>
> unman
>
I understand. Thanks all, for the explanation (security), and the
potential for setting rules.

Todd


-- 
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/c110ccec-7b7d-e5e9-adbe-238e231de2c2%40nowlas.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[unman]

On Thu, Feb 14, 2019 at 03:05:20PM +0100, ashleybrown...@tutanota.com wrote:
> > The magic is in NAT rules (but I had to research this too.) See 
> > https://www.qubes-os.org/doc/networking 
> > , and "sudo iptables -t nat -L" 
> > in sys-firewall and sys-net.
> 
> I previously looked at IP tables and honestly I really do not understand it. 
> Can you please explain a little how it works?
> 
> Here is what my nat look like in sys-firewall:
> 
> Chain PR-QBS (1 references)
> target prot opt source   destination
> DNAT   udp  --  anywhere 10.139.1.1   udp dpt:domain 
> to:10.139.1.1
> DNAT   tcp  --  anywhere 10.139.1.1   tcp dpt:domain 
> to:10.139.1.1
> DNAT   udp  --  anywhere 10.139.1.2   udp dpt:domain 
> to:10.139.1.2
> DNAT   tcp  --  anywhere 10.139.1.2   tcp dpt:domain 
> to:10.139.1.2
> 
> So, when I do ping google.com it needs to do a DNS request. Because my AppVm 
> /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to send to 
> 10.139.1.1. However, no VM on the network actually has this address.
> 
> Is that packet modified? I am assuming what happens is the packet is 
> forwarded to whoever the internet provider is (in this case sys-firewall). 
> Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the DNS 
> server.
> 
> I am assuming the IP-Header of each hop is rewritten. So, for example, 
> sys-net will rewrite the IP header to be the external IP address for the 
> computer and thus it will receive a response to that IP. Assuming this is 
> correct how does the original AppVM get the correct response? I assume 
> multiple AppVMs are all forwarding these UDP dns requests through 
> sys-firewall and then sys-net. And then when sys-net gets a response how does 
> it know to send which response to which specific AppVM?
> 

Yes, you are spot on. The packet is sent upstream (routing table on
sys-firewall) and hits sys-net.
On sys-net, you'll see in the nat table (I'm assuming iptables on
Debian) rules that rewrite udp/tcp to 10.139.1.1 to use the DNS resolver
provided by the external network.
DNAT   udp  --  * * 0.0.0.0/0    10.139.1.1    udp dpt:domain to:X.X.X.X

These are stateful firewalls that keep track of the packets passing
through them. Sys-net returns the DNS result to sys-firewall and it's
there that the response is matched to the request and sent back to the
originating qube.

hth

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

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

[unman]

On Thu, Feb 14, 2019 at 03:13:00PM +0100, ashleybrown...@tutanota.com wrote:
> 
> 
> Hopefully one day they revert it back to how it was in 3.2. A very common 
> use-case for the firewall is likely to ensure things like DNS requests do not 
> happen through the normal means (and instead go over something like Tor or a 
> VPN). Unfortunately, the current config does not make it very obvious that 
> someone should block DNS ports. Making it very easy for someone to shoot 
> themselves in the foot because the interface is not intuitive (it says it 
> blocks all traffic other than what is specified and then later modifies this 
> saying "just kidding, we let DNS through")
> 
> Feb 14, 2019, 2:05 PM by ashleybrown...@tutanota.com:
> 
> > > The magic is in NAT rules (but I had to research this too.) See > 
> > > https://www.qubes-os.org/doc/networking 
> > > > , and "sudo iptables -t nat 
> > > -L" in sys-firewall and sys-net.
> >
> > I previously looked at IP tables and honestly I really do not understand 
> > it. Can you please explain a little how it works?
> >
> > Here is what my nat look like in sys-firewall:
> >
> > Chain PR-QBS (1 references)
> > target prot opt source   destination
> > DNAT   udp  --  anywhere 10.139.1.1   udp 
> > dpt:domain to:10.139.1.1
> > DNAT   tcp  --  anywhere 10.139.1.1   tcp 
> > dpt:domain to:10.139.1.1
> > DNAT   udp  --  anywhere 10.139.1.2   udp 
> > dpt:domain to:10.139.1.2
> > DNAT   tcp  --  anywhere 10.139.1.2   tcp 
> > dpt:domain to:10.139.1.2
> >
> > So, when I do ping google.com it needs to do a DNS request. Because my 
> > AppVm /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to 
> > send to 10.139.1.1. However, no VM on the network actually has this address.
> >
> > Is that packet modified? I am assuming what happens is the packet is 
> > forwarded to whoever the internet provider is (in this case sys-firewall). 
> > Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the 
> > DNS server.
> >
> > I am assuming the IP-Header of each hop is rewritten. So, for example, 
> > sys-net will rewrite the IP header to be the external IP address for the 
> > computer and thus it will receive a response to that IP. Assuming this is 
> > correct how does the original AppVM get the correct response? I assume 
> > multiple AppVMs are all forwarding these UDP dns requests through 
> > sys-firewall and then sys-net. And then when sys-net gets a response how 
> > does it know to send which response to which specific AppVM?
> >
> > -- 
> > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
> > https://tutanota.com 
> >
> >
> > Feb 14, 2019, 11:46 AM by > qubes-users@googlegroups.com 
> > > :
> >
> >> ashleybrown...@tutanota.com >>  wrote 
> >> on 2/14/19 6:28 AM:
> >>
> >>> When I look at /etc/resolv.conf in the following VMs it says different 
> >>> things:
> >>>
> >>> 1) Normal AppVM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 2) Sys-firewall VM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 3) Sys-net VM:
> >>>
> >>> [actual resolvers]
> >>>
> >>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
> >>>
> >>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That 
> >>> is not the IP address for any VM on the network. This can  be verified in 
> >>> Qubes Manager looking at the IP column. In addition, 10.139.1.1 refers to 
> >>> different VMs depending on the VM sending the packets. In AppVM it routes 
> >>> to sys-firewall. In sys-firewall it routes to sys-net.
> >>>
> >>> So, my question is how does all of this work? Where exactly does any 
> >>> request to 10.139.1.1 route to the actual connected VM. Looking at IP 
> >>> table rules I do not see where traffic sent to 10.139.1.1 goes to 
> >>> [sys-firewall IP here] for example. It appears to be doing it all 
> >>> magically, so where is the magic?
> >>>
> >>
> >> The magic is in NAT rules (but I had to research this too.) See >> 
> >> https://www.qubes-os.org/doc/networking 
> >> >> , and "sudo iptables -t nat 
> >> -L" in sys-firewall and sys-net.
> >>

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.

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

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

[unman]

On Thu, Feb 14, 2019 at 04:29:45PM +1100, haaber wrote:
> Are canaries now  "illegal" in Aussi law as well ???
> 
> On 2/14/19 3:26 PM, teresardavida...@gmail.com wrote:
> > Summary: I have reason to believe the possibility that Mig5 (the new 
> > SysAdmin on Whonix project) could be compelled under federal law to provide 
> > assistance is high and the threat to the security and anonymity offered by 
> > the project could be compromised as a result is also high.
> > 
> > I recently visited the Whonix community website for an unrelated purpose 
> > and discovered something that I think in honest to good faith deserves 
> > public discussion.
> > 
> > I was alarmed and shocked to see my post abruptly deleted and my account 
> > permanently disabled.
> > 
> > I would like to post my thoughts here to the Qubes User community for 
> > further scrutiny and discussion and perhaps maybe get the attention of the 
> > project maintainer who I do see regularly participate on this channel.
> > 
> > Below is a copy paste of the submission which was deleted from the Whonix 
> > community forum.
> > 
> > [Quote]
> > This post is in no way doubting the integrity or calling into question the 
> > character of Mig5 the new sysadmin for the whonix project.
> > 
> > But I do feel it is necessary to point out that the new sysadmin is 
> > Australian (or resides in Australia). Under Australian law, he can be 
> > compelled through threat of imprisonment to cooperate with the Australian 
> > government. This law is designed to compel individuals that work on 
> > projects such as Whonix to insert or write code that permits lawful access. 
> > If a person is served with such enforcement, they are required to keep it 
> > secret or risk imprisonment.
> > 
> > This law was only recently introduced and is already being used to great 
> > effect according to recent reports.
> > 
> > While Whonix is an open-source project it is important to remember that 
> > open source does not imply greater security. One only needs to consider one 
> > of the most widely used and scrutinized open source projects (OpenSSL) had 
> > a backdoor that went undetected for several years. It was just two lines of 
> > code. It literally broke the internet.
> > 
> > I deeply regret having to bring this to the attention of the community 
> > please do not interpret my thoughts here as a question of Mig5's character. 
> > I value all contributions but believe the circumstances and severity of the 
> > consequences warrant public discussion. The bottom line is, as the law is 
> > written, he would be required to cooperate and in secret. I think someone 
> > like him, in a position he now occupies, represents a textbook example of 
> > why this law was written in the first place. In my opinion, it is not a 
> > question of "if" he is compelled but rather just a matter of "when".
> > 
> > Unfortunately it is not uncommon for Whonix to be encountered by forensic 
> > analysts who have the regrettable job of investigating computer equipment 
> > seized by suspects charged with child abuse related offenses. At least not 
> > in Australia. I can say with certainty this project already has high 
> > visibility among specific cyber investigative divisions within both state 
> > and federal AG. I do not have any classified information I can share and if 
> > I did I would not share it but I can provide some information in private to 
> > Patrick that taken to its logical conclusion would suggest this project is 
> > likely to be a high priority target for these new laws.
> > 
> > [/Quote]
> > 

Please dont top post.

Whonix does not use canaries, as you can see here:
https://forums.whonix.org/t/whonix-warrant-canary/3208

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

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[unman]

On Thu, Feb 14, 2019 at 03:13:50PM +0100, ashleybrown...@tutanota.com wrote:
> Hopefully one day they revert it back to how it was in 3.2. A very common 
> use-case for the firewall is likely to ensure things like DNS requests do not 
> happen through the normal means (and instead go over something like Tor or a 
> VPN). Unfortunately, the current config does not make it very obvious that 
> someone should block DNS ports. Making it very easy for someone to shoot 
> themselves in the foot because the interface is not intuitive (it says it 
> blocks all traffic other than what is specified and then later modifies this 
> saying "just kidding, we let DNS through")
> 
> Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:
> 
> > On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com 
> > wrote:
> >
> >> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
> >> > >>  wrote:
> >> > > In 3, if i clicked on "block connections" in the Qubes manager 
> >> > > firewall section, there was (if memory serves me) an option to block 
> >> > > DNS and ICMP. 
> >> > > 
> >> > > That is not present in R4 (though docs say you can disable DNS and 
> >> > > ICMP manually)
> >> > > 
> >> > > I'm just wondering what the logic behind the removal was? I would have 
> >> > > thought that a general user who clicks "block connections" on Qube 
> >> > > would not expect the qube to be able to actually send out and receive 
> >> > > network packets such as DNS or ICMP. This presents information leakage 
> >> > > scenarios (default DNS lookups of given qube) and also potential 
> >> > > egress vectors if a qube is ever compromised (DNS tunnelling, ICMP 
> >> > > tunnelling). 
> >> > 
> >> As I said, I understand the documentation is correct. thats not my 
> >> question. My question is why was it removed as an option when the firewall 
> >> box itself in network manager says "Deny network access except..." 
> >>
> >> My point is it is counter intuitive. If it says "deny network access 
> >> exccept..." then there is an expectation that it will deny network access 
> >> except for what is specified. There used to be tick buttons (allow 
> >> updates/allow ICMP/allow DNS), which made it clear on the granular control 
> >> there - but were removed in R4. The underlying subsytems you can still do 
> >> that, sure. 
> >>
> >> Can I suggest that the wording "deny network access except..." is changed 
> >> to "Deny TCP and UDP access except ..." for the avoidance of any doubt.
> >>
> >
> >
> > https://github.com/QubesOS/qubes-manager/pull/153 
> > 
> >

Please dont top post - it breaks the thread of the conversation.

I dont find the current position confusing, since the DNS and ICMP
position is clearly stated in the NOTE at the bottom of the window.

Simon, to answer your original question, there are many features in 4.0
which are aimed at simplifying use of Qubes. I think this is one of
them.
The underlying issue is this: if you want to set a firewall rule using a
named site, then you must not only  set the rule, (and the resolution
will be set at the upstream firewall), but you must also enable DNS -
otherwise your qube will not be able to resolve the address, even
though you have correctly set the firewall rule.
This adds a layer of complexity which a naive user would not understand.

The decision was made to keep DNS open in a trade off between usability
and security.
There's also an underlying assumption that users who want more will be
able to negotiate command line tools. This assumption may be misplaced.
There are many users (not only of Qubes) who consider themselves "power
users" (never understood what that meant), but dont seem able to
understand iptables or use anything except a GUI. (Just to be clear, I'm
not aiming at any contributor here.)

As for ICMP, it's a moot point whether you should ever block ICMP at
firewall level. Again, the benefit of having ICMP enabled is that basic
network mechanisms are enabled, and basic diagnostic tools are
available. It's a trade off between security and usability.

As with *all* parts of Qubes, if you dont like the defaults change them
on your system.
If you like, propose a change by submitting a PR.
There's an open issue on exactly this, where Marta outlined the issue and
invited contributions that would allow the change and also keep clarity
for naive users (my gloss). No one has yet stepped up.

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

Re: [qubes-users] qvm-copy-to-vm question

[unman]

On Wed, Feb 13, 2019 at 08:12:42PM -0800, Todd Lasman wrote:
> 
> On 2/13/19 3:18 PM, 'awokd' via qubes-users wrote:
> > Todd Lasman wrote on 2/13/19 1:58 AM:
> > > I'm not sure if I'm doing this correctly.
> > > 
> > > According to the usage, the syntax is:
> > > qvm-copy-to-vm destination_qube_name FILE
> > 
> > > All I want to do is copy a file from one qube to the next without
> > > hassle. Suggestions?

You can suppress the prompt by setting rules in
/etc/qubes-rpc/policy/qubes.Filecopy
So if you have in that file:
qube1 qube2 allow
In qube1 you can use qvm-move-to-vm qube2 foo and no prompt will appear.

The prompt appears because either you have not specified a target qube
or you have not given appropriate permissions.

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

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[ashleybrown480]

Hopefully one day they revert it back to how it was in 3.2. A very common 
use-case for the firewall is likely to ensure things like DNS requests do not 
happen through the normal means (and instead go over something like Tor or a 
VPN). Unfortunately, the current config does not make it very obvious that 
someone should block DNS ports. Making it very easy for someone to shoot 
themselves in the foot because the interface is not intuitive (it says it 
blocks all traffic other than what is specified and then later modifies this 
saying "just kidding, we let DNS through")

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:

> On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
>
>> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
>> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> > 
>> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
>> > >>  wrote:
>> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
>> > > section, there was (if memory serves me) an option to block DNS and 
>> > > ICMP. 
>> > > 
>> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
>> > > manually)
>> > > 
>> > > I'm just wondering what the logic behind the removal was? I would have 
>> > > thought that a general user who clicks "block connections" on Qube would 
>> > > not expect the qube to be able to actually send out and receive network 
>> > > packets such as DNS or ICMP. This presents information leakage scenarios 
>> > > (default DNS lookups of given qube) and also potential egress vectors if 
>> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
>> > 
>> > Let me quote full text you can find on firewall tab there:
>> > 
>> > NOTE: To block all network access, set Networking to (none) on the
>> > Basic settings tab. This tab provides a very simplified firewall
>> > configuration. All DNS requests and ICMP (pings) will be allowed. For
>> > more granular control, use the command line tool qvm-firewall.
>> > 
>> > There is clear message what to do if you want to cut the qube from the
>> > network.
>> > 
>> > - -- 
>> > 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/THMrX1ywFAlxk5lQACgkQ24/THMrX
>> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
>> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
>> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
>> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
>> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
>> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
>> > =9dvG
>> > -END PGP SIGNATURE-
>>
>> As I said, I understand the documentation is correct. thats not my question. 
>> My question is why was it removed as an option when the firewall box itself 
>> in network manager says "Deny network access except..." 
>>
>> My point is it is counter intuitive. If it says "deny network access 
>> exccept..." then there is an expectation that it will deny network access 
>> except for what is specified. There used to be tick buttons (allow 
>> updates/allow ICMP/allow DNS), which made it clear on the granular control 
>> there - but were removed in R4. The underlying subsytems you can still do 
>> that, sure. 
>>
>> Can I suggest that the wording "deny network access except..." is changed to 
>> "Deny TCP and UDP access except ..." for the avoidance of any doubt.
>>
>
>
> https://github.com/QubesOS/qubes-manager/pull/153 
> 
>
> -- 
> 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/39615092-155b-4f93-a418-95f7ff95c...@googlegroups.com
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

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

[ashleybrown480]

Hopefully one day they revert it back to how it was in 3.2. A very common 
use-case for the firewall is likely to ensure things like DNS requests do not 
happen through the normal means (and instead go over something like Tor or a 
VPN). Unfortunately, the current config does not make it very obvious that 
someone should block DNS ports. Making it very easy for someone to shoot 
themselves in the foot because the interface is not intuitive (it says it 
blocks all traffic other than what is specified and then later modifies this 
saying "just kidding, we let DNS through")

Feb 14, 2019, 2:05 PM by ashleybrown...@tutanota.com:

> > The magic is in NAT rules (but I had to research this too.) See > 
> > https://www.qubes-os.org/doc/networking 
> > > , and "sudo iptables -t nat -L" 
> > in sys-firewall and sys-net.
>
> I previously looked at IP tables and honestly I really do not understand it. 
> Can you please explain a little how it works?
>
> Here is what my nat look like in sys-firewall:
>
> Chain PR-QBS (1 references)
> target prot opt source   destination
> DNAT   udp  --  anywhere 10.139.1.1   udp dpt:domain 
> to:10.139.1.1
> DNAT   tcp  --  anywhere 10.139.1.1   tcp dpt:domain 
> to:10.139.1.1
> DNAT   udp  --  anywhere 10.139.1.2   udp dpt:domain 
> to:10.139.1.2
> DNAT   tcp  --  anywhere 10.139.1.2   tcp dpt:domain 
> to:10.139.1.2
>
> So, when I do ping google.com it needs to do a DNS request. Because my AppVm 
> /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to send to 
> 10.139.1.1. However, no VM on the network actually has this address.
>
> Is that packet modified? I am assuming what happens is the packet is 
> forwarded to whoever the internet provider is (in this case sys-firewall). 
> Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the DNS 
> server.
>
> I am assuming the IP-Header of each hop is rewritten. So, for example, 
> sys-net will rewrite the IP header to be the external IP address for the 
> computer and thus it will receive a response to that IP. Assuming this is 
> correct how does the original AppVM get the correct response? I assume 
> multiple AppVMs are all forwarding these UDP dns requests through 
> sys-firewall and then sys-net. And then when sys-net gets a response how does 
> it know to send which response to which specific AppVM?
>
> -- 
> Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
> https://tutanota.com 
>
>
> Feb 14, 2019, 11:46 AM by > qubes-users@googlegroups.com 
> > :
>
>> ashleybrown...@tutanota.com >>  wrote on 
>> 2/14/19 6:28 AM:
>>
>>> When I look at /etc/resolv.conf in the following VMs it says different 
>>> things:
>>>
>>> 1) Normal AppVM:
>>>
>>> nameserver 10.139.1.1
>>> nameserver 10.139.1.2
>>>
>>> 2) Sys-firewall VM:
>>>
>>> nameserver 10.139.1.1
>>> nameserver 10.139.1.2
>>>
>>> 3) Sys-net VM:
>>>
>>> [actual resolvers]
>>>
>>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
>>>
>>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That is 
>>> not the IP address for any VM on the network. This can  be verified in 
>>> Qubes Manager looking at the IP column. In addition, 10.139.1.1 refers to 
>>> different VMs depending on the VM sending the packets. In AppVM it routes 
>>> to sys-firewall. In sys-firewall it routes to sys-net.
>>>
>>> So, my question is how does all of this work? Where exactly does any 
>>> request to 10.139.1.1 route to the actual connected VM. Looking at IP table 
>>> rules I do not see where traffic sent to 10.139.1.1 goes to [sys-firewall 
>>> IP here] for example. It appears to be doing it all magically, so where is 
>>> the magic?
>>>
>>
>> The magic is in NAT rules (but I had to research this too.) See >> 
>> https://www.qubes-os.org/doc/networking 
>> >> , and "sudo iptables -t nat -L" 
>> in sys-firewall and sys-net.
>>
>>
>> -- 
>> 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/42007cbd-b403-c239-25cc-78f1d7ac3...@danwin1210.me
>>  
>> >>
>>  .
>> For more options, visit >> https://groups.google.com/d/optout 
>> >> .
>>
>
>
>
>
> --
>  Y

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[ashleybrown480]

There is an issue that talks about the change: 
https://github.com/QubesOS/qubes-issues/issues/4141 


They are willing to port it back to how it should be if someone does the 
interface to re-add those options.

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:

> On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
>
>> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
>> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> > 
>> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
>> > >>  wrote:
>> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
>> > > section, there was (if memory serves me) an option to block DNS and 
>> > > ICMP. 
>> > > 
>> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
>> > > manually)
>> > > 
>> > > I'm just wondering what the logic behind the removal was? I would have 
>> > > thought that a general user who clicks "block connections" on Qube would 
>> > > not expect the qube to be able to actually send out and receive network 
>> > > packets such as DNS or ICMP. This presents information leakage scenarios 
>> > > (default DNS lookups of given qube) and also potential egress vectors if 
>> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
>> > 
>> > Let me quote full text you can find on firewall tab there:
>> > 
>> > NOTE: To block all network access, set Networking to (none) on the
>> > Basic settings tab. This tab provides a very simplified firewall
>> > configuration. All DNS requests and ICMP (pings) will be allowed. For
>> > more granular control, use the command line tool qvm-firewall.
>> > 
>> > There is clear message what to do if you want to cut the qube from the
>> > network.
>> > 
>> > - -- 
>> > 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/THMrX1ywFAlxk5lQACgkQ24/THMrX
>> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
>> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
>> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
>> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
>> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
>> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
>> > =9dvG
>> > -END PGP SIGNATURE-
>>
>> As I said, I understand the documentation is correct. thats not my question. 
>> My question is why was it removed as an option when the firewall box itself 
>> in network manager says "Deny network access except..." 
>>
>> My point is it is counter intuitive. If it says "deny network access 
>> exccept..." then there is an expectation that it will deny network access 
>> except for what is specified. There used to be tick buttons (allow 
>> updates/allow ICMP/allow DNS), which made it clear on the granular control 
>> there - but were removed in R4. The underlying subsytems you can still do 
>> that, sure. 
>>
>> Can I suggest that the wording "deny network access except..." is changed to 
>> "Deny TCP and UDP access except ..." for the avoidance of any doubt.
>>
>
>
> https://github.com/QubesOS/qubes-manager/pull/153 
> 
>
> -- 
> 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/39615092-155b-4f93-a418-95f7ff95c...@googlegroups.com
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

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

[ashleybrown480]

> The magic is in NAT rules (but I had to research this too.) See 
> https://www.qubes-os.org/doc/networking 
> , and "sudo iptables -t nat -L" in 
> sys-firewall and sys-net.

I previously looked at IP tables and honestly I really do not understand it. 
Can you please explain a little how it works?

Here is what my nat look like in sys-firewall:

Chain PR-QBS (1 references)
target prot opt source   destination
DNAT   udp  --  anywhere 10.139.1.1   udp dpt:domain 
to:10.139.1.1
DNAT   tcp  --  anywhere 10.139.1.1   tcp dpt:domain 
to:10.139.1.1
DNAT   udp  --  anywhere 10.139.1.2   udp dpt:domain 
to:10.139.1.2
DNAT   tcp  --  anywhere 10.139.1.2   tcp dpt:domain 
to:10.139.1.2

So, when I do ping google.com it needs to do a DNS request. Because my AppVm 
/etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to send to 
10.139.1.1. However, no VM on the network actually has this address.

Is that packet modified? I am assuming what happens is the packet is forwarded 
to whoever the internet provider is (in this case sys-firewall). Sys-firewall 
then forwards it to sys-net. Sys-net then forwards it to the DNS server.

I am assuming the IP-Header of each hop is rewritten. So, for example, sys-net 
will rewrite the IP header to be the external IP address for the computer and 
thus it will receive a response to that IP. Assuming this is correct how does 
the original AppVM get the correct response? I assume multiple AppVMs are all 
forwarding these UDP dns requests through sys-firewall and then sys-net. And 
then when sys-net gets a response how does it know to send which response to 
which specific AppVM?

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Feb 14, 2019, 11:46 AM by qubes-users@googlegroups.com:

> ashleybrown...@tutanota.com >  wrote on 
> 2/14/19 6:28 AM:
>
>> When I look at /etc/resolv.conf in the following VMs it says different 
>> things:
>>
>> 1) Normal AppVM:
>>
>> nameserver 10.139.1.1
>> nameserver 10.139.1.2
>>
>> 2) Sys-firewall VM:
>>
>> nameserver 10.139.1.1
>> nameserver 10.139.1.2
>>
>> 3) Sys-net VM:
>>
>> [actual resolvers]
>>
>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
>>
>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That is 
>> not the IP address for any VM on the network. This can  be verified in Qubes 
>> Manager looking at the IP column. In addition, 10.139.1.1 refers to 
>> different VMs depending on the VM sending the packets. In AppVM it routes to 
>> sys-firewall. In sys-firewall it routes to sys-net.
>>
>> So, my question is how does all of this work? Where exactly does any request 
>> to 10.139.1.1 route to the actual connected VM. Looking at IP table rules I 
>> do not see where traffic sent to 10.139.1.1 goes to [sys-firewall IP here] 
>> for example. It appears to be doing it all magically, so where is the magic?
>>
>
> The magic is in NAT rules (but I had to research this too.) See > 
> https://www.qubes-os.org/doc/networking 
> > , and "sudo iptables -t nat -L" 
> in sys-firewall and sys-net.
>
>
> -- 
> 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/42007cbd-b403-c239-25cc-78f1d7ac3...@danwin1210.me
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

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

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, simon.new...@gmail.com wrote:
> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
> > > section, there was (if memory serves me) an option to block DNS and ICMP. 
> > > 
> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
> > > manually)
> > > 
> > > I'm just wondering what the logic behind the removal was? I would have 
> > > thought that a general user who clicks "block connections" on Qube would 
> > > not expect the qube to be able to actually send out and receive network 
> > > packets such as DNS or ICMP. This presents information leakage scenarios 
> > > (default DNS lookups of given qube) and also potential egress vectors if 
> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
> > 
> > Let me quote full text you can find on firewall tab there:
> > 
> > NOTE: To block all network access, set Networking to (none) on the
> > Basic settings tab. This tab provides a very simplified firewall
> > configuration. All DNS requests and ICMP (pings) will be allowed. For
> > more granular control, use the command line tool qvm-firewall.
> > 
> > There is clear message what to do if you want to cut the qube from the
> > network.
> > 
> > - -- 
> > 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/THMrX1ywFAlxk5lQACgkQ24/THMrX
> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
> > =9dvG
> > -END PGP SIGNATURE-
> 
> As I said, I understand the documentation is correct. thats not my question. 
> My question is why was it removed as an option when the firewall box itself 
> in network manager says "Deny network access except..." 
> 
> My point is it is counter intuitive. If it says "deny network access 
> exccept..." then there is an expectation that it will deny network access 
> except for what is specified. There used to be tick buttons (allow 
> updates/allow ICMP/allow DNS), which made it clear on the granular control 
> there - but were removed in R4. The underlying subsytems you can still do 
> that, sure. 
> 
> Can I suggest that the wording "deny network access except..." is changed to 
> "Deny TCP and UDP access except ..." for the avoidance of any doubt.


https://github.com/QubesOS/qubes-manager/pull/153

-- 
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/39615092-155b-4f93-a418-95f7ff95c71f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Feb 13, 2019 at 08:42:10AM -0800, simon.new...@gmail.com wrote:
> > In 3, if i clicked on "block connections" in the Qubes manager firewall 
> > section, there was (if memory serves me) an option to block DNS and ICMP. 
> > 
> > That is not present in R4 (though docs say you can disable DNS and ICMP 
> > manually)
> > 
> > I'm just wondering what the logic behind the removal was? I would have 
> > thought that a general user who clicks "block connections" on Qube would 
> > not expect the qube to be able to actually send out and receive network 
> > packets such as DNS or ICMP. This presents information leakage scenarios 
> > (default DNS lookups of given qube) and also potential egress vectors if a 
> > qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
> 
> Let me quote full text you can find on firewall tab there:
> 
> NOTE: To block all network access, set Networking to (none) on the
> Basic settings tab. This tab provides a very simplified firewall
> configuration. All DNS requests and ICMP (pings) will be allowed. For
> more granular control, use the command line tool qvm-firewall.
> 
> There is clear message what to do if you want to cut the qube from the
> network.
> 
> - -- 
> 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/THMrX1ywFAlxk5lQACgkQ24/THMrX
> 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
> Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
> HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
> cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
> J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
> EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
> =9dvG
> -END PGP SIGNATURE-

As I said, I understand the documentation is correct. thats not my question. My 
question is why was it removed as an option when the firewall box itself in 
network manager says "Deny network access except..." 

My point is it is counter intuitive. If it says "deny network access 
exccept..." then there is an expectation that it will deny network access 
except for what is specified. There used to be tick buttons (allow 
updates/allow ICMP/allow DNS), which made it clear on the granular control 
there - but were removed in R4. The underlying subsytems you can still do that, 
sure. 

Can I suggest that the wording "deny network access except..." is changed to 
"Deny TCP and UDP access except ..." for the avoidance of any doubt. 

-- 
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/3ef9e1e3-47f3-4062-adbc-69c5ba5d109d%40googlegroups.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/14/19 6:28 AM:

When I look at /etc/resolv.conf in the following VMs it says different things:

1) Normal AppVM:

nameserver 10.139.1.1
nameserver 10.139.1.2

2) Sys-firewall VM:

nameserver 10.139.1.1
nameserver 10.139.1.2

3) Sys-net VM:

[actual resolvers]

The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net

However, what I don't undersatnd is that 10.139.1.1 does not exist. That is not 
the IP address for any VM on the network. This can  be verified in Qubes 
Manager looking at the IP column. In addition, 10.139.1.1 refers to different 
VMs depending on the VM sending the packets. In AppVM it routes to 
sys-firewall. In sys-firewall it routes to sys-net.

So, my question is how does all of this work? Where exactly does any request to 
10.139.1.1 route to the actual connected VM. Looking at IP table rules I do not 
see where traffic sent to 10.139.1.1 goes to [sys-firewall IP here] for 
example. It appears to be doing it all magically, so where is the magic?


The magic is in NAT rules (but I had to research this too.) See 
https://www.qubes-os.org/doc/networking/, and "sudo iptables -t nat -L" 
in sys-firewall and sys-net.



--
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/42007cbd-b403-c239-25cc-78f1d7ac37f5%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-copy-to-vm question

['awokd' via qubes-users]

Todd Lasman wrote on 2/14/19 4:12 AM:


On 2/13/19 3:18 PM, 'awokd' via qubes-users wrote:


From a terminal session inside the source qube, use "qvm-copy 
[filename]". It will then prompt for the destination qube.


Ok. Thanks for the explanation. Still doesn't seem right to me, though. 
I think I should be able to do the whole copy/move with one command, 
rather than two.


I think it was done for security reasons- having dom0 prompt for the 
destination is safer than allowing any qube to copy any data to any 
other qube automatically.


--
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/e07a0d49-2d23-8130-7fd0-1e63f088285d%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.