[qubes-users] Skype Package Installation Issue

2017-04-10 Thread Nick Geary 
I've installed the Skype .dpm package and installed it using dnf install
./..dpm. The installation completed without errors.

However, I don't see skype listed in the AppVm's list of available
shortcuts or within the installed software app.

I've also tried installing Skype on a Debian template with the same result.

How do I go about launching the Skype application post install?

The Skype web application has no option available for Web calls. The
section is greyed out, despite the webcam being loaded on the AppVm and
accessable by Cheese.

Any help is appreciated. It's been an interesting process. This being the
last step for a functional OS.

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

[qubes-users] Re: Scanner use in VM

2017-04-10 Thread pomonamikey 
On Monday, April 10, 2017 at 9:22:47 PM UTC-4, Daniel Acevedo wrote:
> I only see my scanner in dom0, using this command:
> 
>   # lsusb | grep Canon
> 
>   Bus 001 Device 005: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110
> 
> Of course it doesn't appear in the VMs.
> 
> I know I should assign the USB device where the scanner is plugged to
> the VM where I'm going to use it. The problem is that I don't know
> which USB Hub I should select (I have 3 different ones) and I'm afraid
> of making the wrong move and losing mouse and keyboard control in
> Qubes, forcing me to reinstall everything from scratch.
> 
> Any tips would be appreciated.
> 
> Thaks in advance,
> Daniel

You may be looking for qvm-usb.  Run in dom0 with no arguments.  The first 
column is the device name that you supply next to "qvm-usb -a $VM $DEVICE".

PS even if you made a mistake and lost mouse and keyboard, couldn't you power 
cycle and get them 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/ef7aaa22-f465-40da-bda4-cf99fb3f8690%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Scanner use in VM

2017-04-10 Thread Daniel Acevedo 
I only see my scanner in dom0, using this command:

  # lsusb | grep Canon

  Bus 001 Device 005: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110

Of course it doesn't appear in the VMs.

I know I should assign the USB device where the scanner is plugged to
the VM where I'm going to use it. The problem is that I don't know
which USB Hub I should select (I have 3 different ones) and I'm afraid
of making the wrong move and losing mouse and keyboard control in
Qubes, forcing me to reinstall everything from scratch.

Any tips would be appreciated.

Thaks in advance,
Daniel

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

Re: [qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Unman 
On Mon, Apr 10, 2017 at 03:39:26PM -0400, Chris Laprise wrote:
> On 04/10/2017 03:17 PM, Chris Laprise wrote:
> >On 04/10/2017 02:55 PM, Reg Tiangha wrote:
> >
> >I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and
> >re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty
> >much the only persistent thing left would be contents of /rw/home, which
> >is sort of a middle of the road between fully persistent /rw and using
> >dispVMs for everything.
> >
> >
> >>
> >>I'm definitely going to apply your scripts to my TemplateVMs soon now
> >>that I've been made aware, but I wish there were a way to turn off
> >>persistent /usr/local and to make AppVMs use the TemplateVM's version
> >>instead. I don't use the feature, so I would prefer that /usr/local gets
> >>wiped every time like everything else in the root file system since
> >>that's the behaviour I expected to happen when I first started using
> >>Qubes (I only discovered for myself that it wasn't the case when I was
> >>trying to figure out why a custom-compiled version of Wine that I had
> >>made and installed in my TemplateVM wasn't showing up in my AppVM; its
> >>default prefix is /usr/local, which is why). Is there a way to turn off
> >>persistent /usr/local? Or is it something that's baked-in?
> 
> BTW, /usr/local == /rw/usrlocal. Its a symlink.
> 

And it's set in the template - so if you don't want it open the template,
remove the symlink and move /usr/local.orig to /usr/local.
Then qubes based on that template wont have persistent /usr/local.

NB this will break torVMs and maybe other features of your Qubes.
An alternative approach would be to run tripwire against persistent
directories and monitor changes.

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

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-10 Thread qubenix 
qubenix:
> Andrew David Wong:
>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>>> Hi,
>>
>>> if you setup MAC randomization via network manager in a debian 9
>>> template as described here:
>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>> you still leak your hostname.
>>
>>> Once your MAC address is randomized you might also want to prevent the
>>> disclosure of your netvm's hostname to the network, since "sys-net"
>>> might be a unique hostname (that links all your random MAC addresses and
>>> the fact that you likely use qubes).
>>
>>> To prevent the hostname leak via DHCP option (12):
>>> - start the debian 9 template
>>> - open the file /etc/dhcpd/dhclient.conf
>>> - in line number 15 you should see "send host-name = gethostname();"
>>> - comment (add "#" at the beginning) or remove that line and store the file
>>> - reboot your netvm
>>
>>> I tested the change via inspecting dhcp requests and can confirm that
>>> the hostname is no longer included in dhcp requests.
>>
>>
>> Thanks. Added as a comment:
>>
>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>>
>>
> 
> Nice. I was just thinking about this after spending some time on my
> routers interface. Thanks for the post!
> 

After testing this, 'sys-net' still shows up on my router interface.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/e43a76ea-eba3-9aba-f127-eec495a7fcee%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread cooloutac 
On Monday, April 10, 2017 at 2:55:42 PM UTC-4, Reg Tiangha wrote:
> On 04/10/2017 12:41 PM, Chris Laprise wrote:
> >
> > Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin)
> > requires privilege escalation. If sudo has no auth process, then there
> > is no challenge for the attacker... they can change /rw/usrlocal in
> > any case.
> >
> > But also, they can change /rw/config including rc.local and firewall
> > scripts which run as root!
> >
> > BTW, my "better question" above really referred to the non-home areas
> > of /rw.
> >
> 
> Ah, got it. Well, that's something, I suppose.
> 
> >>
> >> While my versions do exactly what you would expect them to do, the
> >> difference is that each time you launch one of my versions, it starts up
> >> a key logging service (no root required!) in the background that
> >> persists even after you close the app that launched it. So for that
> >> entire session (assuming that AppVM is connected to the Internet), I can
> >> capture all of your keystrokes. And because /usr/local is persistent and
> >> you probably don't constantly check /usr/local for changes (because
> >> again, you're not paranoid), those programs will stick around and launch
> >> the next time you access the VM.
> >
> > But this is a problem for things like ~/.bashrc as well. Using PATH=
> > or alias, attacker could divert you to a phony `git` command that logs
> > your github password before executing the intended operation.
> >
> > That's why I suggest people consider enabling sudo auth and securing
> > shell init scripts in /home (see my post "Protect AppVM init startup
> > scripts"). You could even have an in-template startup script that
> > resets most of /rw (root-owner bits) to defaults really shouldn't
> > be hard.
> >
> > In that case, your attack scenario hinges on having a Linux escalation
> > exploit, and even then it might not last long enough for you to
> > collect valuable info (e.g. resets or updates occur that patch the
> > vulnerability).
> >
> >
> 
> Still, though, let's say such Linux escalation exploit exists and a
> malicious person can access the AppVM's (let's set aside TemplateVMs for
> a moment) file system. They can't stick anything in most places in /
> because they'll disappear when the VM shuts down. Changes in /home/user
> could work, but because users interact with /home on a daily basis
> through shells or file browsers, the likelihood of them noticing changes
> there might be a bit higher so that might not be the smartest move. But
> how many here on this list regularly check their app/sys VMs for
> modifications to /usr/local? I'm doubting it's very many, and that I
> guess is my main concern.
> 
> Some people may not even be aware that it *is* persistent, so people who
> use something like Whonix who've been targeted might even have stuff
> living in /usr/local right now and may not even know it (since privilege
> escalation exploits in tor-browser seem to be found every so often).
> 
> I'm definitely going to apply your scripts to my TemplateVMs soon now
> that I've been made aware, but I wish there were a way to turn off
> persistent /usr/local and to make AppVMs use the TemplateVM's version
> instead. I don't use the feature, so I would prefer that /usr/local gets
> wiped every time like everything else in the root file system since
> that's the behaviour I expected to happen when I first started using
> Qubes (I only discovered for myself that it wasn't the case when I was
> trying to figure out why a custom-compiled version of Wine that I had
> made and installed in my TemplateVM wasn't showing up in my AppVM; its
> default prefix is /usr/local, which is why). Is there a way to turn off
> persistent /usr/local? Or is it something that's baked-in?

absolutely! great discussion!

-- 
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/3cfb5ea6-a88a-44f4-a364-a7d19b34e22e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Chris Laprise 

On 04/10/2017 03:17 PM, Chris Laprise wrote:

On 04/10/2017 02:55 PM, Reg Tiangha wrote:

I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and
re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty
much the only persistent thing left would be contents of /rw/home, which
is sort of a middle of the road between fully persistent /rw and using
dispVMs for everything.




I'm definitely going to apply your scripts to my TemplateVMs soon now
that I've been made aware, but I wish there were a way to turn off
persistent /usr/local and to make AppVMs use the TemplateVM's version
instead. I don't use the feature, so I would prefer that /usr/local gets
wiped every time like everything else in the root file system since
that's the behaviour I expected to happen when I first started using
Qubes (I only discovered for myself that it wasn't the case when I was
trying to figure out why a custom-compiled version of Wine that I had
made and installed in my TemplateVM wasn't showing up in my AppVM; its
default prefix is /usr/local, which is why). Is there a way to turn off
persistent /usr/local? Or is it something that's baked-in?


BTW, /usr/local == /rw/usrlocal. Its a symlink.

--

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

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

Re: [qubes-users] HDMI-related threats in Qubes OS

2017-04-10 Thread Vít Šesták 
On Sunday, April 9, 2017 at 8:49:47 PM UTC+2, Jean-Philippe Ouellet wrote:
> On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták
> <…@v6ak.com>
> wrote:
> >
> > * DDC (PIN 15+16) – needed for getting the resolution etc., present even in 
> > current version of VGA. While there is some attack surface, it seems to be 
> > rather small.
> 
> Note that this is not strictly necessary for things to work though.

For VGA, it seems to be clearly true, as DDC was added some time after initial 
VGA release.

But I am not sure if the same applies to HDMI or even for DVI. They don't seem 
to be designed to work without DDC.

Regards,
Vít Šesták 'v6ak'

-- 
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/7b60fde6-00f6-47fa-b8af-af72ae4bac30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HDMI-related threats in Qubes OS

2017-04-10 Thread Vít Šesták 
> what about vga or dvi wires?

Frankly, my main interest is HDMI. But I have briefly looked at VGA and DVI 
pinouts. It seems that the only input channels are hotplug (if you count this) 
and DDC (for resolutions etc.). Plus older VGA seems to have some pre-DDC 
mechanism called “Monitor ID”. For VGA, you can see scheme 
http://pinouts.ru/Video/VGA15_pinout.shtml . The “Dir” column is helpful, 
though it seems to be incorrect at line “I2C bidirectional data line”.

> Qubes already ignores hdmi sound driver in my case lol.

Well, I am not sure if this is intentional, but I don't think so.

> Because really how can we even trust its hardware, its another separate pc 
> outside of qubes.

Well, you do trust you hardware at some degree. Without trusted HW, you cannot 
trust it runs the SW properly and it does not spy you in other means, e.g., by 
sending screen content somewhere. Malware in a compromised digital TV could do 
so and neither Qubes nor cut wires can prevent it. But maybe you decide to 
trust the TV just partially (e.g., public presentation), so you don't read 
top-secret messages etc. here.

>  Same goes for printers if you using it,  you already giving up some privacy 
> regardless of Qubes.

Mostly true, but a bit vague. But the situation is the same as with monitors – 
choose your level of trust and then behave accordingly.

Regards,
Vít Šesták 'v6ak'

-- 
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/63c386f1-6e09-430e-bf4a-541d4d59abee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Chris Laprise 

On 04/10/2017 02:55 PM, Reg Tiangha wrote:

On 04/10/2017 12:41 PM, Chris Laprise wrote:


Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin)
requires privilege escalation. If sudo has no auth process, then there
is no challenge for the attacker... they can change /rw/usrlocal in
any case.

But also, they can change /rw/config including rc.local and firewall
scripts which run as root!

BTW, my "better question" above really referred to the non-home areas
of /rw.



Ah, got it. Well, that's something, I suppose.



While my versions do exactly what you would expect them to do, the
difference is that each time you launch one of my versions, it starts up
a key logging service (no root required!) in the background that
persists even after you close the app that launched it. So for that
entire session (assuming that AppVM is connected to the Internet), I can
capture all of your keystrokes. And because /usr/local is persistent and
you probably don't constantly check /usr/local for changes (because
again, you're not paranoid), those programs will stick around and launch
the next time you access the VM.


But this is a problem for things like ~/.bashrc as well. Using PATH=
or alias, attacker could divert you to a phony `git` command that logs
your github password before executing the intended operation.

That's why I suggest people consider enabling sudo auth and securing
shell init scripts in /home (see my post "Protect AppVM init startup
scripts"). You could even have an in-template startup script that
resets most of /rw (root-owner bits) to defaults really shouldn't
be hard.

In that case, your attack scenario hinges on having a Linux escalation
exploit, and even then it might not last long enough for you to
collect valuable info (e.g. resets or updates occur that patch the
vulnerability).




Still, though, let's say such Linux escalation exploit exists and a
malicious person can access the AppVM's (let's set aside TemplateVMs for
a moment) file system. They can't stick anything in most places in /
because they'll disappear when the VM shuts down. Changes in /home/user
could work, but because users interact with /home on a daily basis
through shells or file browsers, the likelihood of them noticing changes
there might be a bit higher so that might not be the smartest move. But
how many here on this list regularly check their app/sys VMs for
modifications to /usr/local? I'm doubting it's very many, and that I
guess is my main concern.

Some people may not even be aware that it *is* persistent, so people who
use something like Whonix who've been targeted might even have stuff
living in /usr/local right now and may not even know it (since privilege
escalation exploits in tor-browser seem to be found every so often).


Some people, maybe. But also notice more than a couple of Qubes users 
prefer to use dispVMs for most tasks. That is another way around the 
risk, in addition to the way I suggested.


I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and 
re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty 
much the only persistent thing left would be contents of /rw/home, which 
is sort of a middle of the road between fully persistent /rw and using 
dispVMs for everything.





I'm definitely going to apply your scripts to my TemplateVMs soon now
that I've been made aware, but I wish there were a way to turn off
persistent /usr/local and to make AppVMs use the TemplateVM's version
instead. I don't use the feature, so I would prefer that /usr/local gets
wiped every time like everything else in the root file system since
that's the behaviour I expected to happen when I first started using
Qubes (I only discovered for myself that it wasn't the case when I was
trying to figure out why a custom-compiled version of Wine that I had
made and installed in my TemplateVM wasn't showing up in my AppVM; its
default prefix is /usr/local, which is why). Is there a way to turn off
persistent /usr/local? Or is it something that's baked-in?





--

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

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

[qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Reg Tiangha 
On 04/10/2017 12:41 PM, Chris Laprise wrote:
>
> Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin)
> requires privilege escalation. If sudo has no auth process, then there
> is no challenge for the attacker... they can change /rw/usrlocal in
> any case.
>
> But also, they can change /rw/config including rc.local and firewall
> scripts which run as root!
>
> BTW, my "better question" above really referred to the non-home areas
> of /rw.
>

Ah, got it. Well, that's something, I suppose.

>>
>> While my versions do exactly what you would expect them to do, the
>> difference is that each time you launch one of my versions, it starts up
>> a key logging service (no root required!) in the background that
>> persists even after you close the app that launched it. So for that
>> entire session (assuming that AppVM is connected to the Internet), I can
>> capture all of your keystrokes. And because /usr/local is persistent and
>> you probably don't constantly check /usr/local for changes (because
>> again, you're not paranoid), those programs will stick around and launch
>> the next time you access the VM.
>
> But this is a problem for things like ~/.bashrc as well. Using PATH=
> or alias, attacker could divert you to a phony `git` command that logs
> your github password before executing the intended operation.
>
> That's why I suggest people consider enabling sudo auth and securing
> shell init scripts in /home (see my post "Protect AppVM init startup
> scripts"). You could even have an in-template startup script that
> resets most of /rw (root-owner bits) to defaults really shouldn't
> be hard.
>
> In that case, your attack scenario hinges on having a Linux escalation
> exploit, and even then it might not last long enough for you to
> collect valuable info (e.g. resets or updates occur that patch the
> vulnerability).
>
>

Still, though, let's say such Linux escalation exploit exists and a
malicious person can access the AppVM's (let's set aside TemplateVMs for
a moment) file system. They can't stick anything in most places in /
because they'll disappear when the VM shuts down. Changes in /home/user
could work, but because users interact with /home on a daily basis
through shells or file browsers, the likelihood of them noticing changes
there might be a bit higher so that might not be the smartest move. But
how many here on this list regularly check their app/sys VMs for
modifications to /usr/local? I'm doubting it's very many, and that I
guess is my main concern.

Some people may not even be aware that it *is* persistent, so people who
use something like Whonix who've been targeted might even have stuff
living in /usr/local right now and may not even know it (since privilege
escalation exploits in tor-browser seem to be found every so often).

I'm definitely going to apply your scripts to my TemplateVMs soon now
that I've been made aware, but I wish there were a way to turn off
persistent /usr/local and to make AppVMs use the TemplateVM's version
instead. I don't use the feature, so I would prefer that /usr/local gets
wiped every time like everything else in the root file system since
that's the behaviour I expected to happen when I first started using
Qubes (I only discovered for myself that it wasn't the case when I was
trying to figure out why a custom-compiled version of Wine that I had
made and installed in my TemplateVM wasn't showing up in my AppVM; its
default prefix is /usr/local, which is why). Is there a way to turn off
persistent /usr/local? Or is it something that's baked-in?


-- 
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/ocgkev%24rpd%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Chris Laprise 

On 04/10/2017 02:04 PM, Reg Tiangha wrote:

On 04/10/2017 11:51 AM, Chris Laprise wrote:

Given the default Qubes security model, its not supposed to matter if
malware can persist. Even the read-only nature of root on
template-based VMs is supposed to be only a beneficial footnote.

OTOH, I'd say your inquiry implies that internal VM security matters
to you to at least some degree (no unguarded sudo, etc.) otherwise
there is nothing to distinguish the /rw/usrlocal persistence issue
from persistence via autostart scripts in /home (which can normally
run sudo without any resistence).

With sudo authentication enabled, the question of persistence becomes
similar to that for a standalone VM... if a malware process can
escalate privs (even via a temporary kernel bug) it can persist in the
root-owned /rw/usrlocal even in a template-based VM.

Maybe a better question is: Should we have the ability to turn off
execution of /rw contents in templates?



Well, here's a simple for-instance. Say you're a developer of a rival
firm and I want to know all of your secrets so I target you. I know
you're an emacs user, and I know you use Qubes. I also know you're
paranoid enough to segregate all of your development work into one Qubes
VM (yay!), but *not* paranoid enough to cut off that VM from the
Internet (boo!), so not only do you do dev work in it, but you use the
web browser (Chromium, in this case) to interact with websites related
to your work (ex. github) but not to do anything else.

So (somehow, let's say MITM) I find a way to access your file system and
put stuff there. I know that most things get destroyed as soon as the VM
is shutdown, so what I do is I find a way to infect your /usr/local/bin
with malicious versions of Chromium and emacs and ls and all the other
utilities that you'd probably use on a daily basis.


Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) 
requires privilege escalation. If sudo has no auth process, then there 
is no challenge for the attacker... they can change /rw/usrlocal in any 
case.


But also, they can change /rw/config including rc.local and firewall 
scripts which run as root!


BTW, my "better question" above really referred to the non-home areas of 
/rw.




While my versions do exactly what you would expect them to do, the
difference is that each time you launch one of my versions, it starts up
a key logging service (no root required!) in the background that
persists even after you close the app that launched it. So for that
entire session (assuming that AppVM is connected to the Internet), I can
capture all of your keystrokes. And because /usr/local is persistent and
you probably don't constantly check /usr/local for changes (because
again, you're not paranoid), those programs will stick around and launch
the next time you access the VM.


But this is a problem for things like ~/.bashrc as well. Using PATH= or 
alias, attacker could divert you to a phony `git` command that logs your 
github password before executing the intended operation.


That's why I suggest people consider enabling sudo auth and securing 
shell init scripts in /home (see my post "Protect AppVM init startup 
scripts"). You could even have an in-template startup script that resets 
most of /rw (root-owner bits) to defaults really shouldn't be hard.


In that case, your attack scenario hinges on having a Linux escalation 
exploit, and even then it might not last long enough for you to collect 
valuable info (e.g. resets or updates occur that patch the vulnerability).



--

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

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

[qubes-users] Re: Persistent /usr/local: Are there risks?

2017-04-10 Thread Reg Tiangha 
On 04/10/2017 11:51 AM, Chris Laprise wrote:
> Given the default Qubes security model, its not supposed to matter if
> malware can persist. Even the read-only nature of root on
> template-based VMs is supposed to be only a beneficial footnote.
>
> OTOH, I'd say your inquiry implies that internal VM security matters
> to you to at least some degree (no unguarded sudo, etc.) otherwise
> there is nothing to distinguish the /rw/usrlocal persistence issue
> from persistence via autostart scripts in /home (which can normally
> run sudo without any resistence).
>
> With sudo authentication enabled, the question of persistence becomes
> similar to that for a standalone VM... if a malware process can
> escalate privs (even via a temporary kernel bug) it can persist in the
> root-owned /rw/usrlocal even in a template-based VM.
>
> Maybe a better question is: Should we have the ability to turn off
> execution of /rw contents in templates?
>

Well, here's a simple for-instance. Say you're a developer of a rival
firm and I want to know all of your secrets so I target you. I know
you're an emacs user, and I know you use Qubes. I also know you're
paranoid enough to segregate all of your development work into one Qubes
VM (yay!), but *not* paranoid enough to cut off that VM from the
Internet (boo!), so not only do you do dev work in it, but you use the
web browser (Chromium, in this case) to interact with websites related
to your work (ex. github) but not to do anything else.

So (somehow, let's say MITM) I find a way to access your file system and
put stuff there. I know that most things get destroyed as soon as the VM
is shutdown, so what I do is I find a way to infect your /usr/local/bin
with malicious versions of Chromium and emacs and ls and all the other
utilities that you'd probably use on a daily basis.

While my versions do exactly what you would expect them to do, the
difference is that each time you launch one of my versions, it starts up
a key logging service (no root required!) in the background that
persists even after you close the app that launched it. So for that
entire session (assuming that AppVM is connected to the Internet), I can
capture all of your keystrokes. And because /usr/local is persistent and
you probably don't constantly check /usr/local for changes (because
again, you're not paranoid), those programs will stick around and launch
the next time you access the VM.

That's just one idea. My imagination isn't as good as others though, so
I'm sure other people can think of nasty things that can be done that
doesn't require privilege escalation. Sure, you can mitigate a lot of
this by cutting off VM access to the network entirely, but that's
because you're smart. The guy next to you may not be as smart (or
paranoid). While there would be some merit to cutting off execution in
/rw areas, for the most part, the way Qubes is set up works well and
that might be going too far. I do think a persistent /usr/local should
be optional, however, and ideally, be disabled by default and only
turned on if needed. There are some cases where one may want to install
custom packages of software that they may have compiled themselves and
would rather put them in /usr/local rather than /usr to help keep the
file system clean. ~/bin isn't much of a problem since a) it's last in
the PATH and b) if you're putting stuff in there, you definitely do so
with the intent to use it only on that AppVM's user account.


-- 
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/ocgheb%244tm%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Display Resolution in Win 7 & Qubes 3.2 -> Problem of Qubes Windows Tools 3.2.2.3

2017-04-10 Thread 'Philipp Raschdorff' via qubes-users 

Hello,

after discovering that my Windows 7 HVM which worked perfectly under 
Qubes OS 3.1 causing problems with changing the display resolution under 
Qubes OS 3.2 I made some further research.


It seems that there is a problem with Qubes Tools 3.2.2.3

- Plain Install of Qubes OS 3.2
- Installation of a Windows 7 HVM accoring to the documentation
- Full Installation of Qubes Windows Tools 3.2.2.3 (except of the Xen PV 
Disk Driver)


=> Display resolution can only be set to Full Resolution and 800x600

I've then uninstalled Qubes Tools, and reinstalled it, without the Qubes 
Tools graphic drivers.

Strangely I am then able to change the resolution from within windows.

So it seems to me, that something seems to be broken with Qubes Tools 
3.2.2.3 under Qubes OS 3.2 regarding the graphic drivers.


Is anyone else discovering the same problem?

- P

--
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/b859b4ba-e86a-77b2-5a59-330865ae0bf1%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Persistent /usr/local: Are there risks?

2017-04-10 Thread Chris Laprise 

On 04/10/2017 01:16 PM, Reg Tiangha wrote:

According to the docs, both /home and /usr/local are persistent in an AppVM:

https://www.qubes-os.org/doc/software-update-vm/

The default PATH in a Qubes VM (Debian 8) looks like this:

user@Email:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/.local/bin:/home/user/bin

Unless I'm mistaken, it'll search /usr/local/bin first for a binary, and
if it doesn't find it there, it'll go on to the next directory which is
/usr/bin. If it does find it, then the search stops and the /usr/local
version gets executed, correct?

So a silly question:  What's stopping an adversary from placing commonly
named but malicious binaries into /usr/local/bin like ls or
qrexec-related binaries? Unless the scripts and programs that call those
programs are hard-coded to use the absolute paths (ex. /bin/dmesg rather
than just dmesg), would there not be a danger that the /usr/local
versions could be invoked instead in *some* situations? Because
/usr/local is persistent, a user may not necessarily know that stuff may
have been placed in that directory, unless they're actively scanning it
for changes, so if they regularly do work in the default bash shell,
they may never know that their 'ls' command or similar may have been
compromised. I don't mind a persistent /home so much since that can be
useful, and I *can* see some use for a persistent /usr/local in some
circumstances, but is there a way to turn the feature off for those who
don't need it and make an AppVM use the TemplateVM's version instead?


Given the default Qubes security model, its not supposed to matter if 
malware can persist. Even the read-only nature of root on template-based 
VMs is supposed to be only a beneficial footnote.


OTOH, I'd say your inquiry implies that internal VM security matters to 
you to at least some degree (no unguarded sudo, etc.) otherwise there is 
nothing to distinguish the /rw/usrlocal persistence issue from 
persistence via autostart scripts in /home (which can normally run sudo 
without any resistence).


With sudo authentication enabled, the question of persistence becomes 
similar to that for a standalone VM... if a malware process can escalate 
privs (even via a temporary kernel bug) it can persist in the root-owned 
/rw/usrlocal even in a template-based VM.


Maybe a better question is: Should we have the ability to turn off 
execution of /rw contents in templates?


--

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

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

[qubes-users] Persistent /usr/local: Are there risks?

2017-04-10 Thread Reg Tiangha 
According to the docs, both /home and /usr/local are persistent in an AppVM:

https://www.qubes-os.org/doc/software-update-vm/

The default PATH in a Qubes VM (Debian 8) looks like this:

user@Email:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/.local/bin:/home/user/bin

Unless I'm mistaken, it'll search /usr/local/bin first for a binary, and
if it doesn't find it there, it'll go on to the next directory which is
/usr/bin. If it does find it, then the search stops and the /usr/local
version gets executed, correct?

So a silly question:  What's stopping an adversary from placing commonly
named but malicious binaries into /usr/local/bin like ls or
qrexec-related binaries? Unless the scripts and programs that call those
programs are hard-coded to use the absolute paths (ex. /bin/dmesg rather
than just dmesg), would there not be a danger that the /usr/local
versions could be invoked instead in *some* situations? Because
/usr/local is persistent, a user may not necessarily know that stuff may
have been placed in that directory, unless they're actively scanning it
for changes, so if they regularly do work in the default bash shell,
they may never know that their 'ls' command or similar may have been
compromised. I don't mind a persistent /home so much since that can be
useful, and I *can* see some use for a persistent /usr/local in some
circumstances, but is there a way to turn the feature off for those who
don't need it and make an AppVM use the TemplateVM's version instead?


-- 
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/ocgekl%24q3h%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Protect AppVM init startup scripts:

2017-04-10 Thread Chris Laprise 
Here is a small script for Linux templates that protects files executed 
on startup by...


bash
sh
Gnome
KDE
Xfce
X11

Together with enabling sudo authentication, this is a simple way to make 
template-based VMs less hospitable to malware.


LINK: https://github.com/tasket/Qubes-VM-hardening

--

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

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

Re: [qubes-users] HW RNG on dom0?

2017-04-10 Thread Jean-Philippe Ouellet 
On Mon, Apr 10, 2017 at 8:23 AM, Johannes Graumann
 wrote:
> I am wondering whether
> 1) under QubesOS a (USB) HW RNG like http://www.bitbabbler.org/ is usable

Yes. You would need to do some work to make it feed entropy in a safe
way though.

> and if yes
> 2) where attaching it would make most sense? sys-net? dom0?

sys-usb, and have a qrexec service in dom0 to collect entropy from it
and mix in into the dom0 pool, which will eventually propagate to
other VMs.

> Can Xen VM's be set up to feed on entropy provided by the host?

Yes, in fact we already do so.

Discussion:
- https://github.com/QubesOS/qubes-issues/issues/673
- https://groups.google.com/d/topic/qubes-devel/5wI8ygbaohk/discussion

Implementation:
- 
https://github.com/QubesOS/qubes-core-agent-linux/blob/a69acdabbfb60d88971644cfad50165091a66b9f/init/functions#L95-L101
- 
https://github.com/QubesOS/qubes-core-admin/blob/19e68bacf22cd965e819dfa4913740ecc14d1c40/core-modules/000QubesVm.py#L1152-L1158

Cheers,
Jean-Philippe

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

[qubes-users] HCL - GIGABYTE GB-BSi5A-6200

2017-04-10 Thread Philippe Doublet 

Dear Qubes users,

I am a recent Qubes user and especially bought this config to run qubes. 
Totally happy with it and hopefully using it in a secure way.


Best regards,

Philippe


--
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/3e41d4f4-cb61-f071-13cb-a266a0c62db8%40crans.org.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-GIGABYTE-GB_BSi5A_6200-20170410-143039.yml
Description: application/yaml


Qubes-HCL-GIGABYTE-GB_BSi5A_6200-20170410-143039.cpio.gz
Description: application/gzip

[qubes-users] HW RNG on dom0?

2017-04-10 Thread Johannes Graumann 
I am wondering whether 
1) under QubesOS a (USB) HW RNG like http://www.bitbabbler.org/ is
usable

and if yes
2) where attaching it would make most sense? sys-net? dom0? Can Xen
VM's be set up to feed on entropy provided by the host?

Thanks for any hint.

Sincerely, Joh

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

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-10 Thread Chris Laprise 

On 04/09/2017 06:25 PM, Joonas Lehtonen wrote:

Hi,

if you setup MAC randomization via network manager in a debian 9
template as described here:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/
you still leak your hostname.



I have seen reports this change in dhcp settings did not work[1], but 
maybe that was a bug that was fixed.


Unfortunately, the effect of these measures is likely to be limited 
until some changes are made for common NICs[2].




1. 
https://serverfault.com/questions/557120/how-do-i-stop-a-linux-computer-from-sending-a-dhcp-hostname


2. https://arxiv.org/pdf/1703.02874v1.pdf

--

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

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

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

2017-04-10 Thread Joonas Lehtonen 
>> Once your MAC address is randomized you might also want to prevent the
>> disclosure of your netvm's hostname to the network, since "sys-net"
>> might be a unique hostname (that links all your random MAC addresses and
>> the fact that you likely use qubes).
> 
>> To prevent the hostname leak via DHCP option (12):
>> - start the debian 9 template
>> - open the file /etc/dhcpd/dhclient.conf

sorry there is a typo in the file path:
correct file:
/etc/dhcp/dhclient.conf

>> - in line number 15 you should see "send host-name = gethostname();"
>> - comment (add "#" at the beginning) or remove that line and store the file
>> - reboot your netvm
> 
>> I tested the change via inspecting dhcp requests and can confirm that
>> the hostname is no longer included in dhcp requests.
> 
> 
> Thanks. Added as a comment:
> 
> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628

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/da8baa69-eefc-674a-e7d6-e44c4163dabc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] HVM console windows on "hidpi" displays

2017-04-10 Thread pomonamikey 
Hi all .. I am new here.  I have been hacking on Unix systems for about 20 
years, but no prior experience with Xen outside of AWS.

I have a 2016-generation Dell XPS 13 (9360) which has a 13-inch, 3200x1800 
display.  Have been struggling through all of the hacks and tricks necessary to 
get programs to render at a reasonable size.  Will summarize those at the end 
for the benefit of anybody that happens to find this message first in the 
future.[1]

I have just one thing that still runs in Tinyvision, which is the text console 
that comes up with an HVM guest.  Having a hard time figuring out how that 
window gets rendered.  Have tried all the following:


## Theory 1: That window cares what the X server reports via e.g. xdpyinfo.

If this is right, then it might be fixed if we can get 'xrandr --dpi 192' to 
happen at the right place at server start.  Created a setdpi.sh that runs 
'xrandr --dpi 192 && date >> /tmp/setdpi.sh.log'.

Put it at /etc/X11/xinit/xinitrc.d/setdpi.sh
>> It runs, and has no effect.

Put it as the first thing in /etc/X11/xinit/xinitrc:
>> It runs, and has no effect.

Set it as display-setup-script in /etc/lightdm/lightdm.conf:
>> It runs, and has no effect.

Tried it as session-setup-script in /etc/lightdm/lightdm.conf:
>> It runs, and has no effect.

Also tried "DisplaySize 423 238" in xorg.conf.  No effect.

In all cases, the HVM console is still tiny, and at startup, xdpyinfo shows 
96x96.  This is odd because after login, if I run 'xrandr --dpi 192' by hand, 
xdpyinfo changes to show 192x192.  (To get this far required trying several 
kernels and finding that 4.8.12-12.pvops.qubes.x86_64 from qubes unstable repo 
works, BTW.)


## Theory 2: It's the guest OS's problem to ask for a bigger display.

I was surprised to discover that an OpenBSD HVM guest (which doesn't even work 
right in most ways), is capable of changing video modes by starting an X 
server, and the host display gives it a new window at the new resolution.  This 
is also in Tinyvision and not resizable, but that is probably solvable inside 
the guest OS eventually.

I tried many permutations of OpenBSD wsconscfg, and FreeBSD vt (vidcontrol 
etc), to see if the guest OS could be persuaded to change modes on its fake VGA 
device, or at least just throw huge fonts at it.  No good.  The xen device 
doesn't provide whatever interface the console drivers are looking for, and 
nothing works.

I tried hacking up the xen configs to force the HVMs to start with every known 
xen video backend: vga, cirrus, vmvga, xen, vbox, qxl, virtio, and gop.  All 
either unsupported or work the same as the default (xen).


## Theory 3: The window is drawn by qubes-guid.

Have read some of the code in qubes-gui-agent-xen-hvm-stubdom, and maybe 
eventually the answer is in here.

There is a tantalizing clue in /var/log/xen/console/guest-xxx-dm.log, which 
gets messages like "dumping mfns: n=282, w=720, h=400, bpp=32."  This traces 
back to line 171 of qubes-gui.c, and 720x400 is the size of the Tinyvision 
window.


## Theory 4: The simulated vga text console is never going to work.

I could ssh to an HVM from another VM with a working terminal.  Or I can try to 
get 'xl console' to work.  But both cases will require some modifications in 
the guest OS first, and it's painful to do anything non-trivial in Tinyvision.


Anyone recognize any clues here, or have an explanation of how the console 
window gets drawn?


-

[1] Some or all of the following were necessary to apply in each VM:

+ Xfce "Appearance" settings panel - set "Custom DPI setting" on Fonts tab.

+ Xfce "Window Manager" settings panel has a theme named "hidpi" which helps 
with window frames.

+ Some X applications react to 'xrandr --dpi 192'.  Unclear which ones or why.  
You can verify if this had an effect by asking 'xdpyinfo | grep -b2 resolution'

+ Some gtk-based UI elements are affected by running:
gsettings set org.gnome.desktop.interface scaling-factor 2
gsettings set org.gnome.desktop.interface text-scaling-factor 0.75

+ One Debian-8 VM would not persist the Xft change at startup until I did:
echo "Xft/DPI 196608" >> ~/.xsettingsd # that number is 192*1024

-- 
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/9f98b327-80ef-4cc5-b6d2-2e9b3b4a07f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.