[qubes-users] Protect AppVM init startup scripts:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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 -

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

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

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

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

[qubes-users] Scanner use in VM

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

[qubes-users] Re: Scanner use in VM

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

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

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

[qubes-users] HW RNG on dom0?

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

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

-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

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

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

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

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

[qubes-users] Skype Package Installation Issue

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

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

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

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

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