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

2017-04-09 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-04-01 13:58, Vít Šesták wrote:
> Hello,
> I've realized that HDMI offers not only graphical/sound output, but also many 
> inputs. Well, some inputs are expected (listing of available output modes 
> etc. works AFAIK even with VGA), but others can be more or less surprising:
> 
> * audio return channel
> * CEC
> * ethernet (!)
> * maybe even more
> 
> [...]
> 

Very interesting discussion so far. Cross-linking with tracking issue:

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

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

iQIcBAEBCgAGBQJY6wJbAAoJENtN07w5UDAwLokQALhQxKKOMRyoMU17XBKT4CFe
btKsznsSREzwoKwOphV0j1KBSijukjDEYVm/SVfLQfxQLRrPq+Eyv3g0D4qsM1AQ
mzfJLB3On8QAq0jydUaoPDqApgKXYQQ7CKwt016p1+VUb76UR+O+89oDlISBYfiw
7qBq2gwz+Lc3Fei+27pEv22HxXSkxtNZMKtzKiMgXou2l/H3eqWvpYOlbtzWCU1p
gtyj+4sVfJ9YGKWvutN/DzOyIXb1sp0DpzaZCGGpq/5NCKM5Ufg+EYbxCAduDxp/
m0sxFVnRhwcIP4zGGoMW5RHnZtwBHLP6llP55UalWaEolVH6nsS7kRELmfgYm7fw
/sALreuOh/TOv2fFsDN5/Qrw/sFq3yIzQn5NHfxjYnSF5+uGWTEqa854nTPIIQR4
KFPb/BsbLPGoA+f+zDOCcKGBnTEoYpy6LL8OmaYcIODqZkDRQlK0txs4F0DHdob9
+zGwXIj94eB6XdIUACCz2kZeu7hXDRcFHlDuJ5WHn/Effuy45DQEbCztb0vDtAxd
XH7mZ19Hz6GvkCzqNp9R5BSLeubDKbCx1HAmdmaa0cxsyUKt/UHIYthSrMKvPfPF
GTexdTzomHs7v1LlOGT2TnYWX0xowtVWvTBFinTXusw9wfLdj7BN/REFEVDaOT/d
no3IYSVHkscO/TcNGMcI
=PAeU
-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/3227f0e8-12de-b6b1-81de-c46cb2393762%40qubes-os.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-09 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

iQIcBAEBCgAGBQJY6wEhAAoJENtN07w5UDAwdI8P/2+Rl5K73adR4MiQAACLDpZj
jZl9YKskHKqBUMR+m0T2LkD2yw+cGpkOXiDjypTy2eYcsPqfbp0PZnggSK/9IpKM
ZjIjOmoYkm6dfp81HJbz8pqmlf6v2fEZ8CaeHqV6kZnxzlq1aqwwVwtMfrRH2Lqm
HMOA5Hlh+kCCysFC1DvoaJAOL+yv1HlC0lJsCtAVMw0pJadMxNXE8+JGywyeT1sY
OJ+VqOcp9sCqVta/jeWbLx/WzIjqkkDPDtVhuC9KC5uu0pg8zv76ah+nBoSbO5dO
Byvj91yMsCtaDFr684Yq8YlKJLFu2TSIBoUrh5/LHOPp1QYrpOTiSjSX1tTBAYd2
pk3Sid5XxoGabSPxMHT4VF0vCQktPp4WeXjy1oRAdTyZSjx8VF9oGrZQuFzP0Fey
2Zp4nYAKXjj5Ellf89ogxObiAqmZwyMCBerFfvSEnCrtWkxdMn+8s0b9pVf2ewNe
mKKW5YxyDVCpSlSmiewkUzLtihOOC7rzOanTt72ZxEpF6uwEiT8vA6V6uuEJKQrv
TkQaLaXB1UnSN7mxstRVu5gi53sX1n9znBbJLiQmNcRUv/+E63Uj1biP21caOqyZ
zmiffOUSUc72dJvnNsCVz9sfygTHLUKVybn5QQ0oEl1Zt4yeeFY7Cq860uEqr5lQ
a6JXYZkSDeL99PRgd61w
=noLw
-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/3c49d353-59f2-7917-9f16-e69a262b21fc%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: coldkernel status update

2017-04-09 Thread Reg Tiangha
On 04/09/2017 09:49 AM, Patrick Schleizer wrote:
> Reg Tiangha:
>> Thanks for all the hard work! WillyPillow just pointed out to me today
>> on the qubes-devel mail list that installing busybox and updating
>> initramfs in Whonix is all you need to do to get it to boot with
>> coldkernel,
> busybox will be installed on Whonix 14 by default.
>
> https://github.com/Whonix/anon-meta-packages/commit/92c70963ed34953a81f8e53273453926b738ea18
>
> On the other hand, what about adding busybox as a dependency to the
> coldkernel Debian package?
>
> Cheers,
> Patrick
>
It should probably also be added as a dependancy to
qubes-kernel-vm-support as well since the script that needs it comes
from that package.

I know that the package is currently in current-testing at the moment,
but is it too late to modify it to add busybox as a dependency? That
way, if/when it gets pushed out to stable, anyone wanting to use it on a
Whonix template won't have to do anything extra to get coldkernel or
other local kernels to work on 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/oceuto%247n5%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] realized why I always lose sound in the vms

2017-04-09 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-04-05 22:55, Jean-Philippe Ouellet wrote:
> On Wed, Apr 5, 2017 at 11:29 PM, cooloutac  wrote:
>> The sound mixer app I installed xfe in mutes things when I lower the volume 
>> all the way by accident.  Never realized till now lol.  I always have to go 
>> into dom0 alsamixer.
>>
>> Is there a better plugin to use?  Does a new iso come with one by default 
>> now?
> 
> This same exact bug keeps coming up again and again. See:
> - https://github.com/QubesOS/qubes-issues/issues/2550
> - https://github.com/QubesOS/qubes-issues/issues/2117
> - https://github.com/QubesOS/qubes-issues/issues/2291
> - https://github.com/QubesOS/qubes-issues/issues/2321
> - https://groups.google.com/forum/#!msg/qubes-users/53TYf5GYkqY/ZU8i5v6JAwAJ
> 
> This was fixed a while ago, but people don't get the fix because of
> the limitations of updating dom0 by only updating the packages
> installed there. When things get fixed in the installer, they don't
> trickle down to existing systems, and we don't publish new release
> ISOs except for on major releases. This means the default install is
> often broken, and many people end up needing to independently solve
> the same problems over and over. This is clearly not ideal, and IMO
> the way in which we manage dom0 needs some rethinking.
> 
> For this specific case I think we'd need a meta-package tracking which
> packages are installed by the installer, and have the installer just
> list that one and have deps of it be pulled in automatically. That
> would let us update *which* packages are installed by default and have
> that change affect existing installs. Then, as for actually putting
> the new mixer in the panel, we'd probably need a %post section in a
> relevant package or something.
> 

Thanks for bringing this problem and solution to everyone's attention,
JPO. I've created a tracking issue (which, I hope, properly captures
both the problem and the proposed solution):

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

> IMO updating needs a better solution overall. I tried to start a
> discussion about this here:
> - https://groups.google.com/forum/#!topic/qubes-users/dCctVsf15dE/discussion
> but it didn't go anywhere.
> 

IMHO, the reason that thread didn't go anywhere was because it did not
clearly identify a serious problem that needed to be solved or an
enhancement that ought to be implemented. I think your message above
does a much better job of doing both, and the older thread is clearer in
light of it.

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

iQIcBAEBCgAGBQJY6vy+AAoJENtN07w5UDAwwjwP/i2ZSxHafmddFvtfSesQ6CGs
/jN6BJYrBOmfvHL9zH5vx29IVsYPLt2mUC+r7OCZKOO2EyIsvTdq3FoBKXNM/pUO
LfArmni/iUPjEYcpliNacLJNOnoJvx2wRisLH4hPb7jEoLv0KfmPp+eYbkchyNVM
2HpIGw8Fzo/fCth0gt5sWIL7Yo/ld9QWLuAnRXaWhp0d5P9TACai/Qt0Cby+eN7A
V7GPBAT0cvP3gPtkE56Tf+F6ibi+zxPaS99WteHWSkXv8D39lncYH3269X+D1vLr
2KXNCgfxh0WNmd65xmwFHlj6ulGhpg6bqmoshLZxkATSprjUXloF7KZuYZarcWpP
OPE/gKnx+TQ1QuFbijMdw1Ph66sdKonc7MXc8pS6uJckE7iMNGJx37Lxv4ZmHk6z
PfAyCoerad9XidxNt15PJQOGTh1VGkarGRVV+uRAM+SIpctJzAOlj87N6aEiWpHd
Eeuv5ndJPFbmYPl8Ihua9/KGpl259I6x4uwDXxX8JxU28SzrrkpaW8MvlDX0mhqn
l94wJiO/cCHEbInrY4lz3ri9I0FGRrRf6Fr1iSzGIC8IBn7M/vdMQ9PvO0BAUwAu
nIm4zqlCSXL/21WPTP4PiB8kfVyTRFQqQ06rSSZaSDYeOA/138C2+lHhNGM7Lgfd
4h/9l5TtnEdsAmnrydQZ
=hiil
-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/57371712-fb11-f8b9-c53e-3738e9c12e5c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: USB installer did not use existing EFI system partition on NVME drives

2017-04-09 Thread jaymao1
On Saturday, April 8, 2017 at 11:22:09 PM UTC-7, jay...@gmail.com wrote:
> I am unsure if this is primarily an issue with Qubes or the Anaconda 
> installer.
> 
> Issue observed while installing in UEFI mode. BIOS was set to use AHCI 
> (otherwise, the "nvme disk" is not reported to the installer or the live usb 
> I used to look at the disk contents).
> 
> Manual partitioning does not appear to recognize an existing EFI partition on 
> an "nvme disk" (1) as an EFI partition (error message "No valid bootloader 
> target device found..." (2)).
> Installing anyway results in no Qubes boot option on reboot. (3)
> Running efibootmgr -v from a live usb reports a Qubes entry at VenHw (instead 
> of a HD).
> 
> The laptop I used also had a non-nvme disk, and accepting automatic 
> partitioning put a new esp on that disk instead. The install completed 
> successfully with automatic partitioning. I have observed no issues with the 
> installed Qubes system so far.
> 
> (1) the disk is reported as nvme0n1 during the manual parition process.
> (2) "No valid bootloader target device found. See below for details. For a 
> UEFI installation, you must include an EFI system partition on a 
> GPT-formatted disk, mounted at /boot/efi"
> (3) I am unsure if this is relevant, but the installation process does write 
> a "qubes" folder to the ESP partition on the nvme disk. On my first 
> installation attempt, the write was corrupted, and trying to read the files 
> through a live usb reported "fat_get_cluster: invalid cluster chain (i_pos 
> 0)". Later attempts did not result in such an error, though no attempt 
> resulted in a working Qubes boot option.

I attempted installing the same Qubes image again using an nvme partition for 
/boot/efi. Though the installed system did not work initially, I was able to 
create a working entry for /boot/efi/xen.efi with efibootmgr.

-- 
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/702f1bff-2045-4876-bada-e8cd970a16b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

2017-04-09 Thread 7690
On Sunday, April 9, 2017 at 2:55:01 PM UTC-4, cooloutac wrote:
> I gotta say the dvm template always gets messed up too.  So i also only 
> consider it untrusted tasks now.  but the vault vm is great imo.
> 
> Maybe you should post in user devel the people there are not as noob as me.

You type to much trash and you give nothing to the community. 

-- 
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/d9663d11-aea1-461b-98cc-c6d4199ad8ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-04-09 Thread Joonas Lehtonen
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.

-- 
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/69a68b76-9f83-771f-da84-9448790cd4a9%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


[qubes-users] i3 current state 2017 on Qubes 3.2

2017-04-09 Thread Eva Star

Hello,

I tried to install i3 windows manager from current Qubes repository (non 
testing) and i3-settings-qubes package (before i3 started first time).


And I have problems :
- i3 wizard manager start, although i3-settins-qubes packed already on 
the system (is it correct behavior?)

- Qubes VM-to-VM copy/paste key combinations does not work.
- Right mouse key on the firefox (and other applications does not work). 
:( And how to use firefox without right mouse key on i3?
- After some testing (clicking :) )  on next re-login i3 die: On the 
bottom of the screen it say that missing some dependence.



--
Regards

--
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/88913115-900d-66f1-b54b-2adf9c0cfebc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Why is there no built-in nvidia driver support? aka GTX 980 issues

2017-04-09 Thread ZK9
On Saturday, April 8, 2017 at 12:31:18 PM UTC-4, cooloutac wrote:
> On Friday, April 7, 2017 at 2:51:11 AM UTC-4, sl98077 wrote:
> > On Thursday, March 9, 2017 at 11:56:52 PM UTC-5, cooloutac wrote:
> > > Just to add you won't get any benefit from the Nvidia card.  Qubes only 
> > > uses it for desktop effects.  the vms don;t have 3d rendering.
> > 
> > 
> > It's not only about 3D rendering it has to do with users that want to also 
> > dual boot with a spare ssd, be a little mindful others have different 
> > obligations.. if Qubes wants to grow it needs to be readily available for 
> > all users.
> 
> 
> dual booting another os? That would defeat the purpose.  Qubes is for people 
> who want some exra security.  not a cool tech experiment.

You have this silly statement for everything, the person above this post has 
his methods and there are certainly others. 

-- 
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/7b6abc83-9b6f-4a89-b9d7-ed30c507819e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

2017-04-09 Thread cooloutac
I gotta say the dvm template always gets messed up too.  So i also only 
consider it untrusted tasks now.  but the vault vm is great imo.

Maybe you should post in user devel the people there are not as noob as 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/80fb44b6-c024-4a74-a1ec-a94eb7243329%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-04-09 Thread Jean-Philippe Ouellet
On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták

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.

Having the display device report its supported resolutions lets local
config managers display a list of resolutions to choose from, but the
VGA controller is free to just try to output whatever resolution it
wants. The driver does not inform the display device of what
resolution it is using via some out-of-band protocol, this information
is trivially inferred by the number of pixel clocks between the front
& back porches of the vsync & hsync signals. In 2017 you can't really
damage devices by providing invalid signals (or I would have most
definitely broken some things in the process of developing my own VGA
controller), in practice the device usually just reports "signal out
of range" or equivalent.

Back-reporting via i2c is nice and convenient, but by no means
required for things to work. You can just try best resolution you
want, and if it doesn't work then keep trying others until it works.

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


Re: [qubes-users] Re: Why is there no built-in nvidia driver support? aka GTX 980 issues

2017-04-09 Thread Daniel Acevedo
On Sat, 8 Apr 2017 09:31:18 -0700 (PDT)
cooloutac  wrote:

> On Friday, April 7, 2017 at 2:51:11 AM UTC-4, sl98077 wrote:
> > On Thursday, March 9, 2017 at 11:56:52 PM UTC-5, cooloutac wrote:  
> > > Just to add you won't get any benefit from the Nvidia card.
> > > Qubes only uses it for desktop effects.  the vms don;t have 3d
> > > rendering.  
> > 
> > 
> > It's not only about 3D rendering it has to do with users that want
> > to also dual boot with a spare ssd, be a little mindful others have
> > different obligations.. if Qubes wants to grow it needs to be
> > readily available for all users.  
> 
> 
> dual booting another os? That would defeat the purpose.  Qubes is for
> people who want some exra security.  not a cool tech experiment.   
> 

Using a Sata Switch that plugs in a PCI slot, one can turn on/off
different drives, allowing dual booting without diminishing the
security.

I ordered this one (still waiting for it):
http://thumbs.ebaystatic.com/images/g/ZBgAAOSwvg9XbqSI/s-l225.jpg


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


[qubes-users] Re: off topic - invite codes to 'riseup'

2017-04-09 Thread vipulgreattt
I too need two invite codes. Thanks in advance. :)

On Tuesday, October 28, 2014 at 11:56:49 PM UTC+5:30, 
bm-2cu9wcijafoqtf6...@bitmessage.ch wrote:
> Dear qubes-users,
> 
> I am long time qubes follower and user. I apologize in advance if anyone 
> feels this request is spam.
> 
> I am looking for two invite codes needed to sign up to anonymous 
> riseup.net email service.
> 
> I am hoping there are some qubes users who are riseup.net account 
> holders.
> 
> Can anyone please send me a couple of invite codes that I might be able 
> to sign up?
> 
> Thank you in advance.

-- 
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/a4a6eda4-3e75-4113-961b-96c77fee5682%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: coldkernel status update

2017-04-09 Thread Patrick Schleizer
Reg Tiangha:
> Thanks for all the hard work! WillyPillow just pointed out to me today
> on the qubes-devel mail list that installing busybox and updating
> initramfs in Whonix is all you need to do to get it to boot with
> coldkernel,

busybox will be installed on Whonix 14 by default.

https://github.com/Whonix/anon-meta-packages/commit/92c70963ed34953a81f8e53273453926b738ea18

On the other hand, what about adding busybox as a dependency to the
coldkernel Debian package?

Cheers,
Patrick

-- 
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/587f68f5-a342-b55a-6b39-4d5cd555c255%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


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

2017-04-09 Thread Vít Šesták
Well, there seems to be a cheaper way to do roughly the same. In a nutshell, 
you just ensure there is no wire for those two things:

* HEAC+ (audio return channel plus ethernet). HEAC+ is optional and thus safe 
to remove.
* CEC (remote control input) – This one is a bit more tricky. While CEC is also 
optional, its wiring is reportedly (via Wikipedia) mandatory. I haven't found 
this in specification. Maybe CEC wire is mandatory for cables (as this is in 
1.0 specification), but can be completely ignored in both parties. 
Theoretically, the worst what can (but hopefully won't) happen is downgrade to 
single-link digital DVI, effectively restricting the resolution to  1920 × 1200 
@ 60 Hz, see below. OTOH, if you don't want to cut CEC, my brief look suggests 
just minimal attack surface.

Removing them will keep only two inputs you can hardly get rid of:

* 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.
* HotPlug/HEAC- (PIN 19) – I believe it will work just as hotplug detection if 
HEAC+ is missing. So, virtually no attack surface.

How to practically cut the wire(s)? You don't have to actually cut the cable 
etc. There are few easy options:

a. Use HDMI-to-DVI and then DVI-to-HDMI, both should be passive converters. 
According to pinout at http://pinouts.ru/visual/gen/hdmi_dvi_cable.jpg , it 
seems to cut just the two input wires, i.e., it would do exactly what we want. 
While this looks like converting to single-link DVI and back, passive 
converters will probably allow full HDMI without the features we want to get 
rid of.
b. Use an older cable without HEAC+ wire. According to the specification, they 
should exist, but I am not sure if you can find a new one. Useful for home TV, 
since it is you who buys the cable. However, such cable will probably still 
have CEC. On the other hand, brief look at CEC does not suggest a large attack 
surface there.
c. Use cable without CEC wire. It is probably nonstandard, but it seems to 
actually exist: https://www.pulse-eight.com/p/110/cec-less-hdmi-cable. It is 
not sure if the cable includes HEAC+ wire ir not.

I suggest verifying the wiring by ohmmeter.

“Cutting” wires might be also better from security perspective than proxy, but 
it depends. When the proxy is implemented carefully, it might even absorb 
attack surface of DDC. It also could protect the device (e.g., Smart TV) from 
attacks from compromised laptop, but this is probably slightly off this topic.

## Should Qubes handle this?

I believe that Qubes should care about it partialy, but the developers cannot 
do all for you.

First, QubesOS should ignore HDMI ethernet and maybe some other inputs (CEC and 
ARC) from HDMI. Maybe it already ignores all network devices connected to dom0, 
but I haven't seen anything that confirms this. Failure to ignore HDMI network 
in dom0 could make QubesOS more vulnerable to attacks over HDMI than 
conventional distros are, especially when dom0 is based on EOLed Fedora version.

On the other hand, QubesOS probably cannot resolve this exposure in full 
extent. Imagine an input being processed by GPU firmware and then with GPU 
driver and then rejected by QubesOS. You see, the rejection by QubesOS does not 
necessarily prevent processing of the input by some parsers running with 
absolute privileges, either dom0 or DMA-enabled device handled by dom0. QubesOS 
will hardly fix them and I consider it to be outside of QubesOS 
responsibilities.

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/f445bbc5-cd0f-4dab-ad51-2032c2d55736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Windows 7 installation stops

2017-04-09 Thread 'Philipp Raschdorff' via qubes-users
Hello,

What version of Qubes and which Windows 7 version (home/pro/32bit/64bit)
are you using?

I've successfully installed Windows 7 on Qubes 3.1 and 3.2
Make sure to add at least 2GB RAM to the windows VM.
Following the excellent Qubes Documentation I found out that if you create
a Windows HVM from the command line it has only 512 MB RAM which caused
problems after (!) installation.
Be also sure to use the 32bit-Version of Windows.

I have used Windows 7 Pro 32bit and installation was smooth & easy.

If you need further help, do not hesitate to contact me.

Regards

- P.

Am 09.04.2017 4:45 vorm. schrieb "'01v3g4n10' via qubes-users" <
qubes-users@googlegroups.com>:

On Tuesday, April 4, 2017 at 6:10:44 AM UTC-5, pete...@hushmail.com wrote:
> Hi
> I can't install HVM with Windows 7 because the installation stops on the
screen "Starting Windows". Before this I had installed and removed it many
times. What can be succeeded? I have no problems with win8 or linux OS.
>
> Best

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

--
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/8aefeec8-b4be-4328-9913-792a2238d45e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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


Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

2017-04-09 Thread Shane Optima
>usability is not a good reason to add or change anything. 

I suggest you switch to running Lynx on OpenBSD then. I guarantee you're 
running all kinds of horribly insecure stuff on whatever you're using to read 
this right now.  

Usability has always been a top priority in Qubes and that is a major part of 
why it is such an excellent operating system.  Why on Earth do you think they 
bothered making a GUI tool?  Why don't they require a password for sudo? 

(Newcomers: that last one was a rhetorical question that I've already analyzed 
at length; please see older messages om this thread.)

>Yes i'm a noob,  but you still sound like a security nightmare to me.

Security isn't a gut feeling thing. At least, not in the way you're doing it. 
Your gut needs to know what it's talking about first.

> You lost me way earlier when you mentioned browser extensions

Exactly my point. You don't understand at all what the purpose of the browser 
extension is.  All it does is generate a token that Dom0 uses to look up 
something in its index. If you can't follow me trying to explain what the 
extension does (it generates a token of about 3 characters according to a 
specific set of rules, and appends them to the page title. That's it!), let me 
try instead to explain what it DOESN'T do:

A. The extension would have no way of knowing if the Dom0 code was actually 
doing anything with a particular token. It wouldn't know if the Dom0 code was 
running. It wouldn't know whether or not the Dom0 tool was even installed.

B. As per the above, it would receive no feedback or input from Dom0. 

C. It wouldn't be involved at all in handling the username / password (although 
I guess someone could write another extension to automate that as well.  But 
this probably wouldn't be high on my list of priorities.)  

D. At no point would the extension cause any data whatsoever to be written to 
any files in Dom0 except perhaps in the form of a logfile (which the extension 
itself isn't aware of or capable of accessing.)

E. At no point is the extension concerned with the keypress that activates the 
tool. It doesn't know or care when or how any of that stuff happens. It keeps 
providing index tokens all day long even if the password key combo is never 
pressed.

F. It would be entirely optional. The password tool could function just fine 
without it, but would be vulnerable to a title spoofing attack (not as dire a 
threat as M. Ouellet thinks, but it's there) and it would require a bit more 
effort to set up your password list on Dom0 and keeping it running smoothly.

G. The extension should be thought of as an *extra layer of armor*, not an 
extra point of failure in this setup. If someone exploits a bug that causes the 
extension to crash or behave erratically, the tool on Dom0 immediately stops 
providing passwords.  It *can't* provide any passwords if it's been set up to 
use the tokens but they aren't being provided.

H. Building on G, if someone manages to compromise your entire web browser such 
that they can either disable the extension (or control it) AND they can read 
your randomly generated salt... then yes, they could intercept your passwords 
on that VM. 

And this is what they could do in any other situation involving a catastrophic 
browser takeover.  But you're better off in this situation vs. using the 
browser's built-in password manager, even an encrypted one. Vs. manually copy 
and pasting passwords from an offline VM, and it's roughly the same situation. 

I. Mistakes and misconfiguration should just result in nothing at all 
happening. Pressing the activation key for the tool while you're on the wrong 
site results in nothing happening except perhaps an error popup (that is 
handled by the Dom0 tool, not the extension.) 

> If my Mother can handle ctrl shift c, I'm sure you can too.  

This is akin to telling Joanna that your mother can handle running 5 different 
VMs in Virtualbox, so she can too--crazy window mixing from different VMs? OMG! 
That's a security nightmare!

You've no idea what you're talking about, and Ouellet refuses to consider the 
version with an extension because he knows there is no plausible security hole. 
He doesn't like it because it's messy, and I agree, but open source software 
has rarely been driven forward by anything but people giving in and hacking 
together something kinda messy.  Messy doesn't mean full of security holes, it 
just means... messy.

And if you're telling me you use manual copy/pasting for everything, and you 
don't use persistent cookies, and you use a DispVM[1] for everything that 
requires a login, and you don't use a password manager, AND you have strong 
randomized passwords for everything, AND you have more than a couple dozen 
accounts, AND that you use your computer heavily, with a decent amount of 
DispVM restarts throughout the day...

Well, I don't believe you.  Nobody who tried use to do it all manually, with 
heavy usage over a prolonged period 

[qubes-users] USB installer did not use existing EFI system partition on NVME drives

2017-04-09 Thread jaymao1
I am unsure if this is primarily an issue with Qubes or the Anaconda installer.

Issue observed while installing in UEFI mode. BIOS was set to use AHCI 
(otherwise, the "nvme disk" is not reported to the installer or the live usb I 
used to look at the disk contents).

Manual partitioning does not appear to recognize an existing EFI partition on 
an "nvme disk" (1) as an EFI partition (error message "No valid bootloader 
target device found..." (2)).
Installing anyway results in no Qubes boot option on reboot. (3)
Running efibootmgr -v from a live usb reports a Qubes entry at VenHw (instead 
of a HD).

The laptop I used also had a non-nvme disk, and accepting automatic 
partitioning put a new esp on that disk instead. The install completed 
successfully with automatic partitioning. I have observed no issues with the 
installed Qubes system so far.

(1) the disk is reported as nvme0n1 during the manual parition process.
(2) "No valid bootloader target device found. See below for details. For a UEFI 
installation, you must include an EFI system partition on a GPT-formatted disk, 
mounted at /boot/efi"
(3) I am unsure if this is relevant, but the installation process does write a 
"qubes" folder to the ESP partition on the nvme disk. On my first installation 
attempt, the write was corrupted, and trying to read the files through a live 
usb reported "fat_get_cluster: invalid cluster chain (i_pos 0)". Later attempts 
did not result in such an error, though no attempt resulted in a working Qubes 
boot option.

-- 
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/2101ef84-7a2a-4b4b-8cbd-75ed282e855b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.