Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?

[Chris Laprise]

On 12/03/2017 12:09 AM, Michael Siepmann wrote:

On 11/30/2017 10:14 PM, Chris Laprise wrote:

On 11/30/2017 11:44 PM, Michael Siepmann wrote:


On Jun 12, 2017, Andrew Morgan wrote:

Did you follow the "Set up a ProxyVM as a VPN gateway using 
iptables and

CLI scripts" section of the Qubes VPN docs
(https://www.qubes-os.org/doc/vpn/ 
 )?


If so you should be good just to execute the `/rw/config/rc.local` 
file

on your VPN VM after every suspend either manually, through a keyboard
shortcut (which I do personally with the following command):

qvm-run -i root sys-vpn "/rw/config/rc.local"


I followed the "Set up a ProxyVM as a VPN gateway using iptables and 
CLI scripts" instructions but for me executing "/rw/config/rc.local" 
doesn't make it work again.


I've also tried commenting out or deleting "persist tun" from my 
OpenVPN config file, as Chris Laprise as suggested in the thread "is 
vpn made manually, not supposed to restart after suspend?" on May 21 
but that isn't helping either.


My current workaround is a script I wrote in dom0 that first does 
"qvm-prefs VMname -s netvm none" for all the VMs I normally have 
running that use sys-vpn (my ProxyVM VPN gateway), then shuts 
sys-vpn down, waits 10 seconds, starts sys-vpn, then does "qvm-prefs 
VMname -s netvm sys-vpn" for all those VMs.


Any ideas what could be going on so that neither executing 
/rw/config/rc.local nor commenting out "persist tun" works in my case?




I have a couple ideas as to workarounds. Instead of re-starting 
sys-vpn, you could:


  qvm-run -u root sys-vpn 'pkill openvpn'
  qvm-run -u root sys-vpn 'sh /rw/config/rc.local'

...before you re-enable the netvm prefs.

Also, one thing that changing the netvm prefs does is to trigger 
qubes-firewall-user-script to run again. You might compare the state 
of iptables before and after your workaround to see if something went 
missing after waking from sleep. If that's the case, you could just 
trigger the script as a third command added to the above.




Thanks! I tried those commands and they don't get it working again. I 
still have to shut it down and restart it. I also checked the iptables 
and that does not seem not to be the problem. However, I've found out 
that after a brief suspend the VPN may continue working, but in cases 
when it stops working, the process ends and can't be restarted. In the 
following the first ps command was just after resuming, and the second 
a few seconds later, after I'd seen the "VPN is down" notification:


[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
5 S root  1093 1  0  80   0 - 16371 poll_s 14:33 ?00:00:42 
openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon
[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
[user@sys-vpn ~]$
[user@sys-vpn ~]$ sudo sh /rw/config/rc.local
[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
[user@sys-vpn ~]$

I also tried "pkill openvpn" when it is working, and I can't restart 
it after that either:


[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
5 S root  1134 1  0  80   0 - 16371 poll_s 21:26 ?    00:00:00 
openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon
[user@sys-vpn ~]$ sudo sg qvpn -c "pkill openvpn"
[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
[user@sys-vpn ~]$ sudo sh /rw/config/rc.local
[user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
[user@sys-vpn ~]$

Any ideas why this might be happening?


Looking at openvpn entries in 'journalctl' can give you a better idea.

I've seen instances where openvpn versions starting with 2.4 have this 
bad reaction to disconnection (which is what sleep/wake is in this 
case); with openvpn 2.3 you could count on it to keep 
going/re-connecting. But there may also be an issue with the way 
Qubes/Xen are handling the virtual interfaces between VMs; the symptoms 
remind me of basic networking problems many of us have experienced with 
prior Qubes releases, where only VM restarts would re-build inter-VM 
links correctly.


But if there isn't a basic networking problem, moving to a service-based 
config will be more robust and should keep openvpn running. One way to 
do this is to have your rc.local script start openvpn with systemd-run 
(and the right options), but I've already created a project that uses a 
full systemd config to manage VPN processes...


https://github.com/tasket/Qubes-vpn-support

Setup is much easier than the vpn doc, though it currently only works 
with Qubes 3.2 which I'm guessing you're using. The usual 'systemctl 
start/stop/status' commands give you control over the 
qubes-vpn-handler.service that manages openvpn.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  

[qubes-users] Re: Can’t Upgrade to Fedora 25

[Foppe de Haan]

On Sunday, December 3, 2017 at 6:10:37 AM UTC+1, Person wrote:
> When I try to update a Fedora 23 VM in Qubes 3.2, I get this error message:
> 
> https://imgur.com/a/nuKDG

try adding a few gb to the root volume.

-- 
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/74824f67-404b-4e5a-af4b-ed87d3d77346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: VPN Setup on qubes 4 RC3

[eminem]

Yeah that worked, 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/7dbecd0c-b70c-49b0-bf94-d424aa80cdb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: USB Keyboard thoughts...

[taii...@gmx.com]

I would consider purchasing one of unicomps excellent mechanical 
keyboards, they don't have re-writable firmware so a malicious computer 
can't install a virus (unlike most keyboards) and they are also made in 
america thus much more trustworthy.


Truly a pleasure to type on, they are made with the original IBM Model M 
tooling.


--
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/a8c34cb4-2bba-020c-a581-233884374f91%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How To Replace Libvirt Drivers

[Person]

Is this a common problem?

-- 
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/d5af2039-d133-4f68-9746-d696621edc09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Suggestions (for forum posts)

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-12-02 09:13, Stumpy wrote:
> 
> 
> On 02.12.2017 01:36, Andrew David Wong wrote: On 2017-12-01 13:24,
> Stumpy wrote:
 
 
 On 01.12.2017 10:05, Tom Zander wrote:
> On Friday, 1 December 2017 00:37:47 CET Stumpy wrote:
>> I am not so familiar with google groups but I don't have
>> a google account
> 
> For those of us in that section of the population; you can
> subscribe to the group without having a google account and
> get 100% of the emails in your email application of
> choice.
> 
> The details are here; 
> https://www.qubes-os.org/mailing-lists/
> 
> Quoting from it;
> 
>> Google Groups
>> 
>> You don’t have to subscribe in order to post to this
>> list. However, subscribing might nonetheless be
>> desirable, as it ensures that your messages will not be
>> eaten by the Google Groups spam filter and allows you to
>> receive messages which were sent directly to the list.> 
>> To subscribe to the list, send a blank email to 
>> qubes-users+subscr...@googlegroups.com.> Note: A Gmail
>> account is not required. Any email address will work.
 
 Thanks for the response. Perhaps I am a bit confused but I
 have subscribed to the mailing list but some of the responses
 only seem to be in google groups, not my inbox, so in order
 to reply I would have to get a google account no?
 
> 
> No, a Google Account is not required. Many people who use the
> Qubes mailing lists never create one. If you're subscribed to one
> of the lists, you should be receiving every message sent to that
> list. (Of course, you won't retroactively receive emails that were
> sent to the list before you subscribed.)
> 
>> Really? I must be doing something wrong. I had origonally sent a
>> message to qubes-users+subscr...@googlegroups.com and got a
>> confirmation message but I dont get any messages except some of
>> the responses to my posts that I sent to
>> qubes-users@googlegroups.com I will read the mailing list page
>> again because I think I have missed an important detail

I just tried to search for your email address in the list of
qubes-users subscribers, and it's not there. So, it looks like your
address was never successfully subscribed, or it was unsubscribed at
some point. I recommend that you try to subscribe again.

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

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJaI2kgAAoJENtN07w5UDAwkuEQAM0vWT/88+c7rsHTA1F5aobN
EQ4uDv9RFSxEmp7bYxKCJhx4bcyKxNH54pM9H3tH/lUrUxms+OmGO7WSxslfdghz
egly/u0L43sr5J+l7xMc1dxzTR2e8Md8EGpxiT0+zZylenzQRQT2w4fU5UMD3Sky
43BJ7ct6MIRC8amayYGqrDAP+eejTa0kRMCl8TmeCcx8A3YcjeRMMm7u/e0bDn5n
ZkthRdqTW8+xnU8aWkbxtCJwn4iN47sVhJedzu2cd9r51DiYsX0BTL0A8yZdMXs+
2pDAaBm7e5NG4M2BZOC8YcEQ9844BzQOqN9M+DalkzdRtRLFg1kfUWIrqS/feOIx
TJm4JePZbdfRYOah1sYEf6OjAVHXmA7h7owt5G30itvLzRGXVvJiAyMi3HlMVUiW
3NftuyCDFkrc/L1Lj2rKLVDDDYHf4i99RMiaeJeCXBcWv4kmYxBGtteGbXtX6RkW
ywN03dWg96XpOjV+ewnUZe4W/0CXSYWnD6fHX6LZMbueITORudUJfyVbuSsdLXjP
s8pTtRmO1RdnNiVGMqCHhBLEBiPQME5xAPWcRVk0xbItdn29YelYZ3rdg8qIvzIf
6kSnjlV6ZCfRzl1bi43tkHfYGLEc8MAWLVjUae06Jjjfh5JZCdDCzymCkeRFVMPU
zEstVGvQsynLzgi23/N2
=liCS
-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/aa3ec4e5-e6b6-8aaa-a6dc-3d8f9f519fc5%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Dec 02, 2017 at 01:02:52AM -0800, Joe Hemmerlein wrote:
> Danke, Stephan, your pointers were very valuable!
> 
> At first, I decided to just borrow an external DVD drive and boot off a DVD 
> burned from the ISO, in UEFI mode. The result however was the same as when 
> booting from my previously-created USB stick: grub boots, but no matter what 
> i select, the screen briefly flashes and takes me back to grub. So.. yeah, 
> the ISO image does not appear to be usable out of the box on some UEFI 
> devices, even when burning it to a DVD.
> 
> Your description of the livecd-tools helped make good progress, but still 
> without ability to boot the installer completely, but they sent me in the 
> right direction. I then found 
> https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk, which 
> described a process very similar to yours (it omits the part about using 
> dosfslabel, but has a part about also updating the xen.cfg file).
> 
> Altogether, this did the trick!

Thanks for posting detailed instruction. And for the pull request for
qubes-doc!

> In condensed form, this is what i did to create a USB install stick that 
> works with UEFI on the T470:
> 1. Use the "livecd-iso-to-disk" utility from fedora livecd-tools to put the 
> ISO image onto an USB stick
> 2. rename the USB stick's partition label to BOOT
> 3. edit the /BOOT/EFI/xen.cfg file on the USB stick's partition to make sure 
> all LABEL= instances are replaced with LABEL=BOOT

Does anyone have an idea what the difference livecd-iso-to-disk make,
compared to isohybrid? If possible, we'd like to installation iso work
out of the box on UEFI systems, including new ones...

I wonder if Fedora netinst iso (_not_ Live iso) boot on such new
hardware, after directly dd-ing it to USB stick. Can you check that?
Just see if installer starts. It's here:

https://alt.fedoraproject.org/

If that would work, I can try to find what is different about those
images and fix Qubes iso.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJaHurZAAoJENuP0xzK19csN8AH/2bR8wcOcHt6BBYfsk0H6Nsv
rtZ5Pwy41RCkXqwUO5gCbxdjkisqnKGqR+QWSEgJpETk7OOQmu7IMVzWBDfZQtVA
PG6GdbX2qiohgCjzXDlGYSXkwp/hYoOu0O1YJsh/EwIRZJcYPO9MsavggFRw4fP8
HL/GsNK4Hc+zWDgjuV3NZBeT0VKIH0/frp98QIKU6JQfo79q9+1PIX4ZOTX4Y9jB
WUOaj4tbrU6vOeeCQ2EcwRVA6LxjIztvYgmI/csqeJoXV/Va/YS0lhWZFH6tswT/
C+3bj4vbuqThu56yRq/+mGM6K6Nd2DoEMX+SdZ/eWrgSHxu3Cz/awNW3ZiHiuVg=
=Fo88
-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/20171203020359.GG1935%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows 10 on Qubes (freeRDP)

[pixel fairy]

How well does it work just installing in a standalone hvm? can you pass usb 
devices? if not the qubes filtered "filesystem only" etc flavor, then raw usb 
pass through?

-- 
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/a4677f24-514f-4f35-b065-4c5070e7d480%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: guid.conf for disposable VMs

[pixel fairy]

On Saturday, December 2, 2017 at 9:26:36 AM UTC-8, tech...@tutanota.com wrote:
> Hi,
> 
> I understand generally how to customize guid options via the 
> /etc/qubes/guid.conf file in Dom0 as per 
> https://www.qubes-os.org/doc/full-screen-mode
> 
> My question is, if I want this to effect disposable vms only, not globally, 
> what do use for the VM name in the VM: {} block in the file?
> 
> Thanks.

You should be able to get full screen regardless with ALT+F11

-- 
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/5a303512-1aa9-4555-9faa-12280ab5db08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 4.0 RC3 IO Remapping differences - qubes-hcl and xl dmesg on Asus Sabertooth Rev 2.0 bios 2901

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Nov 29, 2017 at 08:14:52AM -0800, Sergio Matta wrote:
> I am already using RC3 and everything is working fine, but:
> 
> qubes-hcl-report says
> HVM:   Active
> I/O MMU:   Active
> HAP/SLAT   Yes
> Remapping: no
> 
> xl dmesg says
> (XEN) AMD-Vi: IOMMU 0 Enabled.
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0: mode: Relaxed
> (XEN) Interrupt remapping enabled
> 
> Is there a error in qubes-hcl-report?

Yes, similar to this one:
https://github.com/QubesOS/qubes-issues/issues/3208#issuecomment-339565279

Thanks for the report!

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJaHuLYAAoJENuP0xzK19csRrwH/jN2bbqFXUm+PI5KXlQONbDu
M95a2pAZagQXcCe/jukRZfJ8sml08IJP38vZNUL0DNhyROj8jmF/D6F3gRK6SD/F
T9lnkgftZVk+Yc9Eb6X4WX6SGWTYDqadMi4mwSNTmYo8DX4XP2PuuFCVMBmq8bon
VGaeW6PtbdUR4iam71TEkl3iHD9CDrlMb8hScQTj5ZS7tSTvtdaW6x6OEhnVZAxK
9vzNNH4DaGt9qLmZgdR8EbAbX9PhYw8jHzqgz1wXqgE3kS2Qou4Q5OElnV7/vSoc
R/EcwBHPpukKfzVRyollkG/3pzQiOln3BDUMD3hN5N7SLfXuM28EKksvw3X8yQg=
=hrME
-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/20171203012950.GE1935%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes in a corporate network behind HTTP proxy

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Dec 01, 2017 at 02:46:55AM -0800, pr0xy wrote:
> On 2017-12-01 10:30, awokd wrote:
> > On Thu, November 30, 2017 22:36, pr0xy wrote:
> > 
> >> Specifically I need to pass HTTP, HTTPS and FTP through
> >> the corporate proxies. I modified your example to this:
> >>
> >> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 80:443 -j DNAT --to
> >> proxy.example.com:8080
> >> iptables -t nat -I PREROUTING -i vif+ -p tcp --dport 21 -j DNAT --to
> >> proxy.example.com:10021
> >>
> >> I placed that in the /rw/config/rc.local of sys-net and made it
> >> executable. Rebooting the machine shows that it's persistent, and they
> >> show up in the PREROUTING section when I check
> >> iptables --table nat --list
> >>
> >> Problem is that AppVMs connected to the sys-firewall > sys-net don't
> >> seem to take advantage of those settings. For example, I can't use
> >> Firefox to connect to internet sites without manually setting the proxy
> >> in the browser. Likewise, TemplateVMs with the same routing can't
> >> update.
> > 
> > Might depend on how that corporate proxy is configured. For example, if it
> > requires authentication. How friendly/linux savvy are the people who admin
> > it?
> 
> I'm the first person to run anything non-Windows in this network, so
> this is new territory. It's a Squid 3.3.8 proxy for HTTP and HTTPS. The
> FTP proxy is something else. There are no usernames or passwords
> required for the proxy.
> 
> They gave me all the settings and told me to work it out if I want to
> use Qubes, so that's what I'm trying to do...
> 
> >> Should I instead be making these iptables settings in a ProxyVM, and
> >> connect like: AppVM/StandaloneVM/TemplateVM > ProxyVM > sys-firewall >
> >> sys-net?
> > 
> > This would be my approach for flexibility but either should work.
> 
> All the documentation I'm seeing makes me think it should work as well. 
> 
> I'm not looking into the option of setting environment variables on each
> template to see if that might work. So far the only other option that
> has worked is to manually set the proxy in each piece of software, in
> each AppVM.

Above iptables example will not work in most cases - HTTP direct
connection and HTTP proxy connection have some differences. Client
application must be aware that http proxy is being used.

There are two options:
1. Setup ProxyVM with some application that will intercept all the
connections and wrap them into HTTP proxy connection. Tor can do that,
but as a side effect you'll get all your traffic through tor. You can
also setup some HTTP proxy in transparent mode (at least squid supports
that).

2. Configure each application, in each VM to use HTTP proxy.
This may sound laborious, but in fact it is not: you can
set http_proxy and https_proxy variables in your template(s) and all VMs
based on it automatically will pick it up. Just create
/etc/profile.d/proxy.sh and export appropriate variables from there.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJaHt2yAAoJENuP0xzK19csogEH/3MLAWIm1C6vqpX/iugoxLl6
4tk0x4KXKWsNNfR50ir/8INgLWWXrCxk9QbZXy010nC3Dp0TNso3ei6ae+fc25as
2aj36TOyDA8ztV5F0libiZFxDCWcfzskvW7GiC57JlOustCq2CTTkaz3p5eHyjp8
ITnnOKpA/Ji7MTloxPNedw8hzpyMxJQudqryd7DDribbTHozG/xtBTRR/ZhPaIjI
Z849e8uRj47xrPWyVyOtuP6KGy5Q79CYCk1qM3bCd9EKipYNwqUZGZsPkI3SAfhv
xiM5YfP7Frc/62H64Z0KiieP9M5XIys64OWzK+trfSCCOzYafJDtJvti4q02s0o=
=vfFi
-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/20171203010752.GD1935%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-11-29 15:03, genevieve.c.gauth...@gmail.com wrote:
> On Wed, 2017-11-29 at 15:59 +, Unman wrote:
>> In the Fedora documentation there ARE methods described for 
>> getting bug reports out of the install process, but they require 
>> active intervention from the user (copy to another drive or scp 
>> across network). There's no suggestion that these reports would 
>> be automatically submitted.
>> 
>> I've had a quick look through the code and i dont see any 
>> mechanism for passing on bug reports - but it was a very quick 
>> look.
> 
> Interesting & very good to know this but that would have surprise 
> me a lot from a Qubes OS installation. Have you learned if it is 
> specific to Qubes 4.0 rc3 (perhaps the installation part has been 
> there for a long time before this release) ?
> 
> 3-4 questions remains for me.  If you can learn those answer in the
> future, I believe this issue would have been truly investigated for
> me.
> 
> With an "active" intervention from the user (or if I had connected 
> to the internet and submitted my report from my computer to the 
> computer receiving those reports)
> 
> 1.1 : Does my passphrase would have been transmitted ?  YES/NO ? 
> 1.2 encrypted along the way ? YES/NO ? 2.1 : If YES 1.1, where/who 
> does the passphrase would have been transmitted/ transmitted to
> 2.2 : Who would have had access to this information ?
> 
> 
> I am not looking for an immediate answer. However, I am still 
> curious about all this.  Such a strange 'Bug Report' to see it
> like this.. Seems complicated to use those information to comprise
> the whole system via dom0 (that's good)
> 

Hi all,

After checking with the Qubes Security Team, I'm happy to report that
there is no cause for alarm here:

1. For security, networking is always disabled in the Qubes OS
   installer, so you would not be able to send that bug report (or
   anything else, for that matter), even if you wanted to. Disabling
   networking during installation is necessary for Qubes to protect
   itself before it creates a NetVM (and hence before the network
   stack has been isolated).

2. We agree that sensitive user data, especially passwords, should never
   be included in bug reports. The last thing we want is for any third
   party (least of all us) to see a Qubes user's private data. In fact,
   you can think of the entire Qubes OS Project as working to ensure the
   exact opposite. :)

3. Qubes OS uses an installer called Anaconda [1], which generated the
   bug report you saw. After it performs an installation, Anaconda saves
   the data from that installation in /root/anaconda-ks.cfg. We have
   verified that the LUKS (disk encryption) password is not stored in
   this file. Only a hash of the user account / screen locker password
   is stored there (not the password itself, and not even a hash of the
   LUKS password is stored there). We have also filed an upstream bug
   report with Fedora about Anaconda including the LUKS password in the
   bug report. [2]

[1] https://en.wikipedia.org/wiki/Anaconda_(installer)
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1519895

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

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJaI0jZAAoJENtN07w5UDAwYMsQAKkgoqP4VzitWKissQr9ls2c
kYpXuOCD9WWj9toAg2weK82W8YvCqMBhuuZfO7UUR1qyYE1d3F8g79dvKBDj1tGD
JiNXoaJSPpsjyOpGEMcZAF+5dLtDfZqrfdY6LewpRQ18aIsRy/j3fLOVsnWNTATv
2g1RVRij1Z4nZn4kjr5oP99k+u9z/IBMR9QFo6L4D8+Mxb3mGXOCQqOxVkXuDojP
5vw7b5ICEPbmQRVbylmbuXA2RpQ/I6LPsNR7vELtMoQGyEHN7JHnHlU4sM0tkh8V
qiqG5u6g1cqoZs+SvspFz9xd1idrtx8zFvlZFtAXWDsM7M5pfJCbtTPnKRlk4iEQ
dGabpRYco/+E9fos7k+ypsP3iqh/sLB8mHxkMPcdDdmJTLZYqj7pRUqOX3e+AiRs
QAZ8oOKFMEhmVmKbNWoArE9WNiT7w1zjzywUPuxWN/4nOVcm0TTqnOGGNHP2Ys8C
wqOZ7bOnA089mPR8WNYN8JSHiAqd2JpLJQlmSjUUp4kQWfczaCiRh7CodgInihL9
+R++lcCNAQ2c+T9LeUwwa0ibXYiOHWVewMP9tg1K7fVa7nDZXzn3O7LSyw31FcXF
2eoFusB7Ot+GKeDWTPMlRELy2iEaa46oQc1veE3FoU6s9biYw7wrIKRpwEO5Gpu7
wTfnq1qL23hv5QbnlE/E
=I7ZH
-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/26fe33d1-3233-c946-cb2d-6e6af9887163%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB Keyboard thoughts...

[Jean-Philippe Ouellet]

On Fri, Dec 1, 2017 at 1:10 PM, Matty South  wrote:
> I love the Qubes project! I've been thinking of ways to improve the security 
> when it comes to USB Keyboards.
>
> I'm sure a lot of us who use Qubes as our day-to-day OS have a nice keyboard 
> attached to the system. Upon plugging in the USB keyboard for the first time, 
> I rightfully got a security warning about the implications of passing USB 
> Keyboard input into dom0 (think USB Rubber Ducky attack among others). OK, 
> I'm on board so far. What surprises me is that I didn't just authorize THIS 
> keyboard to pass through to dom0, I have authorized *ANY* USB keyboard to 
> access dom0. I verified this with other keyboards and even a home-made Rubber 
> Ducky attack using a teensy.
>
> Curious, is there a reason why we don't restrict the authorized USB keyboard 
> based on USB Serial number or even VID or PID. Sure with PID/VID, a physical 
> attacker who knows your brand of keyboard could still pass through 
> keystrokes, but it would still up the bar a little for these style of attacks.
>
> I'm on Version 3.2 so forgive me if this has been addressed in 4.0.
>
> Secondly, I don't want to be the guy begging for improvements, I would like 
> to contribute. Can anyone point me to a good place to start if I want to add 
> this feature? I'm thinking here maybe? 
> https://github.com/QubesOS/qubes-app-linux-usb-proxy

See https://github.com/QubesOS/qubes-issues/issues/2518

-- 
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_At%2BPXpw0y%3DQgCKZQqYKjSJRCRqbNjD3VtdW%3D9H%2B1kvqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Drobo seen in dom0 but not appvms? (block dev is attached)

[Stumpy]

Hi, I have an old (2nd gen) drobo and was able to connect to it using 
nautilus on my debian appvms, I would attach the drobo/block dev via the 
qbes vm manager (am still on 3.2) and then it would show up under other 
locations. Well my DebVM is not behaving for some reason, audio not 
working AND nautilus is giving me errors when I try to start it. I 
haven't though much about it as I plan to redo everything once 4.0 goes 
stable. The caveat is that I can't seem to access my Drobo via fedora 
(nautilus/thunar) or via debian (thunar as nautilus doesn't work).
I can access it just fine via thunar on dom0 but I don't want to start 
messing with those files on dom0 (Im assuming that would be bad opsec), 
and anyway all my apps for using those files are in my appvms.
I tried looking up on the net how to manually mount drobo but I can't 
figure out with dev drobo is, though I tried mounting a few that I 
wasn't sure about to no avail.

help! (please)

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

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Saturday, December 2, 2017 at 3:41:26 AM UTC-8, Stephan Marwedel wrote:
> Now we have a nice recipe to install Qubes on modern Thinkpads. This 
> should become part of the official documentation.

Pull request: https://github.com/QubesOS/qubes-doc/pull/490

-- 
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/308d1a40-7bf9-453b-a696-c0c94eedd26a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mystic Buyer]

Hi,

I was looking for Riseup invite as well, would be very helpful if I could
get a code. Please send me an email if anyone is willing to.

Thank you


On Wed, Nov 29, 2017 at 9:21 PM,  wrote:

> Hi, Can you send me rise up invitation code please.
>
> 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/6bc1afc7-3502-4897-a45c-27a4baff4188%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/CAD9tXNDqRh4ip-VoOFdoJrW4WeOyrmsLS0%3DDDTdiwyPcQjoj%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: USB Keyboard thoughts...

[Yethal]

W dniu piątek, 1 grudnia 2017 19:10:07 UTC+1 użytkownik Matty South napisał:
> I love the Qubes project! I've been thinking of ways to improve the security 
> when it comes to USB Keyboards. 
> 
> I'm sure a lot of us who use Qubes as our day-to-day OS have a nice keyboard 
> attached to the system. Upon plugging in the USB keyboard for the first time, 
> I rightfully got a security warning about the implications of passing USB 
> Keyboard input into dom0 (think USB Rubber Ducky attack among others). OK, 
> I'm on board so far. What surprises me is that I didn't just authorize THIS 
> keyboard to pass through to dom0, I have authorized *ANY* USB keyboard to 
> access dom0. I verified this with other keyboards and even a home-made Rubber 
> Ducky attack using a teensy.
> 
> Curious, is there a reason why we don't restrict the authorized USB keyboard 
> based on USB Serial number or even VID or PID. Sure with PID/VID, a physical 
> attacker who knows your brand of keyboard could still pass through 
> keystrokes, but it would still up the bar a little for these style of 
> attacks. 
> 
> I'm on Version 3.2 so forgive me if this has been addressed in 4.0.
> 
> Secondly, I don't want to be the guy begging for improvements, I would like 
> to contribute. Can anyone point me to a good place to start if I want to add 
> this feature? I'm thinking here maybe? 
> https://github.com/QubesOS/qubes-app-linux-usb-proxy

All of these values can be forged by the attacker. You may want to try using 
udev rules to block all keyboards except the ones that were present during boot 
process. You'd lose the ability to use USB keyboard plugged into a live system 
but it would also force a potential attacker to reboot your machine in order to 
use a rubber ducky.

-- 
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/153e0878-7269-472c-8ab4-993888e857dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: guid.conf for disposable VMs

[Yethal]

W dniu sobota, 2 grudnia 2017 18:26:36 UTC+1 użytkownik tech...@tutanota.com 
napisał:
> Hi,
> 
> I understand generally how to customize guid options via the 
> /etc/qubes/guid.conf file in Dom0 as per 
> https://www.qubes-os.org/doc/full-screen-mode
> 
> My question is, if I want this to effect disposable vms only, not globally, 
> what do use for the VM name in the VM: {} block in the file?
> 
> Thanks.

the dispvm template vm name so fedora-25-dvm or whatever it is called on your 
machine

-- 
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/16a2cfe0-076b-430e-983a-86c82b7bd92d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes audio

[charly LEMMINKÄINEN]

Le samedi 2 décembre 2017 00:07:44 UTC+1, charly LEMMINKÄINEN a écrit :
> Le vendredi 1 décembre 2017 21:33:52 UTC+1, Yethal a écrit :
> > W dniu piątek, 1 grudnia 2017 19:34:14 UTC+1 użytkownik charly LEMMINKÄINEN 
> > napisał:
> > > Le vendredi 1 décembre 2017 18:53:50 UTC+1, Yethal a écrit :
> > > > W dniu piątek, 1 grudnia 2017 15:40:34 UTC+1 użytkownik charly 
> > > > LEMMINKÄINEN napisał:
> > > > > Le vendredi 1 décembre 2017 13:02:12 UTC+1, awokd a écrit :
> > > > > > On Fri, December 1, 2017 10:07, charly LEMMINKÄINEN wrote:
> > > > > > >
> > > > > > > sorry to retrieve an old thread but I would like to know if qubes 
> > > > > > > r3.2
> > > > > > > does even support usb headset? I mean not by assigning it to a VM 
> > > > > > > but for
> > > > > > > general purpose across the whole system?
> > > > > > > pavucontrol is normally for inside the vm, not to install at the 
> > > > > > > system
> > > > > > > base.
> > > > > > 
> > > > > > Have you looked over https://www.qubes-os.org/doc/external-audio/ ?
> > > > > 
> > > > > Again, it's about the usage into a VM. I don't see why the built-in 
> > > > > audio would be accepted as a general audio device in a laptop, so you 
> > > > > can listen to a youtube video from a browser in one vm and at the 
> > > > > same time listen to a podcast or a video in another vm, and not a usb 
> > > > > headset
> > > > > So again, is it a way to make the general audio device a usb headset 
> > > > > as the built-in audio is, or is it a security risk and so qubes 
> > > > > doesn't allow it? Or Maybe it does work for some of you and so maybe 
> > > > > my headset is just not properly recognized?
> > > > 
> > > > Works systemwide if the USB controller is assigned to Dom0. Works in a 
> > > > specific qube if using sys-usb. I think it might be handy to be able to 
> > > > move audio backend from Dom0 to a specified VM to reduce attack surface.
> > > 
> > > so you're telling me that your headset is in usb and it's working ? 
> > > Because mine doesn't work, so are you sure that it is supposed to work 
> > > system-wide? 
> > > I understand that it would be more secure to have contained the audio to 
> > > one vm but right now it's not my purpose.
> > 
> > It is working in a specific vm if I assign it to the vm via qvm-usb. Was 
> > working systemwide when I had USB controllers in dom0
> 
> okey so it's mine then which is not recognized or something. Which one do you 
> use ? Should I wait for a kernel update?

ok apparently I had a problem with my headset but it's now available across the 
whole system

-- 
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/5413ad87-c3e6-4a43-94da-9ef69ec08b25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Stephan Marwedel]

Hi Joe,

thanks for the concise summary :-)

I actually forgot to mention the necessary changes to the xen.cfg that 
you correctly described.


Now we have a nice recipe to install Qubes on modern Thinkpads. This 
should become part of the official documentation.


Using this recipe will try to install Qubes on my recently acquired 
Anniversary Thinkpad 25 which is essentially a T470 with a different 
keyboard and a dedicated GPU.


Cheers,
Stephan

On 12/2/17 10:02 AM, Joe Hemmerlein wrote:

On Friday, December 1, 2017 at 2:01:47 PM UTC-8, Stephan Marwedel wrote:

I have installed Qubes 3.2 successfully on my Thinkpad T470p
   (20J6CTO1WW). This machine is pretty similar to the T470, except
   that is has a quad-core i7 CPU.  It runs perfectly and all Qubes
   functionality is available on that machine. The installation,
   however, was not an easy task.

 
 
1. Booting: UEFI is not a problem for the Qubes installer, but

   you must pay attention on how you created the bootable install
   media. Just using dd is not sufficient. I had to use the
   livecd-tools from Fedora to create the install media. After
   creating the media I had to manually set the partition label to
   BOOT using the dosfslabel utility. Otherwise, I was unable to boot
   from the media. It was not necessary to fall back to legacy boot
   or to mess around with the Grub configuration.

 
 2. Networking: The onboard ethernet  hardware is only supported by a

 4.9 kernel or later, but the installer containts a 4.4 kernel. So
 you have no network in teh sys-net vm. You have to manually download
 the source of the Intel network driver, compile it and install it
 using a USB media in the template vm. As soon as you have network
 access, upgrade dom0 to using the testing or unstable repository.

 


 3. Graphics: The Kaby Lake Intel graphics works well with a newer
 kernel.

 


 Summary: Prepare the boot media with more care than for older
 machines. Compile the ethernet network driver manually to enable
 network access after the install. Upgrade to kernel 4.9 in dom0 as
 soon as possible to enable graphics and networking support of your
 Thinkpad.

Danke, Stephan, your pointers were very valuable!

At first, I decided to just borrow an external DVD drive and boot off a DVD 
burned from the ISO, in UEFI mode. The result however was the same as when 
booting from my previously-created USB stick: grub boots, but no matter what i 
select, the screen briefly flashes and takes me back to grub. So.. yeah, the 
ISO image does not appear to be usable out of the box on some UEFI devices, 
even when burning it to a DVD.

Your description of the livecd-tools helped make good progress, but still 
without ability to boot the installer completely, but they sent me in the right 
direction. I then found 
https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk, which 
described a process very similar to yours (it omits the part about using 
dosfslabel, but has a part about also updating the xen.cfg file).

Altogether, this did the trick!

In condensed form, this is what i did to create a USB install stick that works 
with UEFI on the T470:
1. Use the "livecd-iso-to-disk" utility from fedora livecd-tools to put the ISO 
image onto an USB stick
2. rename the USB stick's partition label to BOOT
3. edit the /BOOT/EFI/xen.cfg file on the USB stick's partition to make sure all 
LABEL= instances are replaced with LABEL=BOOT

In a bit more detail:
- booted Fedora 26 live USB stick in UEFI mode
- installed livecd-tools: sudo dnf install livecd-tools
- attached a USB stick that contains the Qubes 4 RC3 x86-64 ISO image file
- verified digests and signatures for ISO image
- attached another USB stick to the fedora live instance to put the Qubes 
installer on (/dev/sdd)
- repartitioned /dev/sdd USB stick with a single (8GB) FAT32 partition and MBR, 
and marked bootable
- started imaging: sudo livecd-iso-to-disk 
/run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso /dev/sdd1
- waited for everything to complete (took quite a while)
- used dosfslabel to rename the qubes installer USB stick: sudo dosfslabel 
/dev/sdd1 BOOT
- manually edited the xen.cfg file on the install stick (located at /BOOT/EFI): replaced 
all instances of "LABEL=Qubes-R4.0-rc3-x86_64" with "LABEL=BOOT"

Success!

Now one thing that is different is that after installation, the 
correct/selected keyboard layout (in my case English-Dvorak) isn't active when 
prompted for the LUKS passphrase; but after entering it in QWERTY, Qubes OS 
boots and completes configuration.

But the primary issue, not being able to boot in UEFI mode, is solved.

Thanks everyone for your input!

Cheers,
-joe



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

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Friday, December 1, 2017 at 2:01:47 PM UTC-8, Stephan Marwedel wrote:
> I have installed Qubes 3.2 successfully on my Thinkpad T470p
>   (20J6CTO1WW). This machine is pretty similar to the T470, except
>   that is has a quad-core i7 CPU.  It runs perfectly and all Qubes
>   functionality is available on that machine. The installation,
>   however, was not an easy task. 
> 
> 
> 
> 1. Booting: UEFI is not a problem for the Qubes installer, but
>   you must pay attention on how you created the bootable install
>   media. Just using dd is not sufficient. I had to use the
>   livecd-tools from Fedora to create the install media. After
>   creating the media I had to manually set the partition label to
>   BOOT using the dosfslabel utility. Otherwise, I was unable to boot
>   from the media. It was not necessary to fall back to legacy boot
>   or to mess around with the Grub configuration. 
> 
> 
> 2. Networking: The onboard ethernet  hardware is only supported by a
> 4.9 kernel or later, but the installer containts a 4.4 kernel. So
> you have no network in teh sys-net vm. You have to manually download
> the source of the Intel network driver, compile it and install it
> using a USB media in the template vm. As soon as you have network
> access, upgrade dom0 to using the testing or unstable repository.
> 
> 
> 
> 3. Graphics: The Kaby Lake Intel graphics works well with a newer
> kernel. 
> 
> 
> 
> Summary: Prepare the boot media with more care than for older
> machines. Compile the ethernet network driver manually to enable
> network access after the install. Upgrade to kernel 4.9 in dom0 as
> soon as possible to enable graphics and networking support of your
> Thinkpad.

Danke, Stephan, your pointers were very valuable!

At first, I decided to just borrow an external DVD drive and boot off a DVD 
burned from the ISO, in UEFI mode. The result however was the same as when 
booting from my previously-created USB stick: grub boots, but no matter what i 
select, the screen briefly flashes and takes me back to grub. So.. yeah, the 
ISO image does not appear to be usable out of the box on some UEFI devices, 
even when burning it to a DVD.

Your description of the livecd-tools helped make good progress, but still 
without ability to boot the installer completely, but they sent me in the right 
direction. I then found 
https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk, which 
described a process very similar to yours (it omits the part about using 
dosfslabel, but has a part about also updating the xen.cfg file).

Altogether, this did the trick!

In condensed form, this is what i did to create a USB install stick that works 
with UEFI on the T470:
1. Use the "livecd-iso-to-disk" utility from fedora livecd-tools to put the ISO 
image onto an USB stick
2. rename the USB stick's partition label to BOOT
3. edit the /BOOT/EFI/xen.cfg file on the USB stick's partition to make sure 
all LABEL= instances are replaced with LABEL=BOOT

In a bit more detail:
- booted Fedora 26 live USB stick in UEFI mode
- installed livecd-tools: sudo dnf install livecd-tools
- attached a USB stick that contains the Qubes 4 RC3 x86-64 ISO image file
- verified digests and signatures for ISO image
- attached another USB stick to the fedora live instance to put the Qubes 
installer on (/dev/sdd)
- repartitioned /dev/sdd USB stick with a single (8GB) FAT32 partition and MBR, 
and marked bootable
- started imaging: sudo livecd-iso-to-disk 
/run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso /dev/sdd1
- waited for everything to complete (took quite a while)
- used dosfslabel to rename the qubes installer USB stick: sudo dosfslabel 
/dev/sdd1 BOOT
- manually edited the xen.cfg file on the install stick (located at 
/BOOT/EFI): replaced all instances of "LABEL=Qubes-R4.0-rc3-x86_64" 
with "LABEL=BOOT"

Success!

Now one thing that is different is that after installation, the 
correct/selected keyboard layout (in my case English-Dvorak) isn't active when 
prompted for the LUKS passphrase; but after entering it in QWERTY, Qubes OS 
boots and completes configuration. 

But the primary issue, not being able to boot in UEFI mode, is solved.

Thanks everyone for your input!

Cheers,
-joe

-- 
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/1e222b94-a3f7-4a54-bacd-fac7231fbc9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes support Secure Boot

[Leo Gaspard]

On 12/02/2017 03:11 AM, taii...@gmx.com wrote:
> On 11/23/2017 07:55 AM, Leo Gaspard wrote:
> 
>> Can you please avoid ranting against secure boot once again?
>>
>> Secure boot is *not* useless. It *does* bring security benefits,
>> although not as good as measured boot with a TPM: it requires an
>> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
>> of just coming in and replacing a non-encrypted element of the bootchain
>> by taking the hard disk out of its case without ever being noticed. So
>> if you have no TPM, using secure boot is a definitive security
>> enhancement.
> The "linux" SB (ie: red hat signed grub) is only for signed grub it
> doesn't sign the kernel or the initramfs, one can also mess with the
> BIOS or ME which is well within the skill level of a state attacker such
> as the MSS.

Ugh. Red Hat signed grub is not at all the only secure boot available
for linux: YOU CAN REPLACE THE KEYS IN YOUR UEFI WITH YOUR OWN. (sorry
for yelling but I think I've written it one too many times, maybe this
way it'll better stand out)

Please check [1] if you want to know how to do it by yourself.

As for signing the kernel or the initramfs, grub can also check the
signature of the kernel and initramfs, see [2] also (which does exactly
the same thing as secure boot except here grub is directly included in
the BIOS, so there is no need for signing it)

> There are also a variety of SB exploits/bypasses.
Of course there always will be flaws on systems, but does it mean you
shouldn't try to harden everything possible? Flaws can most often be
fixed, non-existent feature cannot

> Irregardless it'll be what eventually kills linux on the desktop for the
> average person after the vendors stop including the linux signing key
> (SB 2.0 specs don't obligate them to allow for owner control or even the
> inclusion of the second key unlike SB 1.0 specs), if you desire such
> features it would be much better to simply use a bios-embedded GRUB2 via
> coreboot which supports kernel/initramfs signing features.

Now you are just designing a future you don't like and state “that's
what will happen”. Sorry if I'm no seer, but for the desktop I haven't
owned yet a computer that doesn't allow one to change the keys, and thus
see no reason to believe what you are saying.

Also, libre/coreboot is a nice way to have a level of security
equivalent to secureboot (maybe slightly better because there is one
less step in the boot chain, thus one less possibility of flaw). But
then coreboot is not available/working on all hardware platforms, while
SB is, and the two bring equivalent security.

> "Secure" Boot is a MS trojan horse.

There is no argument to support this assertion. Please once again stop
spreading FUD.


[1]
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot

[2] https://libreboot.org/docs/gnulinux/grub_hardening.html

-- 
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/16f4d3dd-df08-5af6-4c64-8e29f9bc94e7%40gaspard.ninja.
For more options, visit https://groups.google.com/d/optout.