[qubes-users] Network breakdown

[Christopher Jamthagen]

I am running Qubes R3.1, and have been for some time. Every couple of days 
though, the network breaks down and I can't even reach the router it is 
connected to. Only a reboot seems to fix the problem. This has happened a 
couple of times now and it is a little frustrating to say the least. I have no 
idea what causes it. Below is what I could gather from dmesg in sys-net:
[731444.719052] [ cut here ][731444.719090] WARNING: 
CPU: 0 PID: 0 at 
/home/user/rpmbuild/BUILD/kernel-4.1.13/linux-4.1.13/net/sched/sch_generic.c:303
 dev_watchdog+0x24f/0x260()[731444.719107] NETDEV WATCHDOG: enp0s1 (e1000e): 
transmit queue 0 timed out[731444.719117] Modules linked in: iptable_raw xt_nat 
xen_netback xt_REDIRECT nf_nat_redirect ip6table_filter ip6_tables xt_conntrack 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack e1000e ptp pps_core intel_rapl 
iosf_mbi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul 
crc32c_intel xen_pcifront pcspkr dummy_hcd udc_core xen_blkback xenfs 
xen_privcmd u2mfn(O)xen_blkfront[731444.719188] CPU: 0 PID: 0 Comm: swapper/0 
Tainted: G   O4.1.13-9.pvops.qubes.x86_64 #1[731444.719202]  
 2daa9f11921048f4 880012803d28 
8175978f[731444.719218]   880012803d80 
880012803d68 8109fe2a[731444.719232]  c975d228 
 88000a49 0001[731444.719248] Call 
Trace:[731444.719257][] 
dump_stack+0x45/0x57[731444.719276]  [] 
warn_slowpath_common+0x8a/0xc0[731444.719288]  [] 
warn_slowpath_fmt+0x55/0x70[731444.719299]  [] 
dev_watchdog+0x24f/0x260[731444.719310]  [] ? 
dev_graft_qdisc+0x80/0x80[731444.719322]  [] 
call_timer_fn+0x39/0x110[731444.719332]  [] ? 
dev_graft_qdisc+0x80/0x80[731444.719343]  [] 
run_timer_softirq+0x23f/0x350[731444.719355]  [] 
__do_softirq+0xf4/0x2d0[731444.719366]  [] 
irq_exit+0xfd/0x110[731444.719378]  [] 
xen_evtchn_do_upcall+0x39/0x50[731444.719389]  [] 
xen_do_hypervisor_callback+0x1e/0x40[731444.719398]
[] ? xen_hypercall_sched_op+0xa/0x20[731444.720031]  
[] ? xen_hypercall_sched_op+0xa/0x20[731444.720031]  
[] ? xen_safe_halt+0x10/0x20[731444.720031]  
[] ? default_idle+0x1e/0xc0[731444.720031]  
[] ? arch_cpu_idle+0xf/0x20[731444.720031]  
[] ? cpu_startup_entry+0x324/0x3f0[731444.720031]  
[] ? rest_init+0x7c/0x80[731444.720031]  [] 
? start_kernel+0x49e/0x4bf[731444.720031]  [] ? 
set_init_arg+0x55/0x55[731444.720031]  [] ? 
x86_64_start_reservations+0x2a/0x2c[731444.720031]  [] ? 
xen_start_kernel+0x518/0x524[731444.720031] ---[ end trace 2cc739109697c299 
]---[731444.720031] e1000e :00:01.0 enp0s1: Reset adapter 
unexpectedly[731444.963843] e1000e :00:01.0 enp0s1: Timesync Tx Control 
register not set as expected
  

-- 
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/DUB125-W3151504F83F05729B95D068A2C0%40phx.gbl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 3.2RC1: number of issues

[Dima Puntus]

Hi,

Here's the info:

System: HP Elitebook 2570p (3840QM, Intel HD4000, 16GB RAM, 250GB SSD)

Qubes 3.2RC1,

1. Dual monitor setup seems glitchy, by default the system mirrors the
screens but if you force it via xrandr, the laptop screen goes black, can't
right click on it but can drag windows into it and maximize. The panel
always stays on the external monitor. Same setup using Qubes 3.1 works like
a charm out of the box. There's no display/monitor section under system
settings.

2. USB mouse (Razer Abyssus) sensitivity is too low by default and can't be
adjusted via system settings. Works fine in Qubes 3.1 Trackpad is fine.

3. Dom0 is only seeing 3.8GB RAM. Is this by design? I can still allocate
10GB+ for individual VMs so the RAM must be visible by Xen.

4. Sensors Viewer doesn't register max CPU temps when changing polling
interval (I normally set it to 1-3sec). Same issue in Qubes 3.1

5. Plasma crashes when trying to change the default theme. That seems to be
related to plasma 5.x as it crashes on every standalone linux machine for
me including Kubuntu 16.04.

6. Question: is it possible to set max CPU threshold per VM? I can only set
it for all 8 vcores using xenpm

Thank you and hope this info helps improving some rough edges in the new
version.

Let me know if you have any questions.

Dimitry

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

Re: [qubes-users] Password management best practices for mid-grade tinfoil hats

[donoban]

On 21/06/16 21:53, Alex wrote:
> I have a keepassx instance for each trust domain (eg. Personal, untrusted and 
> so on). The massively long passphrases that unlock these instances are kept 
> in the isolated vault VM, along with really sensitive stuff that I don't need 
> readily accessible to my networked VMs - eg. master encryption keys, gpg 
> personal keys, 2FA override codes and the like. 
> 
> I have stopped storing passwords in the Firefox password manager as there 
> have been practical attacks against it that to me feel are easier to land 
> than an attack against keepassx. 
> 

If you are storing your bank passwords on your bank domain or your mail
password on your mail domain, password managers from apps like Firefox
or Thunderbird are safe. Specially if your domains are blocked for only
connect to bank/mail servers.

-- 
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/2ea5a1b1-2b0d-18ec-5c99-f577558bdc5e%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No Internet connection/permissive mode

[Jaakko Färm]

On Tuesday, 21 June 2016 21:27:05 UTC+3, Marek Marczykowski-Górecki wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Tue, Jun 21, 2016 at 09:23:59AM -0700, Jaakko Färm wrote: 
> > Then I tried manually with *echo :01:00.0 > 
> > /sys/bus/pci/drivers/pciback/permissive* but nothing happened. 
>
> You may try to restart sys-net after this, just to test out. Or fix 
> qubes-pre-netvm.service (see below). 
>
> > After that I 
> > followed https://www.qubes-os.org/doc/assigning-devices/ and made the 
> > following file 
> > 
> > [ 
> > [Unit] 
> > Description=Netvm fixup 
> > Before=qubes-netvm.service 
> > 
> > [Service] 
> > ExecStart=/bin/sh -c 'echo :01:00.0 > 
> > /sys/bus/pci/drivers/pciback/permissive' 
> > Type=oneshot 
> > RemainAfterExit=yes 
> > 
> > [Install] 
> > WantedBy=multi-user.target 
> > 
> > 
> > Afted enabling and booting this gave with *systemctl status *the 
> following: 
> > 
> > 
> > *systemctl status qubes-pre-netvm.service* 
> > qubes-pre-netvm.service - Netvm fixup 
> >Loaded: loaded (/etc/systemd/system/qubes-pre-netvm.service; enabled) 
> >Active: failed (Result: exit-code) since Tue 2016-06-21 17:03:52 
> EEST; 
> > 47min ago 
> >   Process: 889 ExecStart=/bin/sh -c echo :01:00.0 > 
> /sys/bus/pci/pciback 
> > /permissive (code=exited, status=1/FAILURE) 
>
> You forgot "drivers" in the path. 
>
> >  Main PID: 889 (code=exited, status=1/FAILURE) 
> >CGroup: /system.slice/qubes-pre-netvm.service 
>
>
> - -- 
> 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- 
> Version: GnuPG v2 
>
> iQEcBAEBCAAGBQJXaYbwAAoJENuP0xzK19csuEoH/RGH9znwNKye0Xy0ofVslHjj 
> qEnLDuNOxMac9/rU7JKz/9nyWSUeDCF27I/NxA3c2gVkzzfNaM2TQehgVrCQDeKS 
> jT7cztdx4W6hgC+Fn//LuFHT/TU0+hTLolOHj/YRoZbqw1SDgL7n0UbEl5hN6X3t 
> TCddLB4U1fC5VToh/c/R9W7eoO0EWwJTKTA90WUEdheY79rL08UhLVyvRzacBbI/ 
> M5BdNtnZft+VCKbi+xo3zFTKgi506MGTYL8miYyhsKggpS1ryuz/ZSnODROg9Kaq 
> YAf0mHB+cKturKJfQCbzddoqIEunvxxIYTh5ZWuzGFQdMU4AQItuUBNxCaHwaYU= 
> =U4ys 
> -END PGP SIGNATURE- 
>

I must have been blind. I can't tell you have many times I read that but 
somehow it slip my eyes. Yes, I had the path wrong, now everything works. 
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/faa65b59-84bc-47ec-8087-ade0ff916255%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] gui protection within app vms and autotype for more paranoid password management.

[pixel fairy]

note: not yet running qubes-os. just my own multi-vm setup until i find a 
good laptop. so if this is already solved, please just tell me :)

within my appvms i run all gui apps with firejail --x11 --private=... this 
means each app gets its own x server, home directory, and is sandboxed from 
certain calls. some have different, or no network access. its far from 
perfect, which is why i have multiple domains, a vault vm, usbvm etc. 

I think this approach would be good in qubes-os as well. it protects 
against clipboard, framegrabber, and keyboard sniffing, and otherwise 
sandboxes apps depending on that apps needs. 

the problem is with the clipboard. since the clipboard would go to display 
:0 in the app vm, cutting and pasting wouldn't work unless you allow 
clipboard sharing within an appvm. you could run keepassx in the app vm, 
and leave out --x11 so it could type into your other app vm windows. ive 
tried this with dummy strings on firejailed apps, and it does work. but, we 
probably dont want keepassx running in our appvms. libvirt cant send key 
into a xen vm. so, i can think of 3 options. maybe theres an easier, more 
sensible way.

1. dom0 has vnc sockets and a vncdotool (python) script to type from a 
given appvms clipboard (probably vault) to the window in another appvm. so 
instead of copy / paste clipboard to clipboard, it would be copy/paste 
clipboard to sendkey. maybe Ctrl-Shift-T. according to the vncdotool docs, 
special characters wont work with this. i dont know what special characters 
means, but that might kill its use for passwords that have policies 
insisting on weird characters. this would open network sockets in dom0 
which might be scary. looking here, 
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html i dont see a way for 
xen domains to have vnc listen on unix domain sockets instead of network 
ones.

2. run all your gui apps in their own appvm. laptop with 32gigs of ram?

3. switch gui to wayland. cant find any kms capable virtual graphics for 
xen / kvm, and this wont happen without that. i hope wayland has sensible 
policies.

-- 
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/2da87b67-e321-44b6-be13-456dd1959efc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: disable seamless mode Windows 7

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-06-21 18:23, Drew White wrote:
> Hi Andrew,
> 
> I see.. andrewdavidwong  added
>  this to the Far in the future 
>   %20future> milestone Jun 18, 2016 
>  696655513>
> 
> .. I guess that means that there is no need to fix the manager or 
> the tools or the interface between?
> 

No. That milestone is in no way decisive. It's an initial
categorization for organizational purposes, and it could change at any
time. Ultimately, it is up to the developers (in this case
specifically, probably Rafał and Marek) which milestone it should have.

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

iQIcBAEBCgAGBQJXaf7mAAoJENtN07w5UDAwAioQAMj5qb0BR1lKLzbrjCpTsip8
6Mg7wKPsDvaK+ZMv2QDpCkD7jDFScb6DKNt/WRlw5buOw5QKb9nxHVq44pb2C8yR
5xDNnMG7i5CPkKD7hSDbWMhQXS/sMrdESe8tH8FcCvqSqU3cB8IcZ11OL+0oFpqS
N8PcpRe+Ftp3s1V3TtijYGGnKobluIUxQ3pjPczxNXEioaCvtq9R7hokS4yKAtpU
VPvNtebT9F6dXbM4RhARzW6ldvou9JADOCEPRqWJQTnhy+iOq03mIRUaNNRLALdj
jXEup7wsN3rwFatySvWPer1xa0nuIzJbCiVMIgRTvllcs5xZ5DZDSjgASD5QnGrl
lhSDNwNugOfJDffpcX0kDHonaR8bn+RETM15jgQhKAfbuIiYoOjf57zygMdL7Jzs
Qk9L2hrv3uXYyh2QW8+iviqW/eOntcpUsYTXMA9dCbzo+giQMJWtOWzL7dOHpvl0
SwcGezQpZJf2dL2qyjH031ZBkRn6b8bis/zVhfzu4qJ3/0Lt9fLwD3O0xQcdmxMS
DUHUUlC4zKSqdhFFkMM1ZTBZTmBI+S6BZiT6OfyXZuBdFhDMNRgaOslv9Lp4/mNd
+Ql/dOgrpgFCgpf+aZzrUHWYwlEQz56AxpMMjVmG/vT/DWZ0+5Y3VMfS5lyoS1yQ
KfKrr79dq0tBd/rbtLGd
=Ppoe
-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/736ea113-1029-8cf6-60cb-f8b627762190%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Syncing files / Alternative backup whist keeping best practises of isolation.

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-06-21 06:10, Franz wrote:
> On Mon, Jun 20, 2016 at 10:32 PM, Andrew David Wong
>  wrote:
> 
> On 2016-06-20 18:05, Franz wrote:
 On Mon, Jun 20, 2016 at 1:51 PM, Andrew David Wong 
  wrote:
 
 On 2016-06-19 08:40, Franz wrote:
>>> On Sun, Jun 19, 2016 at 11:40 AM, Andrew David Wong 
>>>  wrote:
>>> 
>>> On 2016-06-19 04:38, Alistair Hutten wrote:
>> Good evening, Alistair here from Australia,
>> 
>> I'm after some help / recommendation to follow
>> best practices (isolation between my different
>> domains)
>> 
>> My Current practice;
>> 
>> - have encrypted vaults (cryptomator 
>> ) one for personal, and
>> one for work/business, - underlying encrypted
>> files stored within Dropbox
>> 
>> I do it this was because data is encrypted at
>> rest, and more importantly before dropbox sees
>> them,
>>> 
>>> Careful:
>>> 
>>> * Certain kinds of encryption are easier to break if
>>> the attacker has repeated access to a changing
>>> ciphertext.
>>> 
>>> 
 Also, who knows what the future bring and when.
 Quantic computing promises to be able to crack
 current encryption systems. When this happens and if
 you are aware of it, you would need to change all
 your passwords.
>>> 
 
 That mainly applies to asymmetric, not symmetric,
 encryption:
 
 http://pqcrypto.org/
 
 
> Thanks Andrew, I had a look only at the first paper of you
> link and it tells that the quantum computer problem is
> limited to public key encryption. While there is no problem
> for secret key encryption which would be the case for vault
> encryption.
 
> 
> Well, it's not that quantum computing presents no problem *at all*
> for secret key/symmetric encryption. Symmetric ciphers are still
> thought to be vulnerable to Grover's algorithm, which basically
> means that key length would effectively be halved (e.g., the
> strength of AES-256 would be effectively halved to that of
> AES-128), but this is obviously much less of a problem than the
> crypto being completely broken (as would be the case for RSA, for
> example).
> 
 
 I would not send my encrypted vault over the internet
 and would not open it with anything different from my
 vaultVM.
>>> 
 
 Data confidentiality is encryption's raison d'être. If you
 can't send the ciphertext over the internet, then what's the
 point of encrypting it?
 
 
> Well my idea was that there is no 100% security guarantee
> and it is only a matter of relative security. So I
> considered that keeping my backups in a NAS over a personal
> LAN was safer that sending them over the internet.
 
> 
> That's fair. I think that might qualify as security through
> obscurity (or maybe "security through non-availibility"), but
> that's not to say it doesn't still provide some real degree of
> security.
> 
> But you link explains that I am wrong and that for any
> reasonable future secret key encryption is 100% safe.  So
> thanks Andrew. This confidence certainly gives more peace
> of mind.
> 
> Well... I didn't mean to give that impression. IANAC (I am not a 
> cryptographer), but when it comes to encryption, I don't think we 
> should say that anything is "100% safe." It's not that the
> algorithms are apodictically unbreakable. Rather, we derive our
> confidence in them from the fact that lots of smart people have
> spent lots of time trying to break them, and no one has been
> successful yet (that we know of!). That's why there are
> competitions to select algorithms.
> 
> Also, even if the algorithm is secure, any given implementation
> you use might not be. So, even though it's true (as people often
> say) that the crypto itself is usually not the weak point in a
> digital system, I also don't think (and didn't mean to give you the
> impression) that it's "100% safe."
> 
> 
>> You are right of course, but I was referring to sending encrypted
>> vault over internet. It is not compulsory to do that. You can
>> certainly live comfortably without doing that. So why should one
>> do that? Only because there is expectation of a reasonable total
>> safety, so that the difference to 100% may be negligible.
> 

I see what you mean.

I think it still depends on your backup situation, though. If your
only means of having offsite backups is to send (encrypted) backups
over the internet (i.e., you can't physically move disks to another
location or have someone else do it for you), then it may not be
entirely true that you can "live comfortably without doing that." (I
would live uncomfortably knowing that a fire could burn 

Re: [qubes-users] Re: VMWare inside Debian AppVM?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-06-19 17:44, J. Eppler wrote:
> Hello,
> 
> Xen is capable of doing so called nested virtualization:
> 
> http://wiki.xen.org/wiki/Nested_Virtualization_in_Xen
> 
> Nested virtualization is more a experimental topic for researchers.
> 
> 
> If you just want to run a VMWare VM on your Qubes OS than you
> should simply consider converting the VMWare VM to a Xen VM and run
> it on top of Qubes OS as (e. g. HVM).
> 
> Best regards J. Eppler
> 

IIRC, Xen's nested virtualization is disabled in Qubes for security
reasons.

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

iQIcBAEBCgAGBQJXafeOAAoJENtN07w5UDAwDKwP/i37DsXRoQdJgJU+RP6jwnUG
f4bZFz4Kg/fvB3ryiKLRj/iOu9SvnKqTNxNVjcC7lYQECA/HbP99MPReGAW3beQu
5QVnWe0+AWykaL/NcXPJNGPO1Rx3m8wSkTwvjhSkfooNevymOKVjHdctRWkUx1Kv
42/gLCKWeICY1NUjXgPA3czChsR00cD49U5pqq6lnT2TaZ11t6RN3kvuzgLaRJ8d
dJIjiaLI5DCV3gyHE9IezBtOzqDzEbrNFt30m7Fy++JFI3MvIbznxpF/g4yhBe8r
hboLdZuUMx3UEP3K9yxQmMvx1vuFGS4Yv+2MtHXg3gUlX/Ni3NP/F/1sK5v3fiJW
s+LCgjhpPByekUia5tjRKfQWYXtgnfSt9JjuBcKgXWU0ZhitEYTvrOfZeKvWDLt9
K3lccc7tGtEawBuLIaYNUV/qYf0WGMaOpdo1rta7j0sr52DXrzTcFqerHCj5/Orv
3U4j/q5IwRarpaO746+1EhxEBTXQQTxTbAkyf3zvPWI1xAd9jXPEQrQoxdjmIOQw
MO9HnNfzw3lkw1cF8scEvFxuw9kJnyFo9eDc70FDYBWHwxpEGUsDgSnBUxV8gaXz
64FdCUtMdaCtkBWvlrQzllz8uRwThIW/WwbQ2XOGCkZFBqOMBE5eQS1aLv61vBRo
ubHPAR8xZs+PpB7HsHmu
=AeM0
-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/4c57bd80-96ec-b1d1-a819-b96173ae2bcf%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Few Issues With Qubes R3.1

[Qubed One]

Andrew David Wong:
> On 2016-06-19 00:09, CANNON NATHANIEL CIOTA wrote:
> 
>>> On 2016-06-17 23:17, CANNON NATHANIEL CIOTA wrote:
 Hello thank you for the reply...

> What is the output when you run this command in a dom0 
> terminal?
>
> $ qvm-create-default-dvm --default-template

 I have already tried this before re-installing Qubes which made
 no difference.
>>>
>>> Can you be more specific when you say it "made no difference"? 
>>> For example, can you tell us the exact output when you attempted
>>>  to run that command? (Even if there was no output at all, that 
>>> would be helpful to know.)
> 
>> Here is output (I am manually typing this output, so there might
>> be slight typos): [...]
> 
> 
> Ok, that looks normal. When you say DispVMs "do not launch," does that
> just mean that nothing happens when you click the DispVM shortcuts in
> the KDE launcher?
> 
> Is your default template fedora-23? Have you made any modifications to
> it?
> 
> What happens if you execute this command in dom0?
> 
> $ sh -c 'echo xterm | /usr/lib/qubes/qfile-daemon-dvm \
>   qubes.VMShell dom0 DEFAULT red'
> 


Also try removing the pre-existing fedora-23-dvm first, then recreate it
with the above command. I've had issues before that were solved by
removing the old *-dvm first, then creating a new one.

-- 
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/052bbbd0-32aa-a8bf-d3df-5a1cd88eea3c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Password management best practices for mid-grade tinfoil hats

[stephen . wickeri]

Thanks for sharing, everyone. That's pretty much what I have setup right now, 
KeePassX in the vault vm. I think that once I get a machine with far more RAM 
than the machine I'm working with right now, I'll probably have some site 
specific VMs for sites that I visit a lot but would like to maximize security. 
That'd let me keep the password stored inside of Firefox, which would save me 
the oh-so-terrible Qubes copy'n'paste ;). Stuff like checking on the several 
dollars in my checking account, for example.

-- 
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/4bc878ba-faee-4486-9565-e235fac2ad29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [Qubes R3.1] KeePassX Icon disappearing from AppVM menu

[raahelps]

it loads from terminal for me.  the command is keepassx2.

-- 
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/50bb83c2-1dce-4130-8e88-a73d06360264%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes default cryptsetup. How strong is it?

[Robin Schneider]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 21.06.2016 23:54, Arqwer wrote:
> How "quick" any of available super PCs (10,649,60 cores, 125,435. TFLOP/S
>> )  can find the password (e.g 8-16 chars) encrypted with Qubes default 
>> settings cryptsetup?
>> 
> 
> Encryption is the hardest part of chain. If the passphrase is long 
> enough.If password is 16 random lowercase and uppercasr letters, then it
> is 52^16 combinations, it is about 10^27. If you can crack 100 Peta 
> passwords/S, then it will take 10^(27-17) = 10^(10) seconds to brute the 
> password, which is 316 years. (Really expectation is half of it, so 158 
> years on average). Of course, if those letters are not "Password12345678".
> 
> How can we improve security to prevent this?
> 
> 
> If 316 years is not enough, than you can add one more character, to make
> it 16 thousands of years!


Most of those projections about how many years brute forcing a passphrase with
that many bits of entropy may take completely ignore one key aspect, especially
when you are talking about hundreds of years and that is technical advance and
Moore's law. So to be realistic, you would need to take that into
consideration.

Refer to:

*
https://crypto.stackexchange.com/questions/1815/how-to-account-for-moores-law-in
- -estimating-time-to-crack

- --
Live long and prosper
Robin `ypid` Schneider
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXabyzAAoJEIb9mAu/GkD4DhQP/iru7NGtTJ6gVdsdnYlZfLx1
6uTWhX0mwwOYw1TMV4wGC9uW2NDGsiVXHHEJSXpdeLvMwZYdZGfKxu8vv8SRpUQc
SZYI38gybmYn4+wg/fp4oU6cDaHqJ2eh+oOh1YUZhnewOM/jcUMD7kK+sVFcP0Sr
koagcIuEXFC0nRnwZsSMtcfr1DQ3x/rJHQuBwdfQLpKyK6gDOVJEqQ5K1kh0Q2w+
yUEcMVtJiMdFkYyTFu7/pcuVv4Xgssiw+8eUt7tsr8QO5Sqczhr0oxlN3d8EwEeX
2H8poeBIPJ1v++xqiFuglxA2NkS3pi/y5VMWqs4rI8phazSvgPhkcZJ7NOsNpo6k
NkOFZHccwdRAq9KVq8M6OGcFk6ulSU6Y1SayHxkNM9zQ8ofJ4IBoJ4b+zAwcKta6
nPidNlPjhATD1BY0G1wO61TtfCqYqHuEdENvxko+Q2OXuNqaNREs+9+xdQrcwTuJ
hCy+YMC5wS1W25Le4f8Q0oNQrhMiLM92/YNz+tW8JzmLLU1LdzbM4Dz9Kf3aGrqV
Fi0FSj4MdRLzD9lLiZ6zUXpCpfYGlACyP2j58mssa5jLyKqHvEiMt1cSiOAoE16O
Lqxr0D8/M/O4Zx7o9NuQWi86stKK39x1xzbzOTCo0zjK+zwd8L5LspbVZpmW8AQW
q5t6CA096mCC45lflC4F
=0UJ1
-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/a69beae4-41e8-6f5b-9cce-b56916e1c6a3%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes default cryptsetup. How strong is it?

[Arqwer]

> Will Qubes Manager work fine if VMs will not be available at the boot time 
> or some time after that, before user will not mount container? 
>
 
Yes. I have R3.0, and some vm's are on secondaty, encrypted drive. I mount 
it using crontab like
@reboot /my/script/to/mount/encrypted/secondary/drive
I used this instruction  
to move appvms there. But I did it not in purpose of security, but just to 
have more disk space. I store the key to that drive in dom0.

How "quick" any of available super PCs (10,649,60 cores, 125,435. TFLOP/S 
> )  can find the password (e.g 8-16 chars) encrypted with Qubes default 
> settings cryptsetup? 
>

Encryption is the hardest part of chain. If the passphrase is long 
enough.If password is 16 random lowercase and uppercasr letters, then it 
is  52^16 combinations, it is about 10^27. If you can crack 100 Peta 
passwords/S, then it will take 10^(27-17) = 10^(10) seconds to brute the 
password, which is 316 years. (Really expectation is half of it, so 158 
years on average). Of course, if those letters are not "Password12345678". 

How can we improve security to prevent this? 


If 316 years is not enough, than you can add one more character, to make 
it  16 thousands of years!

Is it a good idea to install some 3th party software tat dom0 to make 
> crypto container to store some VMs and mount it before VM start? 


I don't think so. The more different tools you use, the more there are 
chances to use something wrong.

After all, there are much easier ways to get your data.  For example 
hardware backdoor called Intel ME.

-- 
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/8ddbccc9-8bf7-4626-8bcd-bf6d07824872%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Password management best practices for mid-grade tinfoil hats

[Arqwer]

> Or am I growing my tinfoil hat from mid-grade to high-grade? ;)

I think no. I store all passwords in KeePassX in vault vm, and it is very 
convenient, and all passwords are in the same place. Safe place. There is 
almost no overhead - only additional press of ctrl+shift+c, ctrl+shift+v 
which is nothing. I don't see any benefit in using multiple KeePassX in 
different VMs. 

-- 
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/279a467a-e557-428e-9b1e-5a25a43a9fe3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to exclude qubes manager from autostart?

[Arqwer]

Hello.
In R3.0 qubes  manager automatically appears on each start up. How to 
disable 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/d0486201-380f-4a69-adce-303fe1bf6eb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [Qubes R3.1] KeePassX Icon disappearing from AppVM menu

[raahelps]

On Tuesday, June 21, 2016 at 2:19:44 AM UTC-4, Alex wrote:
> Hello everybody,
> I noticed that recently, when I restart an AppVM that used to have the
> KeePassX shortcut added to the application menu, said icon disappears
> from the AppVM menu and has to be re-added with the usual tool.
> 
> Once added, the icon works properly again. I noticed (may or may not be
> related) that typing "keepassx" in the "Run command in VM" popup window
> (in Qubes VM Manager) does not start keepassx anymore (as it used to
> do), and it has to be started via the menu icon.
> 
> I did not notice if this is related to an update of keepassx; my
> hypothesis is that an update changed the way keepassx has to be started,
> and somehow the dom0 shortcuts are not able to use the new method (maybe
> there is some dirty cache?). How can I investigate further to help
> identify the problem? Does it happen to anybody else?
> 
> -- 
> Alex

I also noticed keepassx disappearing from the start menu recently and I had to 
add it back.  I haven't tried to start it from a terminal but I'll try later 
today and post back.

-- 
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/1550b56e-fb51-4c66-bbbf-0d120cd6c3b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] problem with running mullvad in proxyvm (DNS weirdness and autostart question)?

[Chris Laprise]

On 06/21/2016 03:04 PM, Chris Laprise wrote:



On 06/21/2016 02:09 AM, Jane Jok wrote:

Hello!

So, long story short, I've successfully configured a debian-based 
ProxyVM to run Mullvad's GUI client (I know one can use "vanilla 
OpenVPN" to connect to mullvad, I still prefer their GUI thing and 
decided to give it a try)


In a word, as long as one does not select "block internet access on 
connection failure" everything works.


Hi,

Keep in mind that a Qubes proxy vm implies different conditions for 
blocking than a regular desktop architecture, so the Mullvad client 
may not get this right. Its best to setup Qubes-specific blocking 
instead (which is more effective anyway)...




However, there is a persistent DNS leak from any AppVM connected to 
the MullvadProxyVM (as detected by ipleak.net)


Also, if I take the "block connection if tunnel breaks" suggestion 
from here https://www.qubes-os.org/doc/vpn/

(that is, add
|iptables -I FORWARD -o eth0 -j DROP iptables -I FORWARD -i eth0 -j 
DROP to my iptables in the MullvadProxyVM) No connected AppVM can 
resolve hostnames (direct IP works tho) I have, however, figured out 
a sort-a-kinda solution. The solution I have found so far is to edit 
resolv.conf in AppVM to something external (like say Google's DNS, 
8.8.8.8) As long as AppVM's resolv.conf has 8.8.8.8 (or any other 
external nameserver) in it, everything works like a charm without any 
DNS leaks. However, it the resolv.conf in AppVMs is not very 
persistent, and even if |||/rw/config/rc.local| is modified to adjust 
resolv.conf, certain events (like changing netvms) trigger 
restoration of "old" resolv.conf So, my first question is: 1) is 
there a way to prevent reset of manually edited resolv.conf, 
particularly in case when you change AppVM's netvm ? |


|Past advice on setting up a vpn vm revolved around these 3 steps:
1. Update resolv.conf (hard-coded IPs or from openvpn DHCP)
2. Run the /usr/lib/qubes/qubes-setup-dnat-to-ns script
3. Add the eth0 forward-blocking you mentioned to 
qubes-firewall-user-script


The first two basically worked, but had the side-effect of making the 
local vpn vm commands use the tunnel's dns. That might prevent the vpn 
from successfully restarting, or maybe create a different kind of leak 
if local commands inadvertently tried to access the net.


That's why qubes-vpn-handler.sh exists. It accepts dns addresses and 
fixes the dns dnat issue without changing resolv.conf. It shouldn't be 
too hard to integrate with the GUI client if it uses openvpn or 
similar; you just need to run it as the up-script.


OTOH, if the side-effects I mentioned above seem trivial to you, then 
you can use #2 to get dns working.



Also, don't mean to imply that #3 doesn't work. All three do work 
together to route DNS and stop leaks.



Chris



--
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/56ab626e-b04f-93fd-c703-dfa41c20de72%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No Internet connection/permissive mode

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jun 21, 2016 at 09:23:59AM -0700, Jaakko Färm wrote:
> Then I tried manually with *echo :01:00.0 > 
> /sys/bus/pci/drivers/pciback/permissive* but nothing happened. 

You may try to restart sys-net after this, just to test out. Or fix
qubes-pre-netvm.service (see below).

> After that I 
> followed https://www.qubes-os.org/doc/assigning-devices/ and made the 
> following file
> 
> [
> [Unit]
> Description=Netvm fixup
> Before=qubes-netvm.service
> 
> [Service]
> ExecStart=/bin/sh -c 'echo :01:00.0 > 
> /sys/bus/pci/drivers/pciback/permissive'
> Type=oneshot
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> Afted enabling and booting this gave with *systemctl status *the following:
> 
> 
> *systemctl status qubes-pre-netvm.service*
> qubes-pre-netvm.service - Netvm fixup
>Loaded: loaded (/etc/systemd/system/qubes-pre-netvm.service; enabled)
>Active: failed (Result: exit-code) since Tue 2016-06-21 17:03:52 EEST; 
> 47min ago
>   Process: 889 ExecStart=/bin/sh -c echo :01:00.0 > /sys/bus/pci/pciback
> /permissive (code=exited, status=1/FAILURE)

You forgot "drivers" in the path.

>  Main PID: 889 (code=exited, status=1/FAILURE)
>CGroup: /system.slice/qubes-pre-netvm.service


- -- 
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-
Version: GnuPG v2

iQEcBAEBCAAGBQJXaYbwAAoJENuP0xzK19csuEoH/RGH9znwNKye0Xy0ofVslHjj
qEnLDuNOxMac9/rU7JKz/9nyWSUeDCF27I/NxA3c2gVkzzfNaM2TQehgVrCQDeKS
jT7cztdx4W6hgC+Fn//LuFHT/TU0+hTLolOHj/YRoZbqw1SDgL7n0UbEl5hN6X3t
TCddLB4U1fC5VToh/c/R9W7eoO0EWwJTKTA90WUEdheY79rL08UhLVyvRzacBbI/
M5BdNtnZft+VCKbi+xo3zFTKgi506MGTYL8miYyhsKggpS1ryuz/ZSnODROg9Kaq
YAf0mHB+cKturKJfQCbzddoqIEunvxxIYTh5ZWuzGFQdMU4AQItuUBNxCaHwaYU=
=U4ys
-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/20160621182655.GC1593%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Password management best practices for mid-grade tinfoil hats

[Chris Laprise]

On 06/21/2016 11:13 AM, stephen.wick...@gmail.com wrote:

As I'm moving from OS X to Qubes, gradually, I wanted to get a feel for best 
practices for management of passwords. Qubues has KeePassX. Should I trust that 
over the Firefox password manager? Or pretty similar? Would it be a good idea 
to keep the password manager in a non-networked VM? Or am I growing my tinfoil 
hat from mid-grade to high-grade? ;)

Thanks for your thoughts.


Qubes best practice is to use a non-networked 'vault' vm for holding 
passwords and keys. You can run keepassx in vault and use Qubes 
copy/paste between that and other vms.


Whether it is 'safe' to store passwords in firefox has a lot to do with 
how sensitive the password is, and how much risk you're taking with that 
vm. If you're just randomly browsing the web with that vm, then I would 
not store passwords there for anything other than trivial accounts.


Chris

--
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/d3226d23-a0c7-296d-196f-4bf1003a98f2%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Syncing files / Alternative backup whist keeping best practises of isolation.

[Franz]

On Mon, Jun 20, 2016 at 10:32 PM, Andrew David Wong 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-06-20 18:05, Franz wrote:
> > On Mon, Jun 20, 2016 at 1:51 PM, Andrew David Wong
> >  wrote:
> >
> > On 2016-06-19 08:40, Franz wrote:
>  On Sun, Jun 19, 2016 at 11:40 AM, Andrew David Wong
>   wrote:
> 
>  On 2016-06-19 04:38, Alistair Hutten wrote:
> >>> Good evening, Alistair here from Australia,
> >>>
> >>> I'm after some help / recommendation to follow best
> >>> practices (isolation between my different domains)
> >>>
> >>> My Current practice;
> >>>
> >>> - have encrypted vaults (cryptomator
> >>> ) one for personal, and one
> >>> for work/business, - underlying encrypted files stored
> >>> within Dropbox
> >>>
> >>> I do it this was because data is encrypted at rest, and
> >>> more importantly before dropbox sees them,
> 
>  Careful:
> 
>  * Certain kinds of encryption are easier to break if the
>  attacker has repeated access to a changing ciphertext.
> 
> 
> > Also, who knows what the future bring and when. Quantic
> > computing promises to be able to crack current encryption
> > systems. When this happens and if you are aware of it, you
> > would need to change all your passwords.
> 
> >
> > That mainly applies to asymmetric, not symmetric, encryption:
> >
> > http://pqcrypto.org/
> >
> >
> >> Thanks Andrew, I had a look only at the first paper of you link
> >> and it tells that the quantum computer problem is limited to
> >> public key encryption. While there is no problem for secret key
> >> encryption which would be the case for vault encryption.
> >
>
> Well, it's not that quantum computing presents no problem *at all* for
> secret key/symmetric encryption. Symmetric ciphers are still thought
> to be vulnerable to Grover's algorithm, which basically means that key
> length would effectively be halved (e.g., the strength of AES-256
> would be effectively halved to that of AES-128), but this is obviously
> much less of a problem than the crypto being completely broken (as
> would be the case for RSA, for example).
>
> >
> > I would not send my encrypted vault over the internet and
> > would not open it with anything different from my vaultVM.
> 
> >
> > Data confidentiality is encryption's raison d'être. If you can't
> > send the ciphertext over the internet, then what's the point of
> > encrypting it?
> >
> >
> >> Well my idea was that there is no 100% security guarantee and it
> >> is only a matter of relative security. So I considered that
> >> keeping my backups in a NAS over a personal LAN was safer that
> >> sending them over the internet.
> >
>
> That's fair. I think that might qualify as security through obscurity
> (or maybe "security through non-availibility"), but that's not to say
> it doesn't still provide some real degree of security.
>
> >> But you link explains that I am wrong and that for any reasonable
> >> future secret key encryption is 100% safe.  So thanks Andrew.
> >> This confidence certainly gives more peace of mind.
>
> Well... I didn't mean to give that impression. IANAC (I am not a
> cryptographer), but when it comes to encryption, I don't think we
> should say that anything is "100% safe." It's not that the algorithms
> are apodictically unbreakable. Rather, we derive our confidence in
> them from the fact that lots of smart people have spent lots of time
> trying to break them, and no one has been successful yet (that we know
> of!). That's why there are competitions to select algorithms.
>
> Also, even if the algorithm is secure, any given implementation you
> use might not be. So, even though it's true (as people often say) that
> the crypto itself is usually not the weak point in a digital system, I
> also don't think (and didn't mean to give you the impression) that
> it's "100% safe."
>
>
You are right of course, but I was referring to sending encrypted vault
over internet. It is not compulsory to do that. You can certainly live
comfortably without doing that. So why should one do that? Only because
there is expectation of a reasonable total safety, so that the difference
to 100% may be negligible.

But returning to Alistar post, describing the plan to "more importantly
before dropbox sees them, can sync between different devices,"

Here, IMHO the difference to 100% in not at all negligible, because if you
sync your encrypted vault among different device, it is probably because
you want to open it in different devices and this is dangerous. Which is
the point of maintaining Qubes if you expose your vault to the much lower
security of other systems connected to internet?
Best
Fran

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

[qubes-users] Qubes default cryptsetup. How strong is it?

[Setup]

How "quick" any of available super PCs (10,649,60 cores, 125,435. TFLOP/S )  
can find the password (e.g 8-16 chars) encrypted with Qubes default settings 
cryptsetup?

How can we improve security to prevent this? 
Is it a good idea to install some 3th party software tat dom0 to make crypto 
container to store some VMs and mount it before VM start?
Will Qubes Manager work fine if VMs will not be available at the boot time or 
some time after that, before user will not mount container?

-- 
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/20160620161234.42100D8507%40emkei.cz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes-Cheatsheet user feedback request

[J. Eppler]

Hello Zrubi , 


> You should update the qubes-hcl-report entry according to --help 
>

 I assume you mean the qubes-hcl-report -s option. Sadly qubes-hcl-report 
with and without -s did not work on my system. Maybe you can give me a more 
detailed hint on what to update?

Best regards 
  J. Eppler

-- 
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/e59552eb-5bc6-4855-bc9b-65ab84a1cbe6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: VMWare inside Debian AppVM?

[J. Eppler]

Hello, 

Xen is capable of doing so called nested virtualization:

http://wiki.xen.org/wiki/Nested_Virtualization_in_Xen

Nested virtualization is more a experimental topic for researchers. 

If you just want to run a VMWare VM on your Qubes OS than you should simply 
consider converting the VMWare VM to a Xen VM and run it on top of Qubes OS 
as (e. g. HVM).

Best regards
  J. Eppler

-- 
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/1e172f9e-9d34-4244-a03e-296fe1799d45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Firefox profile seems to leak between DispVMs

[Alex]

On 20 June 2016 18:28:49 BST, Andrew David Wong  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On 2016-06-19 12:30, IX4 Svs wrote:
>> On Sun, Jun 19, 2016 at 3:05 PM, Andrew David Wong 
>>  wrote:
>> 
>> On 2016-06-18 14:54, IX4 Svs wrote:
> Qubes R3.1, Fedora 23 template, fully updated.
> 
> I launch a new disposable Firefox, which creates a new DispVM
> and displays [disp42] in the Firefox window title. All normal
> so far.
> 
> I hit CTRL+t to open a new Firefox tab and - I can't believe
>  my eyes - the "new tab" page is full of thumbnails of web 
> pages I have visited in other DispVMs, which have long been 
> shut down.
> 
> sudo xl list from dom0 confirms disp42 is the only DispVM 
> currently running.
> 
> How can such data leakage from one DispVM to another be 
> possible? Yes, I am adamant, 100% certain that I have not 
> visited the web sites showing up in the "new tab" page from 
> the TemplateVM that my DispVM is based upon.
> 
> Any thoughts?
> 
> Thanks,
> 
> Alex
> 
>>> 
>>> Does it persist even after you regenerate the DVM template?
>>> 
>>> $ qvm-create-default-dvm --default-template
>> 
>> I have not tried the nuclear option - I was hoping to find the 
>> cause of such a massive leak now that it's happening so that it can
>> be fixed for all Qubes users.
>
>Sorry, I wasn't thinking of that as "the nuclear option." Rather, I
>was just trying to help determine whether this phenomenon is isolated
>to your specific machine (e.g., perhaps you forgot that you had done
>some special configuration that would be overwritten when regenerating
>the DVM template) or whether it's a Qubes bug.
>
>Personally, I haven't been able to reproduce this on my own machine
>(and I haven't seen anyone else say they can either), so it's not yet
>clear whether this affects any other Qubes users. If the phenomenon
>were to persist even after you regenerate the DVM template, that would
>be significantly more worrisome, since you said you're absolutely sure
>you didn't do anything in the TemplateVM on which the DVM template is
>based that might cause this.
>
>I've never tried backing up the DVM template (since there's usually no
>reason to do so), but I wonder if doing so would allow you to preserve
>the current state so that you can try regenerating the template.
>
>- -- 
>Andrew David Wong (Axon)
>Community Manager, Qubes OS
>https://www.qubes-os.org
>-BEGIN PGP SIGNATURE-
>
>iQIcBAEBCgAGBQJXaCe6AAoJENtN07w5UDAwfU4QAJCUFt26MbWKIq7WFM6x5Bxg
>3PTQWyhG1paGW2wCLY2Zo6wMnyYL8uGJbXYti8QZGJgciRE9cuJWFAnfOxXs0JT8
>gREib7SWIxA5ePBUhDkuN1VcFqrC3Cu9vLXQ1Tn4yChdNKg0DnYNNY3+btXjAkl1
>3VOZ/b+PaQkUB8oGJG7zZ/AEO0MrVZ/nX0xRHoSyB/hITe/cpgmvSDfCAhsPEVfN
>nadJYQUCsdq/a29TY6BLPshh+5VQPc9HWcxEirVrzUvrphXIFXITAg7JUmNeKc/a
>9xvFH6UhvUnh6K5o/n64VGeC4wiiNJ3FvYeB6Cp+lkcvr1eRuLS7iWB5EsJdaGss
>BhfdeVL46biUlLuTWklTCqJnjfQ9kfJnNR9C+UZPWDcNK+QTsgH1SA4n7Xp3BpCm
>ck6ERiMK1evfzqc6ple8GZ238sR2KQJITe5Ijt5uTSBRnKa4WhjKUyOfaNbCn+HI
>RRtI22GW+cTiu9OnaEGHynDYANHcW+Zez9OI/4yRa1g+2Hhd4uJqUd4ntTm7wmnv
>LiEgfT0xbJxOnG7Y+8I8AB5918kV4z4WtcSC1R5/Ht7rwdnfp8DzzHUSUz/pMlnT
>XIP2TwgC6q3vnd8FgjPXaKZ/S2BLnidwA1Vv8zfC2/2N+olJlUAm/eYK6wpzH//P
>YWsRIKndOQwt0ZCK0um3
>=T9NM
>-END PGP SIGNATURE-

I installed the latest fedora-23 updates, which refreshed my DispVM savefile- 
the behavior is now back to normal. 

I unfortunately did not think to capture the old state so that it can be 
studied to understand the set of conditions that led to this unexpected 
persistence.

If there are any logs I can provide to understand what happened I'll be happy 
to dig them out. 

Thanks

Alex 

-- 
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/C83AA398-394C-455C-B632-FDA8013C668C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Debian minimal template?

[Ben Wika]

Perhaps I'm blind but I'm not seeing any mini package list in this thread. 
Only a discussion about who was going to post one. 

On Tuesday, 21 June 2016 10:06:50 UTC+10, Unman wrote:
>
> On Sun, Jun 19, 2016 at 07:39:45PM -0700, Ben Wika wrote: 
> > Hi, 
> > 
> > Not sure what's been happening on this subject since September (maybe 
> > discussion has moved?) but thought I'd make a contribution. Pretty new 
> to 
> > some of this so appreciate the feedback. 
> > 
> > If we install the base qubes template for Debian-8, and then do: 
> > 
> > dpkg-query -f '${binary:Package} ' -W >> ~/inst 
> > 
> > (refer https://wiki.debian.org/ListInstalledPackages ) 
> > 
> > Then we end up with a file in the home directory that lists all 
> installed 
> > packages. 
> > I can use "apt-mark auto" against all these items to clear out the list, 
> > but before doing the autoremove, there's obviously some that have to 
> > remain. 
> > 
> > To not 'break' the template completely, I'm finding that qubes-gui-agent 
> is 
> > the only one that needs to be set to manual. 
> > But for good measure I follow it up with the following apps which I know 
> > I'll be leaving in the minimal template: 
> > sudo apt-get install firefox-esr lxterminal leafpad xfe 
> > 
> > Finally we do the autoremove step and end up saving about 100MB. Not 
> alot, 
> > but I'm more focused on simply reducing the attack surface. 
> > 
> > Having done this, all seems to work fine but I imagine some features are 
> > missing behind the scenes (particularly qubes features). 
> > So I appreciate any further recommendations or suggestions as to why 
> debian 
> > minimal has to be any more complicated than what I've stated. 
> > 
> > Regards 
> > Ben 
> >   
> > 
> > On Thursday, 24 September 2015 07:15:42 UTC+10, Jason M wrote: 
> > > 
> > > On 22 September 2015 at 21:19, Unman  > > > wrote: 
> > > 
> > >> On Tue, Sep 22, 2015 at 07:37:37PM +, Axon wrote: 
> > >> > -BEGIN PGP SIGNED MESSAGE- 
> > >> > Hash: SHA512 
> > >> > 
> > >> > V??t ??est??k: 
> > >> > > I have created something like "minimal" Debian TemplateVM by 
> > >> > > removing (almost) all needless things. I can share the list of 
> > >> > > packages (e.g. output of apt-mark showmanual) if someone is 
> > >> > > interested. 
> > >> > > 
> > >> > > The sparse root.img has just 1.2GiB. OK, I admit it is not as 
> > >> > > minimal as Fedora. 
> > >> > > 
> > >> > 
> > >> > To be fair, fedora-21-minimal is actually larger than that after 
> doing 
> > >> > a normal yum update (without installing any new packages), and of 
> > >> > course it's almost always a good idea to update the software before 
> > >> > using the template for anything important. 
> > >> > 
> > >> > > Regards, V??t ??est??k 'v6ak' 
> > >> > > 
> > >> > > On Thursday, August 27, 2015 at 7:19:36 AM UTC+2, cprise wrote: 
> > >> > >> 
> > >> > >> On 08/26/2015 08:38 PM, nrgaway wrote: 
> > >> > >>> On 26 August 2015 at 16:04, Marek Marczykowski-G??recki 
> > >> > >>>  > >> > >>> > wrote: 
> > >> > >>> 
> > >> > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 
> > >> > >>> 
> > >> > >>> On Wed, Aug 26, 2015 at 05:50:41PM +, Qubed One wrote: 
> > >> >  Hi, just curious if anyone has any plans for a 
> > >> >  Debian-minimal 
> > >> >  
> > >> > >>> template 
> > >> >  for Qubes R3 (ITL or community-maintained)? 
> > >> > >>> 
> > >> > >>> Jason, does the minimal template flavor (which exists in 
> > >> > >> configuration) 
> > >> > >>> is usable in the current state? Could you provide short 
> > >> > >>> description 
> > >> > >> what 
> > >> > >>> functionality is there (like working as NetVM etc) and what 
> > >> > >>> requires additional packages. Something like the same for 
> > >> > >>> Fedora minimal: 
> > >> > >>> http://www.qubes-os.org/doc/Templates/FedoraMinimal/ 
> > >> > >>> 
> > >> > >>> Then I could simply build and upload the package. 
> > >> > >>> 
> > >> > >>> 
> > >> > >>> I will document this for you.  I do not use minimal template 
> > >> > >>> since it's not that much smaller than the regular one so I 
> > >> > >>> will need to test it all out again. 
> > >> > >>> 
> > >> > >>> -- 
> > >> > >> 
> > >> > >> Then it would be good to make the Debian template selections 
> > >> > >> similar to Fedora, with the supplied 'regular' Debian template 
> > >> > >> having desktop features and apps. This would allow a user 
> > >> > >> preferring Debian over Fedora to use their system as a desktop 
> > >> > >> immediately instead of going through manual steps. 
> > >> > >> 
> > >> > >> 
> > >> > >> 
> > >> > > 
> > >> > 
> > >> > -BEGIN PGP SIGNATURE- 
> > >> > 
> > >> > iQIcBAEBCgAGBQJWAa3+AAoJEJh4Btx1RPV8OGMQAOb/QipOtiPaBLpccTZaZsr5 
> > >> > yxfYrwjfFzpkLNhNU8ta0ClWl9MkoLp/tgUiAEfTC8c/DxA65UXGakKvmZrY4bfZ 
> > >> > 

[qubes-users] [Qubes R3.1] KeePassX Icon disappearing from AppVM menu

[Alex]

Hello everybody,
I noticed that recently, when I restart an AppVM that used to have the
KeePassX shortcut added to the application menu, said icon disappears
from the AppVM menu and has to be re-added with the usual tool.

Once added, the icon works properly again. I noticed (may or may not be
related) that typing "keepassx" in the "Run command in VM" popup window
(in Qubes VM Manager) does not start keepassx anymore (as it used to
do), and it has to be started via the menu icon.

I did not notice if this is related to an update of keepassx; my
hypothesis is that an update changed the way keepassx has to be started,
and somehow the dom0 shortcuts are not able to use the new method (maybe
there is some dirty cache?). How can I investigate further to help
identify the problem? Does it happen to anybody else?

-- 
Alex

-- 
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/e152a8ed-5080-c49e-2a54-34995a87be20%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] problem with running mullvad in proxyvm (DNS weirdness and autostart question)?

[Jane Jok]

Hello!

So, long story short, I've successfully configured a debian-based ProxyVM 
to run Mullvad's GUI client (I know one can use "vanilla OpenVPN" to 
connect to mullvad, I still prefer their GUI thing and decided to give it a 
try)

In a word, as long as one does not select "block internet access on 
connection failure" everything works.

However, there is a persistent DNS leak from any AppVM connected to the 
MullvadProxyVM (as detected by ipleak.net)

Also, if I take the "block connection if tunnel breaks" suggestion from 
here https://www.qubes-os.org/doc/vpn/ 
(that is, add

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
to my iptables in the MullvadProxyVM)

No connected AppVM can resolve hostnames (direct IP works tho)

I have, however, figured out a sort-a-kinda solution.

The solution I have found so far is to edit resolv.conf in AppVM to something 
external (like say Google's DNS, 8.8.8.8)

As long as AppVM's resolv.conf has 8.8.8.8 (or any other external nameserver) 
in it, everything works like a charm without any DNS leaks.

However, it the resolv.conf in AppVMs is not very persistent, and even if 
/rw/config/rc.local is modified to adjust resolv.conf, certain events (like 
changing netvms) trigger restoration of "old" resolv.conf

So, my first question is:

1) is there a way to prevent reset of manually edited resolv.conf, particularly 
in case when you change AppVM's netvm ?


My second question is 

2) is there is a way to automatically start a particular GUI application 
whenever a given VM starts ?

 


-- 
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/99bbe4f2-c35a-43e7-902e-7904b1134170%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.