Re: [qubes-users] Update/Removal

2018-10-10 Thread 'Christophe Vial' via qubes-users
You maybe still have fedora 26 set as default template VM in general qubes 
settings. That could be a reason why you can't remove it.

 Original Message 
On Oct 11, 2018, 07:05, wrote:

> I used the qubes R3 with no problem, everything work out of the box and it 
> was nice ( i just wanted to say that ).
>
> Now here's the problem, qubes R4 iso file is not up to date and i have no 
> clue why the team doesn't take the time to update it, rather then force every 
> new person, to install a version that needs to be fully updated from 
> fedora/debian to the new whonix 14 ( woundn't it be easy to provide a iso 
> that updated with debian/fedora/whonix).
>
> So i followed everything step by step on how to update the fedora 26 to 27 
> and to update whonix to whonix 14 and and by all means everything is working 
> perfectly except one problem, ( my old fedora 26 and old whonix are still 
> there and i am not able to remove them by any means).I really tried 
> everything and read other peoples problem.
>
> Will the Qubes team update the R4 iso with the new fedora/debian/whonix ? As 
> i love qubes.
>
> Am using a thinkpad x220
>
> 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/6caf409d-393a-4ff5-b5ff-9da25df0aecf%40googlegroups.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/VpUwh0NhV-WOyK3_aH4FdNohV9UcqQxAIklcTICH5DN5PRFZitvHcEJLJKZj2tZyJUStDJvYJgp4cuZB363Sx1W4zWY9wVMkF1mMRc42boA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Update/Removal

2018-10-10 Thread liontren1
I used the qubes R3 with no problem, everything work out of the box and it was 
nice ( i just wanted to say that ).

Now here's the problem, qubes R4 iso file is not up to date and i have no clue 
why the team doesn't take the time to update it, rather then force every new 
person, to install a version that needs to be fully updated from fedora/debian 
to the new whonix 14 ( woundn't it be easy to provide a iso that updated with 
debian/fedora/whonix).

So i followed everything step by step on how to update the fedora 26 to 27 and 
to update whonix to whonix 14 and and by all means everything is working 
perfectly except one problem, ( my old fedora 26 and old whonix are still there 
and i am not able to remove them by any means).I really tried everything and 
read other peoples problem.

Will the Qubes team update the R4 iso with the new fedora/debian/whonix ? As i 
love qubes.

Am using a thinkpad x220

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/6caf409d-393a-4ff5-b5ff-9da25df0aecf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] after suspend sys-firewall looses connection with sys-net Qubes 3.2

2018-10-10 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/10/18 10:56 PM, Franz wrote:
> Randomly, but increasing, after suspend sys-net is shutdown.
> If I start it, it automatically connects to wifi, but sys-firewall is
> unable to connect to sys-net.
> If I try
> qvm-prefs -s sys-firewall netvm sys-net
> 1. immediately after sys-net start, get "libxenlight failed to detach
> network device"
> 2. after sys-net is fully started and already automatically connected to
> wifi, get "an error occurred but the cause in unknown". The same happens if
> I try to disable networking with the network manager applet.
> 

Known bug:

https://github.com/QubesOS/qubes-issues/issues/3657

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlu+1eEACgkQ203TvDlQ
MDCxVw//dJAC2Rx4UAzAJakJNZILKD0rcLTkLNjz28UJBucengMPxfPQsP9v/BGG
3QeIt/Cokoad8QLdcaNNiQsRdYvkEc8WUM3qbtULJ1Gtsivqc712c9H+2ygLh5TI
6H6YT2dO7DkjsoX6Qyd51c8Y0HoVcIvoW4I5ZD4wQhNXX7PiYs8tcr7imcGmRE6T
9VN5MdmrRcH0P4DwrhJOo78n2BmJuCrSUaH9zuuMCW66+Nn/wEp/Qu9Qcyvp+nBZ
0LRo0F/0YVgLArfgSAqZx7hR9IskH5AtKfbrb5XQA+nUOUoQ63P4zleHZOmsz7V+
r/Rw7YAOr1d6iG6D5ulGcAvr7iNLzQgQaHdm+EoL6hinCvz6OqyaS/m3oEkkQ6HB
KcuJjQbKPE6CZF6y9/yC5P1dXW+apUR8jcDxiQnmQNOy8+XjzKzzeoK3CkPe3fDr
IEd0lFtRrTjlk4n3hvCyfJeD76vat0PcTrN5CL+c+3vQrMpce6yvJTALcmWaNyiG
Y2HnT34A67RyOD0xsEJ2VMczn96xDkFHZo72zwginWcrjwdvJleS2YpKvRpTAOgx
zr+5+GfoxydIW7TU2CMY5v990O3s2228hwPb1jkkjwVr6eeCWVSWcLCxxXVyLP1t
ewAloLKobh2XtHxYLY2yiBC1dSHIYbLBB5g9aZBblcZ/LzkH+N4=
=hll2
-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/cf0c3b8e-5b68-9727-5235-ba07f3bda519%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] after suspend sys-firewall looses connection with sys-net Qubes 3.2

2018-10-10 Thread Franz
Randomly, but increasing, after suspend sys-net is shutdown.
If I start it, it automatically connects to wifi, but sys-firewall is
unable to connect to sys-net.
If I try
qvm-prefs -s sys-firewall netvm sys-net
1. immediately after sys-net start, get "libxenlight failed to detach
network device"
2. after sys-net is fully started and already automatically connected to
wifi, get "an error occurred but the cause in unknown". The same happens if
I try to disable networking with the network manager applet.

-- 
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/CAPzH-qCqZU-S%2Bj4j%2BSrJ_4_prP3G1Q3EvF_ropFqGkcAZo7T6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Celeron N3350 and VT-d

2018-10-10 Thread newpath7
On Monday, October 8, 2018 at 8:42:50 PM UTC-6, awokd wrote:
> @gmail.com:
> > On Monday, October 8, 2018 at 8:10:17 AM UTC-6, awokd wrote:
> >>
> >>
> >>> Now, for the actual question. :) The installer reports missing 
> >>> IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron 
> >>> N3350 which, according to 
> >>> https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-,
> >>>  should have VT-d (unless it needs a specific kind of VT-d?). I am not 
> >>> sure about IOMMU, perhaps it is missing. Does the error message list 
> >>> those as alternatives of the same thing? Or is it that I may have VT-d 
> >>> but not IOMMU, and the error just lists them all if just one has not been 
> >>> detected?
> >>
> >> Did you enable the possibly multiple virtualization options in your UEFI
> >> config?
> > 
> > There are actually no virtualization options in my UEFI config. I do get to 
> > turn off secure boot and some TSC stuff, but not much else. There's no vmx 
> > flag in /proc/cpuinfo (less that file after ctrl+f2 during installation), 
> > but apparently Qubes is not complaining about a lack of VT-x. There is a 
> > hypervisor flag, however.
> 
> It's possible your CPU supports the features, but not your motherboard's 
> chipset and/or UEFI. Not having any options in the config for it is 
> generally a bad sign. Check to see if there's a firmware update 
> available for your board. VT-d implies there's at least one IOMMU, and 
> VT-x is present on everything with VT-d.

Indeed... doing more research it does seem that it is not simply a matter at 
looking at what the chipset supports. Updated UEFI to its latest version, and 
still there is no option for virtualization settings.

Since I used default installation settings and to encrypt drive (actually to a 
flash drive) I had to gpart it to have fat32 partition with /boot info (used 
the installer structure as example but with files that were actually installed 
to the encrypted partition.)

Finally logged in. qubes-hcl-report gives HVM active, I/O MMU not active, 
HAP/SLAT Yes, TPM Device not found (UEFI settings has something about TPM), 
Remapping No. This is for an Acer Aspire ES1 432. I'll still use Qubes this 
way, knowing full well that without VT-d, a lot of protection (ie against DMA 
attacks) is disabled. I'll just cross my fingers that perhaps a future firmware 
update will allow VT-d to be turned on, if the motherboard supports it.

Thanks for the pointers!


Cheers

-- 
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/9732c1ec-58ac-4750-9603-8cb6cbd5c0b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: debian-9 template

2018-10-10 Thread Beto HydroxyButyrate
On 10/11/18 6:25 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 10, 2018 at 05:24:33AM -0700, b...@damon.com wrote:
> > On Friday, April 27, 2018 at 10:46:08 PM UTC+10, higgin...@gmail.com
> wrote:
> > ...
>
> > I have been plagued with this issue ever since heeding the call to
> upgrade whonix-13 to whonix-14.  All my whonix-14 templates are useless.
>
> > I followed the steps carefully, removing / reinstalling.  No errors.
>
> > user@host:~$ sudo dmesg | grep segf
> > [   11.396489] qubesdb-daemon[232]: segfault at 7994802abff8 ip
> 799480098f64 sp 7994802ac000 error 6 in
> ld-2.24.so[79948008f000+23000]
> > [   12.342682] qrexec-agent[648]: segfault at 70d5257f6ff8 ip
> 70d5255f3355 sp 70d5257f7000 error 6 in
> ld-2.24.so[70d5255dd000+23000]
> > [   15.903799] qrexec-agent[789]: segfault at 70d5257f6ff8 ip
> 70d5255f3355 sp 70d5257f7000 error 6 in
> ld-2.24.so[70d5255dd000+23000]
> > [ 1524.123824] qrexec-fork-ser[4430]: segfault at 7b59263a8ff8 ip
> 7b59261a2355 sp 7b59263a9000 error 6 in
> ld-2.24.so[7b592618c000+23000]
> > [ 1547.347882] qrexec-fork-ser[4456]: segfault at 7b59263a8ff8 ip
> 7b59261a2355 sp 7b59263a9000 error 6 in
> ld-2.24.so[7b592618c000+23000]
> > [ 1594.046093] qrexec-fork-ser[4527]: segfault at 7b59263a8ff8 ip
> 7b59261a2355 sp 7b59263a9000 error 6 in
> ld-2.24.so[7b592618c000+23000]
> > [ 2963.435851] qrexec-fork-ser[5300]: segfault at 7b59263a8ff8 ip
> 7b59261a2355 sp 7b59263a9000 error 6 in
> ld-2.24.so[7b592618c000+23000]
> > [ 3145.932364] qrexec-fork-ser[5413]: segfault at 7b59263a8ff8 ip
> 7b59261a2355 sp 7b59263a9000 error 6 in
> ld-2.24.so[7b592618c000+23000]
>
> > Everything is hosed.
>
> > If anyone has a fix, I would appreciate knowing it.
>
> This looks to be the issue described here:
> https://github.com/QubesOS/qubes-issues/issues/4349
>
> The proper fix is in testing repository right now, you can either
> install it[1], or apply a workaround listed in that ticket (add noxsave
> to kernelopts of that template and VMs based on it). Actually, you may
> need to apply workaround temporarily to be able to install updates...
>
> [1] https://www.qubes-os.org/doc/software-update-vm/#debian
>
Thanks for that!

I should have figured out how to post to qubes-users much earlier,
rather than bashing my head against the wall for so long.


-- 
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/e31d1b2a-1dd1-b724-a807-4a7232d12fd9%40damon.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes and Mega Cloud App using

2018-10-10 Thread Black Beard

Hey guys,

1000 thx to both of your helpfull answers.

I downloaded the stuff before into the Cloud and now tried download it. 

For this i used the Domain:work and made the volume up to 100 GB space and 
4096mb memory. 

The download stops by 100% and all works very slow. Its hard to close the VM on 
the normal way. 

Is there any way to download the files without this probleme? 

Or configs ?? Maybe an update to the Fedora template or anouther configs ?

Next time iwill 

following your steps what both of you wrote. 

Thx for all 

-- 
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/03621e71-b826--8de5-2ad88e0e2b5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] [Qubes-4.0] Vanishing Packages on TemplateVMs

2018-10-10 Thread 'Modprobe' via qubes-users
‐‐‐ Original Message ‐‐‐
On Wednesday, October 10, 2018 3:13 PM, Stuart Perkins 
 wrote:

> On Wed, 10 Oct 2018 19:14:01 +
> "'Modprobe' via qubes-users" qubes-users@googlegroups.com wrote:
>
> > ** General intro stuff, not terribly important, tl;dr as appropriate **
> > Hi, all! Qubes newbie here; I installed Qubes on my new laptop just to see 
> > what happens and now I'm bumbling my way along, using it and reading docs, 
> > trying to get a feel for how things get done. For the most part, it's kind 
> > of awesome, but every now and then there's something that confuses me, and 
> > right now the most seriously confusing thing is that packages which I 
> > installed have a nasty tendency to uninstall themselves, and I'm not sure 
> > why...
> > Now a relevant bit of context is that I'm one of those nasty users who 
> > never does things according to the official guidelines and stuff, so I've 
> > made a number of tweaks to my installation to fit my habits. I'll do my 
> > best to keep track of what's unusual on my box and make those things clear 
> > up front, but I might forget something I've done, so please bear with me.
> > ** Quirks about my Environment **
> > Right now, the main quirk on my box, I think, is that I really, really 
> > don't seem to like Fedora, and I really, really do like Arch, so I'm using 
> > the Arch template for most of my AppVMs. Building and installing the Arch 
> > template on Qubes 4 was a bumpy process (I used the instructions for Qubes 
> > 3.2 here, and had to improvise a fair bit as things didn't work), and I'm 
> > not 100% sure it went totally right, but I got to the end of the 
> > instructions and mostly it seems to work...
> > ** My actual issue **
> > Except for the vanishing packages. So every now and then, I install a 
> > package into the TemplateVM (NOT the AppVM; I expect those packages to 
> > vanish when I reboot the AppVM, but packages in the TemplateVM should stick 
> > around until I remove them, yeah?) and it works and shows up correctly for 
> > a while, but some time later (often, I'm pretty certain, without any kind 
> > of reboot in the interim), the package is simply gone. I have to reinstall 
> > it cuz it's just not there anymore. I'm pretty darn sure this is not 
> > expected behavior, but maybe I'm just not understanding something.
> > It seems to be more prevalent for some packages than others; for instance, 
> > I've had AUR builds fail because `patch` wasn't installed, so I install 
> > patch and try again, and it works. The automake and autoconf packages do it 
> > too, but less often than patch. I've installed patch several times on my 
> > Arch TemplateVM by now, but it keeps disappearing behind my back:
> >
> > > [user@archlinux ~]$ history | grep patch
> > > 57 pikaur -S patch
> > > 200 pikaur -S patch
> > > 204 pikaur -S patch
> > > 276 pikaur -S patch
> > > 291 pikaur -S automake patch autoconf
> > > 292 history | grep patch
> >
> > So that's my main confusion with Qubes right now; I'm hoping someone can 
> > help me understand what's going on. Am I making some dumb mistake? Thanks 
> > for your time! =)
> > --
> > Nathan
>
> In Qubes, the Templates are where software is installed. If you install 
> software in an appVM, it will go away when you shutdown the appVM. This is to 
> implement a separation of software and data, and is one of the foundations of 
> Qubes.
>
> If you want software available in a template based appVM, you need to install 
> it in the template. You can install uncertain software in an appVM for 
> evaluation and not worry if it doesn't work, as it will go away when you 
> poweroff the appVM...but then you need to install that same software in the 
> Template in order to make it available in the appVM.
>
> Stuart


Hi, Stuart, and thanks, but as I described in the second sentence of the ** My 
actual issue **, I am aware of this and I am talking about packages installed 
into the TemplateVM, NOT the AppVM. I apologize if this got lost in the mix; I 
confess I am a tad verbose sometimes. :)

-- 
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/WiALhHuJXvsg7lw-n1k7dgtJfZaSXFLb-CA1tl-7hJUqgvcAcmWsW_znpgnw3G8D-uJXGfdOvN6CE9vqaV_fkJXHRZsF3Opju7RR8r6hXHA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: debian-9 template

2018-10-10 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Oct 10, 2018 at 05:24:33AM -0700, b...@damon.com wrote:
> On Friday, April 27, 2018 at 10:46:08 PM UTC+10, higgin...@gmail.com wrote:
> ...
> 
> I have been plagued with this issue ever since heeding the call to upgrade 
> whonix-13 to whonix-14.  All my whonix-14 templates are useless.
> 
> I followed the steps carefully, removing / reinstalling.  No errors.
> 
> user@host:~$ sudo dmesg | grep segf
> [   11.396489] qubesdb-daemon[232]: segfault at 7994802abff8 ip 
> 799480098f64 sp 7994802ac000 error 6 in ld-2.24.so[79948008f000+23000]
> [   12.342682] qrexec-agent[648]: segfault at 70d5257f6ff8 ip 
> 70d5255f3355 sp 70d5257f7000 error 6 in ld-2.24.so[70d5255dd000+23000]
> [   15.903799] qrexec-agent[789]: segfault at 70d5257f6ff8 ip 
> 70d5255f3355 sp 70d5257f7000 error 6 in ld-2.24.so[70d5255dd000+23000]
> [ 1524.123824] qrexec-fork-ser[4430]: segfault at 7b59263a8ff8 ip 
> 7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
> [ 1547.347882] qrexec-fork-ser[4456]: segfault at 7b59263a8ff8 ip 
> 7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
> [ 1594.046093] qrexec-fork-ser[4527]: segfault at 7b59263a8ff8 ip 
> 7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
> [ 2963.435851] qrexec-fork-ser[5300]: segfault at 7b59263a8ff8 ip 
> 7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
> [ 3145.932364] qrexec-fork-ser[5413]: segfault at 7b59263a8ff8 ip 
> 7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
> 
> Everything is hosed.
> 
> If anyone has a fix, I would appreciate knowing it.

This looks to be the issue described here:
https://github.com/QubesOS/qubes-issues/issues/4349

The proper fix is in testing repository right now, you can either
install it[1], or apply a workaround listed in that ticket (add noxsave
to kernelopts of that template and VMs based on it). Actually, you may
need to apply workaround temporarily to be able to install updates...

[1] https://www.qubes-os.org/doc/software-update-vm/#debian

- -- 
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/THMrX1ywFAlu+YEUACgkQ24/THMrX
1yzJmQf/b1fFHTpg8noeSUMtKSPw/LRbj9GNYQ7U8YBX5IbpgPLex6oGG9YBIEy0
U0VMPomxKnUtshM4+bAsRJhMSs6VQ/LxWNtjTUEtKPxIizj4e7Y1u37Abh4T5TJy
td7vtKkuuEfUqIWfhjjHe9WCjVMHn7PeWV8lfNzB3/2/m1BIngedhPYy8mNLnY+Y
CT7laBNR3LvFYVl9VXiwOBKCBM6EcAh5TA8k6Dv36pwOiBhGpYBcP2RwCn3nBVb4
wVv6XkOy3ZPX9okiJkGzBEFn3YzqfWTjKStvHVk0x6BX7dWRP4iChc2E4tcNa6hj
r4Ak9U912AIZfmh3RH3lnXywRpRihg==
=FW0q
-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/20181010202541.GB5083%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] [Qubes-4.0] Vanishing Packages on TemplateVMs

2018-10-10 Thread Stuart Perkins



On Wed, 10 Oct 2018 19:14:01 +
"'Modprobe' via qubes-users"  wrote:

>** General intro stuff, not terribly important, tl;dr as appropriate **
>Hi, all! Qubes newbie here; I installed Qubes on my new laptop just to see 
>what happens and now I'm bumbling my way along, using it and reading docs, 
>trying to get a feel for how things get done. For the most part, it's kind of 
>awesome, but every now and then there's something that confuses me, and right 
>now the most seriously confusing thing is that packages which I installed have 
>a nasty tendency to uninstall themselves, and I'm not sure why...
>
>Now a relevant bit of context is that I'm one of those nasty users who never 
>does things according to the official guidelines and stuff, so I've made a 
>number of tweaks to my installation to fit my habits. I'll do my best to keep 
>track of what's unusual on my box and make those things clear up front, but I 
>might forget something I've done, so please bear with me.
>
>** Quirks about my Environment **
>Right now, the main quirk on my box, I think, is that I really, really don't 
>seem to like Fedora, and I really, really do like Arch, so I'm using the Arch 
>template for most of my AppVMs. Building and installing the Arch template on 
>Qubes 4 was a bumpy process (I used the instructions for Qubes 3.2 
>[here](https://www.qubes-os.org/doc/building-archlinux-template/), and had to 
>improvise a fair bit as things didn't work), and I'm not 100% sure it went 
>totally right, but I got to the end of the instructions and mostly it seems to 
>work...
>
>** My actual issue **
>Except for the vanishing packages. So every now and then, I install a package 
>into the TemplateVM (NOT the AppVM; I expect those packages to vanish when I 
>reboot the AppVM, but packages in the TemplateVM should stick around until I 
>remove them, yeah?) and it works and shows up correctly for a while, but some 
>time later (often, I'm pretty certain, without any kind of reboot in the 
>interim), the package is simply gone. I have to reinstall it cuz it's just not 
>there anymore. I'm pretty darn sure this is not expected behavior, but maybe 
>I'm just not understanding something.
>
>It seems to be more prevalent for some packages than others; for instance, 
>I've had AUR builds fail because `patch` wasn't installed, so I install patch 
>and try again, and it works. The automake and autoconf packages do it too, but 
>less often than patch. I've installed patch several times on my Arch 
>TemplateVM by now, but it keeps disappearing behind my back:
>
>> [user@archlinux ~]$ history | grep patch
>>57  pikaur -S patch
>>   200  pikaur -S patch
>>   204  pikaur -S patch
>>   276  pikaur -S patch
>>   291  pikaur -S automake patch autoconf
>>   292  history | grep patch
>
>So that's my main confusion with Qubes right now; I'm hoping someone can help 
>me understand what's going on. Am I making some dumb mistake? Thanks for your 
>time! =)
>
>--
>Nathan
>

In Qubes, the Templates are where software is installed.  If you install 
software in an appVM, it will go away when you shutdown the appVM.  This is to 
implement a separation of software and data, and is one of the foundations of 
Qubes.

If you want software available in a template based appVM, you need to install 
it in the template.  You can install uncertain software in an appVM for 
evaluation and not worry if it doesn't work, as it will go away when you 
poweroff the appVM...but then you need to install that same software in the 
Template in order to make it available in the appVM.

Stuart

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


[qubes-users] [Qubes-4.0] Vanishing Packages on TemplateVMs

2018-10-10 Thread 'Modprobe' via qubes-users
** General intro stuff, not terribly important, tl;dr as appropriate **
Hi, all! Qubes newbie here; I installed Qubes on my new laptop just to see what 
happens and now I'm bumbling my way along, using it and reading docs, trying to 
get a feel for how things get done. For the most part, it's kind of awesome, 
but every now and then there's something that confuses me, and right now the 
most seriously confusing thing is that packages which I installed have a nasty 
tendency to uninstall themselves, and I'm not sure why...

Now a relevant bit of context is that I'm one of those nasty users who never 
does things according to the official guidelines and stuff, so I've made a 
number of tweaks to my installation to fit my habits. I'll do my best to keep 
track of what's unusual on my box and make those things clear up front, but I 
might forget something I've done, so please bear with me.

** Quirks about my Environment **
Right now, the main quirk on my box, I think, is that I really, really don't 
seem to like Fedora, and I really, really do like Arch, so I'm using the Arch 
template for most of my AppVMs. Building and installing the Arch template on 
Qubes 4 was a bumpy process (I used the instructions for Qubes 3.2 
[here](https://www.qubes-os.org/doc/building-archlinux-template/), and had to 
improvise a fair bit as things didn't work), and I'm not 100% sure it went 
totally right, but I got to the end of the instructions and mostly it seems to 
work...

** My actual issue **
Except for the vanishing packages. So every now and then, I install a package 
into the TemplateVM (NOT the AppVM; I expect those packages to vanish when I 
reboot the AppVM, but packages in the TemplateVM should stick around until I 
remove them, yeah?) and it works and shows up correctly for a while, but some 
time later (often, I'm pretty certain, without any kind of reboot in the 
interim), the package is simply gone. I have to reinstall it cuz it's just not 
there anymore. I'm pretty darn sure this is not expected behavior, but maybe 
I'm just not understanding something.

It seems to be more prevalent for some packages than others; for instance, I've 
had AUR builds fail because `patch` wasn't installed, so I install patch and 
try again, and it works. The automake and autoconf packages do it too, but less 
often than patch. I've installed patch several times on my Arch TemplateVM by 
now, but it keeps disappearing behind my back:

> [user@archlinux ~]$ history | grep patch
>57  pikaur -S patch
>   200  pikaur -S patch
>   204  pikaur -S patch
>   276  pikaur -S patch
>   291  pikaur -S automake patch autoconf
>   292  history | grep patch

So that's my main confusion with Qubes right now; I'm hoping someone can help 
me understand what's going on. Am I making some dumb mistake? Thanks for your 
time! =)

--
Nathan

-- 
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/0UUc__GD6Do3bHyZj4mOuLwppBEy6jUb_1FI0uh6ehy8HiTgKtnziiyR9RR9fqJGBL99Br2zSwSWmvDMO-hUlDLzfKDqRBEbteNxOxPqNfo%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] nftables vs iptables

2018-10-10 Thread Chris Laprise

On 10/10/2018 01:47 PM, David Hobach wrote:

On 10/10/18 3:33 PM, unman wrote:

On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:

On 10/10/18 3:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
    > On 01/10/2018 03:47 PM, Connor Page wrote:
    >> The official templates use nftables so shouldn’t be 
mixed with
iptables. I didn’t have time to learn about nftables, so just 
removed

nftables package from debian 9 template. YMMV.
    >
    > Hmmm, I was just thinking how Qubes' own guest scripts 
still use

    > iptables even in fedora-26.
    >
    > IIUC, iptables and nft are two different interfaces
to netfilter. I
    > don't know if it really matters, at least for the R4.0 
window. I'd

    > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables 
in R4.


The qubes docs don't clarify much.  The qubes firewall scripts 
use

nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The 
upgrade
instructions (going from R3.2 to R4) did not mention 
converting rules
from iptables to nftables.  It looks like other related 
projects (one

example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I 
get the
impression that nftables and iptables should not both by used 
at the

same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, 
Fedora 28

template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used 
in Fedora

Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands 
only, with
the intention to transition to nftables (or that other new 
interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is 
just

starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces 
nftables (in

that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given 
how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) 
IMHO it
wasn't worth it. The OP's post confirms there's quite some 
confusion
about how it interacts with iptables, and the official 
documentation is

far from helpful.
I'm quite proficient with iptables and networking in general but 
it took
me half an hour to understand how to tweak Qubes' nftables rules 
last
time I wanted to change something in the firewall, while I would 
have
done that task in less than one minute with iptables. I could 
have spent
a few hours learning nftables to improve the official doc but at 
my age
I prefer to spend time learning tech that significantly improves 
things

(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 





I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). 


   qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in 
effect.  And
these are different sets of rules.  It's not that the iptables 
command
and the nft command are just two user interfaces showing the same 
packet
filtering rules.  They are different packet filtering rules.  This 
seems

like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS/qubes-issues/issues?


You'll 

[qubes-users] Seahorse-tool with Split GPG

2018-10-10 Thread 21ea20da
Good afternoon,

I have recently joined the QubesOS crew, and I have been trying to replicate a 
similar usability than my previous Ubuntu system for a few days now. One of the 
things I have not been able to fix is the integration of seahorse-tool 
contextual "Encrypt/Decrypt" GUI menu with the splitGPG technique.

Following the documentation published online, I have imported my private PGP 
key to an isolated-VM called "work-gpg", and from the "personal" VM I am trying 
to use that private key to decrypt files by right-clicking on the appropriate 
file, and clicking "Decrypt" on the contextual menu.

The initial configuration on "personal" VM, when you click "Decrypt" on the GUI 
menu, runs:
seahorse-tool --decrypt

As that command is running locally (and the privkey is not in that VM, but in 
"work-gpg", I tried to replace it with:
qubes-gpg-client-wrapper
and
qubes-gpg-client-wrapper -d

However it does not work when using the contextual menu. But if I run, 
manually, in the console, the following:
qubes-gpg-client-wrapper -o outputFilename -d fileToDecrypt.pgp

it works flawlessly.

Do you happen to have any idea as of how I can implement this, so I can 
integrate qubes-gpg-client-wrapper with seahorse-tool GUI menus in Nautilus?

Thanks a lot!

-- 
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/f60ab2df-9753-4863-b8c9-9c783944a35d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] nftables vs iptables

2018-10-10 Thread David Hobach

On 10/10/18 3:33 PM, unman wrote:

On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:

On 10/10/18 3:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
    > On 01/10/2018 03:47 PM, Connor Page wrote:
    >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
    >
    > Hmmm, I was just thinking how Qubes' own guest scripts still use
    > iptables even in fedora-26.
    >
    > IIUC, iptables and nft are two different interfaces
to netfilter. I
    > don't know if it really matters, at least for the R4.0 window. I'd
    > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The upgrade
instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in Fedora
Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it took
me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have spent
a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500



I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes).
   qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in effect.  And
these are different sets of rules.  It's not that the iptables command
and the nft command are just two user interfaces showing the same packet
filtering rules.  They are different packet filtering rules.  This seems
like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS/qubes-issues/issues?


You'll definitely get more visibility on qubes-devel.

FWIW I'm not concerned about the complexity itself: 

Re: [qubes-users] nftables vs iptables

2018-10-10 Thread Ivan Mitev




On 10/10/18 4:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
   > On 01/10/2018 03:47 PM, Connor Page wrote:
   >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
   >
   > Hmmm, I was just thinking how Qubes' own guest scripts still use
   > iptables even in fedora-26.
   >
   > IIUC, iptables and nft are two different interfaces
to netfilter. I
   > don't know if it really matters, at least for the R4.0 window. I'd
   > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The upgrade
instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in Fedora
Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it took
me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have spent
a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500



I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes).
  qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in effect.  And
these are different sets of rules.  It's not that the iptables command
and the nft command are just two user interfaces showing the same packet
filtering rules.  They are different packet filtering rules.  This seems
like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS/qubes-issues/issues?


You'll definitely get more visibility on qubes-devel.

FWIW I'm not concerned about the complexity itself: I trust the Qubes devs
not to mess up.
IMHO the problem is that people proficient with iptables are not 

Re: [qubes-users] Deleting app VMs in Qubes 4.0 doesn't free up disk space

2018-10-10 Thread 'floasretch' via qubes-users
‐‐‐ Original Message ‐‐‐
On Wednesday, October 10, 2018 6:52 AM, unman  
wrote:

> I admire your persistence in continuing to remove qubes.
>
> Have you tried running 'sudo fstrim -av' in dom0?

After I already trimmed / in dom0 as I mentioned (and it reported about 5GB 
freed), I ran sudo fstrim -av per your suggestion, and it reported 0 bytes 
trimmed.

On further investigation, I discovered that /var/log/xen/xenstored-trace.log in 
dom0 was 155GB.

So I did sudo truncate /var/log/xen/xenstored-trace.log --size 0
Then again sudo fstrim -av, and this time for / it reported 80.7GiB trimmed. (I 
don't know why not all 155GB trimmed.)

But qvm-pool -vi lvm still reports 99% HD usage (468GB used out of 473GB size 
for pool00)! The HD is 500GB, so trimming 80.7GiB should have freed 17%.

OTOH, sudo lvs did report that pool00 data% dropped from 99 to 67, and meta% 
dropped from 55 to 39. So the problem is clearly with Qubes, not LVM.

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


Re: [qubes-users] XL VM connectivity to Qubes Network

2018-10-10 Thread 3mptyy
> I believe that is indeed the aim.
> You can either set to 255.255.255.0 or add specific route, as you have
> done. (Did you set a return route on the destination also?)

The return route is automatically added to the Proxy with the vif-route-qubes, 
and the destination send all traffic to the proxy. The vif-route-qubes seems to 
work perfectly, I noticed no difference between a Qube and a HVM using the 
script...

> The next step would be to examine the rules on the proxy to make sure
> that you are allowing the traffic through the ProxyVM. You could listen
> on the interface that's attached to 10.137.0.8 to see if traffic is
> outbound from there.
> 
> unman

I removed all firewall rules (from Proxy and Qube Server), here's the conf :

# iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain QBS-FORWARD (0 references)
target prot opt source   destination

# iptables -t raw --list

Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Always the same result, Qube client connects to Qube server perfectly, HVM 
doesn't connect to Qube server.

I captured traffic this afternoon and I think it's an ARP problem... Here's a 
working ARP session when I connect from Qube client to Qube Server :

QUBE CLIENT ARP (from its specific vif) :

18:32:09.483319 ARP, Request who-has 10.137.0.12 tell 10.137.0.10, length 28
18:32:09.483502 ARP, Reply 10.137.0.12 is-at 00:16:3e:5e:6c:00, length 28
18:32:09.746948 ARP, Request who-has 10.137.0.10 tell 10.137.0.12, length 28
18:32:09.746970 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

QUBE SERVER ARP (from its specific vif) :

18:32:09.483343 ARP, Request who-has 10.137.0.8 tell 10.137.0.10, length 28
18:32:09.483536 ARP, Reply 10.137.0.8 is-at 00:16:3e:5e:6c:00, length 28
18:32:09.542795 ARP, Request who-has 10.137.0.10 tell 10.137.0.8, length 28
18:32:09.542817 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

--

and here is the ARP session from HVM to Qube Server :

HVM ARP :

18:33:34.793593 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:33:34.793631 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

18:34:06.537570 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:34:06.537609 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

18:34:38.793679 ARP, Request who-has 10.137.0.10 tell 10.137.0.200, length 28
18:34:38.793699 ARP, Reply 10.137.0.10 is-at fe:ff:ff:ff:ff:ff, length 28

QUBE SERVER ARP :

Nothing :(

--

It's like the Proxy does not forward traffic to the destination vif, but 
there's no firewall rule blocking it, so I'm out of ideas...

Other observations : ping is working between HVM and Proxy. No luck between HVM 
and Qube Server. 

I saw that every Qube had the same MAC address (I don't understand how it's 
possible, I'd really appreciate a document explaining how Qubes Networking 
work...) so I tried to set this same MAC address to the HVM, no more luck.

Any help appreciated ! I'm feeling desperate right now :(

-- 
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/133d75e3-bebf-49dd-ac0f-90c3ec680fb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Changing USB Controllers

2018-10-10 Thread unman
On Mon, Oct 08, 2018 at 07:27:23PM -0700, Alex Winter wrote:
> Here are the usb controllers when I type in 'sudo lspci -v' 
> 
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USb xHCI (Rev 05) (prog-if 30 [XHCI])
>  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
>  Flags: bus master, medium devsel, latency 0, IRQ 57
>  Memory at f7b0 (64-bit, non-prefetchable) [size=64k]
>  Capabilities: [70] Power Management version 2
>  Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
>  Kernel driver in use: xhci_hcd
>  Kernel modules: xhci_pci
> 
> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USb EHCI #2 (Rev 05) (prog-if 20 [EHCI])
>  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
>  Flags: bus master, medium devsel, latency 0, IRQ 16
>  Memory at f7b18000 (32-bit, non-pcopy and pasterefetchable) [size=1k]
>  Capabilities: [50] Power Management version 2
>  Capabilities: [58] Debug port: BAR=1 offset=00a0
>  Capabilities: [98] PCI Advanced Features
>  Kernel driver in use: ehci-pci
>  Kernel modules: ehci_pci
> 
> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USb EHCI #1 (Rev 05) (prog-if 20 [EHCIReciever])
>  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
>  Flags: bus master, medium devsel, latency 0, IRQ 23
>  Memory at f7b17000 (32-bit, non-prefetchable) [size=1k]
>  Capabilities: [50] Power Management version 2
>  Capabilities: [58] Debug port: BAR=1 offset=00a0
>  Capabilities: [98] PCI Advanced Features
>  Kernel driver in use: ehci-pci
>  Kernel modules: ehci_pci
> 
> when I type in 'sudo lsusb -v' Here are the buses.  
> 
> Bus 002 Device 002: ID 8087:8000 Intel Corp.
> 
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> iProduct 2 EHCI Host Controller
> iSerial  1 :00:1d.0
> 
> Bus 001 Device 002: ID 8087:8008 Intel Corp.
> 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> iproduct 2 EHCI Host Controller
> iSerial  1 :00:1a.0
> 
> Bus 004 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd
> 
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> iProduct 2 xHCI Host Controller
> iSerial  1 :00:14.0
> 
> Bus 003 Device 007: ID 1770:ff00
> 
> Bus 003 Device 005: ID 8087:07dc Intel Corp.
> 
> Bus 003 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 
> receiver
> 
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> iProduct 2 xHCI Host Controller
> iSerial  1 :00:14.0
> 

Without knowing your laptop or exact setup I'm working a bit blind.
I think you say you have a usbVM and are running qubes from a USB stick
- is that right?
You haven't said *which* controller your ports all use.

>From the listing it's clear you have usb2 and usb3 controllers, and it
may be that ALL your ports are 2/3. More info needed please.
I'll throw out some wild suggestions:

Hide one of the controllers on the kernel command line(say the xhci).
Disable ehci in usbVM, and use only USB3 devices with the usbVM.

It might be possible to delete one of the devices in dom0, and still have
it available in qubes. (I mean literally rm /dev/bus/usb/001)

You could unbind a pci device early in boot. I've done this with Xen
before, to have one port in dom0 and the rest available to xen-pciback,
but haven't tried it with Qubes.

You could use udev to block two of the ports in dom0, so that they are
only available in the usbVM.

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


Re: [qubes-users] nftables vs iptables

2018-10-10 Thread unman
On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:
> On 10/10/18 3:14 PM, unman wrote:
> > On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:
> > > 
> > > 
> > > On 10/9/18 7:44 PM, mfreemon wrote:
> > > > On 10/8/18 10:56 AM, mfreemon wrote:
> > > > > On 10/2/18 2:25 AM, Ivan Mitev wrote:
> > > > > > On 10/2/18 1:32 AM, Chris Laprise wrote:
> > > > > > > On 10/01/2018 05:48 PM, mfreemon wrote:
> > > > > > > > On 1/11/18 3:01 PM, Chris Laprise wrote:
> > > > > > > >    > On 01/10/2018 03:47 PM, Connor Page wrote:
> > > > > > > >    >> The official templates use nftables so shouldn’t be mixed 
> > > > > > > > with
> > > > > > > > iptables. I didn’t have time to learn about nftables, so just 
> > > > > > > > removed
> > > > > > > > nftables package from debian 9 template. YMMV.
> > > > > > > >    >
> > > > > > > >    > Hmmm, I was just thinking how Qubes' own guest scripts 
> > > > > > > > still use
> > > > > > > >    > iptables even in fedora-26.
> > > > > > > >    >
> > > > > > > >    > IIUC, iptables and nft are two different interfaces
> > > > > > > > to netfilter. I
> > > > > > > >    > don't know if it really matters, at least for the R4.0 
> > > > > > > > window. I'd
> > > > > > > >    > prefer to put the syntax change (for docs) off until
> > > > > > > > a later release.
> > > > > > > > 
> > > > > > > > I was recently thrown by the mix of both nftables and iptables 
> > > > > > > > in R4.
> > > > > > > > 
> > > > > > > > The qubes docs don't clarify much.  The qubes firewall scripts 
> > > > > > > > use
> > > > > > > > nft. Most of the discussion on the qubes website documentation 
> > > > > > > > is
> > > > > > > > about iptables, but there are also a few mentions of nft.  The 
> > > > > > > > upgrade
> > > > > > > > instructions (going from R3.2 to R4) did not mention converting 
> > > > > > > > rules
> > > > > > > > from iptables to nftables.  It looks like other related 
> > > > > > > > projects (one
> > > > > > > > example is qubes-tunnel) is using iptables.
> > > > > > > > 
> > > > > > > > Just reading a few things and trying to come up to speed, I get 
> > > > > > > > the
> > > > > > > > impression that nftables and iptables should not both by used 
> > > > > > > > at the
> > > > > > > > same time.  Even if technically possible (i.e. both sets of 
> > > > > > > > rules
> > > > > > > > applied correctly), it strikes me as not a great idea to 
> > > > > > > > maintain
> > > > > > > > packet filtering rules in two different ways.
> > > > > > > > 
> > > > > > > > What is the best practice recommendation on this (for R4, 
> > > > > > > > Fedora 28
> > > > > > > > template)?  Are we to be using, exclusively, nftables in R4?
> > > > > > > 
> > > > > > > The last I read about this (for 4.0) is that nftables is used in 
> > > > > > > Fedora
> > > > > > > Qubes code, but Debian Qubes is still using iptables. That
> > > > > > > still appears
> > > > > > > to be the case since nftables is not installed in my
> > > > > > > debian-9 templates.
> > > > > > > 
> > > > > > > I've submitted qubes-tunnel to Qubes with iptables commands only, 
> > > > > > > with
> > > > > > > the intention to transition to nftables (or that other new 
> > > > > > > interface in
> > > > > > > Linux, name escapes me just now) for Qubes 4.1. Someone who is 
> > > > > > > just
> > > > > > > starting a project might be better off going with nftables.
> > > > > > 
> > > > > > ... until yet another packet filtering mechanism replaces nftables 
> > > > > > (in
> > > > > > that case, bpfilter [1]).
> > > > > > 
> > > > > > I understand the rationale behind using nftables [2] but given how 
> > > > > > it is
> > > > > > widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO 
> > > > > > it
> > > > > > wasn't worth it. The OP's post confirms there's quite some confusion
> > > > > > about how it interacts with iptables, and the official 
> > > > > > documentation is
> > > > > > far from helpful.
> > > > > > I'm quite proficient with iptables and networking in general but it 
> > > > > > took
> > > > > > me half an hour to understand how to tweak Qubes' nftables rules 
> > > > > > last
> > > > > > time I wanted to change something in the firewall, while I would 
> > > > > > have
> > > > > > done that task in less than one minute with iptables. I could have 
> > > > > > spent
> > > > > > a few hours learning nftables to improve the official doc but at my 
> > > > > > age
> > > > > > I prefer to spend time learning tech that significantly improves 
> > > > > > things
> > > > > > (eg. Qubes OS over standard linux distribution) over loosing time
> > > > > > learning stuff that is only marginally better.
> > > > > > Anyway - I digress :)
> > > > > > 
> > > > > > [1] https://old.lwn.net/Articles/747551/
> > > > > > [2]
> > > > > > https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500
> > > > > > 
> > > > > 
> > > > > I'm concerned about the confusion and unnecessary complexity here.
> > > > 

Re: [qubes-users] nftables vs iptables

2018-10-10 Thread Illidan Pornrage

On 10/10/18 3:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
   > On 01/10/2018 03:47 PM, Connor Page wrote:
   >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
   >
   > Hmmm, I was just thinking how Qubes' own guest scripts still use
   > iptables even in fedora-26.
   >
   > IIUC, iptables and nft are two different interfaces
to netfilter. I
   > don't know if it really matters, at least for the R4.0 window. I'd
   > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The upgrade
instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in Fedora
Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it took
me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have spent
a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500



I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes).
  qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in effect.  And
these are different sets of rules.  It's not that the iptables command
and the nft command are just two user interfaces showing the same packet
filtering rules.  They are different packet filtering rules.  This seems
like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS/qubes-issues/issues?


You'll definitely get more visibility on qubes-devel.

FWIW I'm not concerned about the complexity itself: I trust the Qubes devs
not to mess up.
IMHO the problem is that people proficient with iptables are not willing 

Re: [qubes-users] nftables vs iptables

2018-10-10 Thread Illidan Pornrage

On 10/9/18 8:18 PM, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
  > On 01/10/2018 03:47 PM, Connor Page wrote:
  >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
  >
  > Hmmm, I was just thinking how Qubes' own guest scripts still use
  > iptables even in fedora-26.
  >
  > IIUC, iptables and nft are two different interfaces to 
netfilter. I
  > don't know if it really matters, at least for the R4.0 window. 
I'd
  > prefer to put the syntax change (for docs) off until a later 
release.


I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The 
upgrade

instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in 
Fedora
Qubes code, but Debian Qubes is still using iptables. That still 
appears
to be the case since nftables is not installed in my debian-9 
templates.


I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new 
interface in

Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how 
it is

widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it 
took

me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have 
spent

a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 



I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that 
software such Qubes needs to be solid on (in both design approach and 
implementation detail).


Is the Qubes team confident in the current situation, such that users 
of Qubes should not be concerned?


nb.  This is not meant to be a criticism at all.  I very much 
appreciate the hard (and complicated) work going into Qubes.  I'm 
just looking to understand the current situation better so as to 
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic 
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). 
  qubes-firewall-user-script also specifies iptables rules.  But 
qvm-firewall implements the rules it manages using nftables.  So the 
firewall VMs have both iptables rules and nftables rules in effect.  
And these are different sets of rules.  It's not that the iptables 
command and the nft command are just two user interfaces showing the 
same packet filtering rules.  They are different packet filtering 
rules.  This seems like a receipt for disaster.


Is this the wrong forum for this discussion?  Should this be on 
qubes-devel, or an issue in qubes-issues at 
https://github.com/QubesOS/qubes-issues/issues?


You'll definitely get more visibility on qubes-devel.

FWIW I'm not concerned about the complexity itself: I trust the Qubes 
devs not to mess up.
IMHO the problem is that people proficient with iptables are not willing 
to spend time learning 

Re: [qubes-users] nftables vs iptables

2018-10-10 Thread unman
On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:
> 
> 
> On 10/9/18 7:44 PM, mfreemon wrote:
> > On 10/8/18 10:56 AM, mfreemon wrote:
> > > On 10/2/18 2:25 AM, Ivan Mitev wrote:
> > > > On 10/2/18 1:32 AM, Chris Laprise wrote:
> > > > > On 10/01/2018 05:48 PM, mfreemon wrote:
> > > > > > On 1/11/18 3:01 PM, Chris Laprise wrote:
> > > > > >   > On 01/10/2018 03:47 PM, Connor Page wrote:
> > > > > >   >> The official templates use nftables so shouldn’t be mixed with
> > > > > > iptables. I didn’t have time to learn about nftables, so just 
> > > > > > removed
> > > > > > nftables package from debian 9 template. YMMV.
> > > > > >   >
> > > > > >   > Hmmm, I was just thinking how Qubes' own guest scripts still use
> > > > > >   > iptables even in fedora-26.
> > > > > >   >
> > > > > >   > IIUC, iptables and nft are two different interfaces
> > > > > > to netfilter. I
> > > > > >   > don't know if it really matters, at least for the R4.0 window. 
> > > > > > I'd
> > > > > >   > prefer to put the syntax change (for docs) off until
> > > > > > a later release.
> > > > > > 
> > > > > > I was recently thrown by the mix of both nftables and iptables in 
> > > > > > R4.
> > > > > > 
> > > > > > The qubes docs don't clarify much.  The qubes firewall scripts use
> > > > > > nft. Most of the discussion on the qubes website documentation is
> > > > > > about iptables, but there are also a few mentions of nft.  The 
> > > > > > upgrade
> > > > > > instructions (going from R3.2 to R4) did not mention converting 
> > > > > > rules
> > > > > > from iptables to nftables.  It looks like other related projects 
> > > > > > (one
> > > > > > example is qubes-tunnel) is using iptables.
> > > > > > 
> > > > > > Just reading a few things and trying to come up to speed, I get the
> > > > > > impression that nftables and iptables should not both by used at the
> > > > > > same time.  Even if technically possible (i.e. both sets of rules
> > > > > > applied correctly), it strikes me as not a great idea to maintain
> > > > > > packet filtering rules in two different ways.
> > > > > > 
> > > > > > What is the best practice recommendation on this (for R4, Fedora 28
> > > > > > template)?  Are we to be using, exclusively, nftables in R4?
> > > > > 
> > > > > The last I read about this (for 4.0) is that nftables is used in 
> > > > > Fedora
> > > > > Qubes code, but Debian Qubes is still using iptables. That
> > > > > still appears
> > > > > to be the case since nftables is not installed in my
> > > > > debian-9 templates.
> > > > > 
> > > > > I've submitted qubes-tunnel to Qubes with iptables commands only, with
> > > > > the intention to transition to nftables (or that other new interface 
> > > > > in
> > > > > Linux, name escapes me just now) for Qubes 4.1. Someone who is just
> > > > > starting a project might be better off going with nftables.
> > > > 
> > > > ... until yet another packet filtering mechanism replaces nftables (in
> > > > that case, bpfilter [1]).
> > > > 
> > > > I understand the rationale behind using nftables [2] but given how it is
> > > > widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
> > > > wasn't worth it. The OP's post confirms there's quite some confusion
> > > > about how it interacts with iptables, and the official documentation is
> > > > far from helpful.
> > > > I'm quite proficient with iptables and networking in general but it took
> > > > me half an hour to understand how to tweak Qubes' nftables rules last
> > > > time I wanted to change something in the firewall, while I would have
> > > > done that task in less than one minute with iptables. I could have spent
> > > > a few hours learning nftables to improve the official doc but at my age
> > > > I prefer to spend time learning tech that significantly improves things
> > > > (eg. Qubes OS over standard linux distribution) over loosing time
> > > > learning stuff that is only marginally better.
> > > > Anyway - I digress :)
> > > > 
> > > > [1] https://old.lwn.net/Articles/747551/
> > > > [2]
> > > > https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500
> > > > 
> > > 
> > > I'm concerned about the confusion and unnecessary complexity here.
> > > 
> > > Network packet filtering is certainly (one of) those features that
> > > software such Qubes needs to be solid on (in both design approach
> > > and implementation detail).
> > > 
> > > Is the Qubes team confident in the current situation, such that
> > > users of Qubes should not be concerned?
> > > 
> > > nb.  This is not meant to be a criticism at all.  I very much
> > > appreciate the hard (and complicated) work going into Qubes.  I'm
> > > just looking to understand the current situation better so as to
> > > judge whether my concern is warranted or not.
> > 
> > 
> > As an example:  I'm wanting to enable some specific network traffic
> > between two qubes.  The docs say to use iptables 
> > 

Re: [qubes-users] Networking between qubes and HVMs

2018-10-10 Thread unman
On Tue, Oct 09, 2018 at 05:43:56AM -0700, jmarkdavi...@gmail.com wrote:
> I am still having difficulty getting these vms to be reachable with each 
> other. Basically what I want to do is have a home security/automation vm, and 
> a freenas vm, communicate with the outside world and with the vm that 
> controls my access points/physical switches.
> 
> Currently I have the usual sys-net/sys-firewall. Each service vm(access 
> points, freenas, etc.) Has its own firewall vm. Those fireall service vms are 
> all connected to sys-firewall.
> 
> I followed the instructions in the qubes-firewall docs setting up forwarding 
> between the service firewalls to travel through sys-firewall. And each 
> service firewall vm(and their associated service vm), can ping every firewall 
> vm in the system. But the actual service vms themselves cannot ping each 
> other.
> 
> So for example: freenas vm > freenas vm firewall > sys firewall > home 
> security firewall vm.
> All will allow ping, but i cant get freenas to talk to home security vm, as i 
> intend on using the nas storage to store the camera footage.
> 
> Similarly the home security vm can do the same amount of pings, but fails to 
> talk to freenas.
> 
> I suspect NAT is the issue but lack the knowledge base to enable this to work.
> 
> I am not particularly dead set on using all these firewall vms either but 
> this is the config thats gotten me the furthest so far. 
> 

I'm not sure what pourpose you had in mind when putting in those extra
firewalls. Undoubtedly they will complicate matters further. Are you
intent on keeping them?

What template are you using for sys-firewall? The instructions should
be updated to cover nft which is now the default in Fedora templates,
rather than iptables.
Which template are you using for 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/20181010130059.kc7gqshrudxana7p%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Deleting app VMs in Qubes 4.0 doesn't free up disk space

2018-10-10 Thread unman
On Wed, Oct 10, 2018 at 07:26:49AM +, 'floasretch' via qubes-users wrote:
> My hard disk was 95% full, as shown by usage/size in the output of qvm-pool 
> -i lvm. So I decided to delete some old unneeded app qubes, each taking a few 
> hundred MB or a few GB of space.
> 
> Before deleting each one, I started it to check the contents, to verify there 
> was nothing I needed to save. HD usage crept up a little, then a little more 
> after I killed the qube. But surprisingly, HD usage crept up a little more 
> after I deleted the qube, instead of decreasing!
> 
> I guessed it was a fluke, so I did the same with the next qube. The same 
> thing happened! Then again with the third and fourth qubes. At this point, my 
> HD is 99% full. I ran fstrim / in dom0, and it reported about 5GB freed, but 
> HD is still 99% full.
> 
> I'm starting to panic, since I know Linux fails badly when an LVM pool that's 
> over-committed with thin volumes (as Qubes 4.0 is designed) fills up.
> 
> I know the qubes were deleted successfully, since lvs | grep  no 
> longer shows them.
> 
> No running qubes are writing any significant data to disk. Now that I'm not 
> deleting any more qubes, HD usage is holding steady at 99%.
> 
> Why isn't my HD usage decreasing when I delete qubes? How can I free up some 
> space?
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

I admire your persistence in continuing to remove qubes.

Have you tried running 'sudo fstrim -av'  in dom0?

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


[qubes-users] Re: debian-9 template

2018-10-10 Thread beto
On Friday, April 27, 2018 at 10:46:08 PM UTC+10, higgin...@gmail.com wrote:
...

I have been plagued with this issue ever since heeding the call to upgrade 
whonix-13 to whonix-14.  All my whonix-14 templates are useless.

I followed the steps carefully, removing / reinstalling.  No errors.

user@host:~$ sudo dmesg | grep segf
[   11.396489] qubesdb-daemon[232]: segfault at 7994802abff8 ip 
799480098f64 sp 7994802ac000 error 6 in ld-2.24.so[79948008f000+23000]
[   12.342682] qrexec-agent[648]: segfault at 70d5257f6ff8 ip 70d5255f3355 
sp 70d5257f7000 error 6 in ld-2.24.so[70d5255dd000+23000]
[   15.903799] qrexec-agent[789]: segfault at 70d5257f6ff8 ip 70d5255f3355 
sp 70d5257f7000 error 6 in ld-2.24.so[70d5255dd000+23000]
[ 1524.123824] qrexec-fork-ser[4430]: segfault at 7b59263a8ff8 ip 
7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
[ 1547.347882] qrexec-fork-ser[4456]: segfault at 7b59263a8ff8 ip 
7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
[ 1594.046093] qrexec-fork-ser[4527]: segfault at 7b59263a8ff8 ip 
7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
[ 2963.435851] qrexec-fork-ser[5300]: segfault at 7b59263a8ff8 ip 
7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]
[ 3145.932364] qrexec-fork-ser[5413]: segfault at 7b59263a8ff8 ip 
7b59261a2355 sp 7b59263a9000 error 6 in ld-2.24.so[7b592618c000+23000]

Everything is hosed.

If anyone has a fix, I would appreciate knowing it.

-- 
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/ea4c2b44-2abf-4cf2-9822-5dfc3a36b962%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] nftables vs iptables

2018-10-10 Thread 'floasretch' via qubes-users
On Monday, October 1, 2018 4:32 PM, Chris Laprise  wrote:
> I've submitted qubes-tunnel to Qubes with iptables commands only, with
> the intention to transition to nftables (or that other new interface in
> Linux, name escapes me just now) for Qubes 4.1.

I guess you mean BPF (Berkeley Packet Filter).

-- 
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/h4m5HXxy0LpeW92e2R0ZdfpFDUA04H-5J7f5E_WpUY121foawKFep0dJ6mdgOzx5jpJKHGRLnH0hGevy9hdWJjhQFCwGyuWNtfed5Vg1dsw%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Deleting app VMs in Qubes 4.0 doesn't free up disk space

2018-10-10 Thread 'floasretch' via qubes-users
My hard disk was 95% full, as shown by usage/size in the output of qvm-pool -i 
lvm. So I decided to delete some old unneeded app qubes, each taking a few 
hundred MB or a few GB of space.

Before deleting each one, I started it to check the contents, to verify there 
was nothing I needed to save. HD usage crept up a little, then a little more 
after I killed the qube. But surprisingly, HD usage crept up a little more 
after I deleted the qube, instead of decreasing!

I guessed it was a fluke, so I did the same with the next qube. The same thing 
happened! Then again with the third and fourth qubes. At this point, my HD is 
99% full. I ran fstrim / in dom0, and it reported about 5GB freed, but HD is 
still 99% full.

I'm starting to panic, since I know Linux fails badly when an LVM pool that's 
over-committed with thin volumes (as Qubes 4.0 is designed) fills up.

I know the qubes were deleted successfully, since lvs | grep  no 
longer shows them.

No running qubes are writing any significant data to disk. Now that I'm not 
deleting any more qubes, HD usage is holding steady at 99%.

Why isn't my HD usage decreasing when I delete qubes? How can I free up some 
space?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

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