[qubes-users] Re: Moving dom0 screenshots immediately to VMs

[wordswithnemo]

On Friday, January 19, 2018 at 6:48:28 AM UTC-5, wordsw...@gmail.com wrote:
> On Friday, January 19, 2018 at 6:32:33 AM UTC-5, Alex Dubois wrote:
> > On Friday, 19 January 2018 08:55:27 UTC, wordsw...@gmail.com  wrote:
> > > I've been working on a solution for this, but unfortunately there are too 
> > > many factors that I'm not familiar with.
> > > 
> > > My goal is to to able to:
> > > 
> > > 1) Take a screenshot using the dom0 hotkey
> > > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
> > > option
> > > 3) A text entry box that prompts me for the destination VM
> > > 4) The screenshot is sent to the indicated VM
> > > 
> > > I think this can be accomplished with
> > > 
> > > .desktop application file
> > > zenity
> > > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
> > > 
> > > but I'm lost in the details.
> > > 
> > > Current problems
> > > 
> > > - I can't get dom0 to include my .desktop application files as "Open 
> > > with:" options in the "Screenshot" dialogue
> > > - I'm not sure what format the screenshot is in initially... will the 
> > > .desktop application receive a bunch of bits? Or the path to a temporary 
> > > file?
> > > - I can figure out how to pipe the screenshot if it's a file, but I don't 
> > > know how to handle a "bunch of bits" scenario
> > > 
> > > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> > > looks great, but the code is too complicated for me to review and I just 
> > > need basic functionality anyway. 
> > > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
> > 
> > This could be useful feature. Happy to help for the dev part...
> > 
> > What do you think about the default behavior being to:
> > - screen-shot only a VM window? Is it available?
> > - screen-shot an area that you lasso?
> > 
> > I'm suggesting these because the Qubes default should always be the safest 
> > that can be implemented...
> 
> Qubes already has built-in the capability to screenshot the entire desktop 
> (Printscreen)  or the current window (Ctrl+Printscreen).
> 
> Lasso would be nice I suppose, but might open up some way to exploit.

Just so I'm clearer - I'm just talking about a simple solution, not building 
any new application. We could use a .desktop file similar to this

[Desktop Entry]
Encoding=UTF-8
Name=BrowserVM
Exec=qvm-open-in-vm APPVMNAME %u
Terminal=false
X-MultipleArgs=false
Type=Application
Categories=Network;WebBrowser;
MimeType=x-scheme-handler/unknown

as documented in 
https://www.qubes-os.org/doc/tips-and-tricks/#opening-links-in-your-preferred-appvm

I've gotten this done so far

[Desktop Entry]
Encoding=UTF-8
Name=Open Screenshot in VM
Exec=zenity --entry --text="Enter destination domain name:" | qvm-open-in-vm %u
Terminal=false
X-MultipleArgs=false
Type=Application
Categories=Network;WebBrowser;
MimeType=x-scheme-handler/unknown

-- 
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/ef593abc-d71e-4cb5-8940-c12b06a6262d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Moving dom0 screenshots immediately to VMs

[wordswithnemo]

On Friday, January 19, 2018 at 6:32:33 AM UTC-5, Alex Dubois wrote:
> On Friday, 19 January 2018 08:55:27 UTC, wordsw...@gmail.com  wrote:
> > I've been working on a solution for this, but unfortunately there are too 
> > many factors that I'm not familiar with.
> > 
> > My goal is to to able to:
> > 
> > 1) Take a screenshot using the dom0 hotkey
> > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
> > option
> > 3) A text entry box that prompts me for the destination VM
> > 4) The screenshot is sent to the indicated VM
> > 
> > I think this can be accomplished with
> > 
> > .desktop application file
> > zenity
> > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
> > 
> > but I'm lost in the details.
> > 
> > Current problems
> > 
> > - I can't get dom0 to include my .desktop application files as "Open with:" 
> > options in the "Screenshot" dialogue
> > - I'm not sure what format the screenshot is in initially... will the 
> > .desktop application receive a bunch of bits? Or the path to a temporary 
> > file?
> > - I can figure out how to pipe the screenshot if it's a file, but I don't 
> > know how to handle a "bunch of bits" scenario
> > 
> > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> > looks great, but the code is too complicated for me to review and I just 
> > need basic functionality anyway. 
> > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
> 
> This could be useful feature. Happy to help for the dev part...
> 
> What do you think about the default behavior being to:
> - screen-shot only a VM window? Is it available?
> - screen-shot an area that you lasso?
> 
> I'm suggesting these because the Qubes default should always be the safest 
> that can be implemented...

Qubes already has built-in the capability to screenshot the entire desktop 
(Printscreen)  or the current window (Ctrl+Printscreen).

Lasso would be nice I suppose, but might open up some way to exploit.

-- 
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/b1ab8852-4873-4ea5-92a6-a98c6d8e282e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Moving dom0 screenshots immediately to VMs

[wordswithnemo]

I've been working on a solution for this, but unfortunately there are too many 
factors that I'm not familiar with.

My goal is to to able to:

1) Take a screenshot using the dom0 hotkey
2) In the "Screenshot" dialogue, select a script from the "Open with:" option
3) A text entry box that prompts me for the destination VM
4) The screenshot is sent to the indicated VM

I think this can be accomplished with

.desktop application file
zenity
qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm

but I'm lost in the details.

Current problems

- I can't get dom0 to include my .desktop application files as "Open with:" 
options in the "Screenshot" dialogue
- I'm not sure what format the screenshot is in initially... will the .desktop 
application receive a bunch of bits? Or the path to a temporary file?
- I can figure out how to pipe the screenshot if it's a file, but I don't know 
how to handle a "bunch of bits" scenario

Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which looks 
great, but the code is too complicated for me to review and I just need basic 
functionality anyway. 
https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh

-- 
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/977360d2-8b7f-49b3-b1cb-772a52385089%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Sporadic Inter-VM Routing Issues with Qubes Updates Proxy

[wordswithnemo]

On Monday, January 15, 2018 at 12:39:41 PM UTC-5, Kiwi17 wrote:
> Hi, I was hoping someone may be able to help make heads or tails of this 
> frustrating issue I'm having.
> 
> 
> 
> Background
> 
> I use a VPN configured as-per the Qubes recommended config for VPNs 
> (https://www.qubes-os.org/doc/vpn/). 
> 
> I have used this configuration with the following VM hierarchy for some 
> months without a problem: sys-net -> sys-firewall -> vpn -> vpn-firewall -> * 
> 
> [where "vpn-firewall" runs the qubes-yum-proxy service (verified TCP listener 
> is showing up in netstat on  0.0.0.0:8082)]
> 
> 
> 
> Problem
> 
> Recently I have encountered a problem where whenever I go to update a 
> TemplateVM, or dom0 - any VM that is configured to use the qubes update proxy 
> - the dnf update times out. The following is the output of "sudo dnf -vvv 
> --refresh update" on a Fedora 26 TemplateVM:
> 
> 
> 
> Cannot download 
> 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26=x86_64':
>  Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for 
> https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26=x86_64
>  [Connection timed out after 30003 milliseconds].
> 
> Error: Failed to synchronize cache for repo 'updates'
> 
> 
> 
> If we watch netstat during this attempted update, we see that a SYN is sent 
> to the correct update proxy address of 10.137.255.254:8082, but no SYN-ACK is 
> received:
> 
> tcp    0    1 10.137.5.14:57914   10.137.255.254:8082 SYN_SENT 
> 
> 
> 
> Leaving this running, no TCP connection is ever established with the 
> qubes-updates-proxy service at "vpn-firewall". Similarly, watching for 
> inbound connections on "vpn-firewall" yields no results for an incoming 
> connection from the TemplateVM. During this time, all  AppVMs continue to 
> have full network connectivity via the vpn-firewall gateway.
> 
> 
> 
> Now here's the weird bit... The problem is sporadic. Sometimes I can reboot 
> my host machine and the updates proxy is broken, other times it works fine.
> 
> 
> 
>  To my untrained eye, this appears to be a routing issue internal to Xen. 
> Does anyone have some advice on how I can investigate further?
> 
> 
> 
> Many thanks in advance,
> 
> Alex
> 
> 
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.

Some thoughts that may or may not be useful:

- qubes-updates-proxy should always be running on the firewall that is closest 
to the vpn. So if you are doing something like

sys-net->sys-firewall->sys-vpn->sys-firewall-vpn->sys-firewall-work

then qubes-updates-proxy should be running on your sys-firewall-vpn.

- Check that you've enabled the qubes-updates-proxy service on the 
sys-firewall-vpn Settings in Qubes VM Manager

- Check that the service is running on sys-firewall-vpn

sudo service qubes-updates-proxy status

If you're running your firewall with restricted memory then in my experience 
tinyproxy *sometimes* fails to start. This minimal memory requirement seems to 
be higher for Fedora 26 than 25.

- Check your dnf settings "cat /etc/dnf/dnf.conf" on your TemplateVM to confirm 
that it's set up to use the proxy. There should be a line at the bottom similar 
to

proxy=10.137.255.254

- Try to update the TemplateVM without using the proxy

-- 
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/cc86159b-eff4-41e1-87e8-58523a8db625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows HVM has network access, but claims there isn't

[wordswithnemo]

On Monday, September 11, 2017 at 1:24:37 PM UTC-4, anguil...@gmail.com wrote:
> On Saturday, September 9, 2017 at 7:18:56 AM UTC-7, Francesco wrote:
> > Hello,
> > 
> > some strange behavior. on Windows HVM template as well as dependent VMs. In 
> > all of them internet is working. I am sure of that because:
> > 1. on cmd pinging google or amazon works
> > 2. a banking application is able to connect and operate
> > 
> > but the icon on the system tray states: identifying... no network access
> > 
> > worse amazon Kindle for PC believes that and is unable to connect.
> > 
> > So I wonder if there is a way to tell the system tray that internet is 
> > already connected. Maybe that after that also Kindle will understand that.
> > 
> > 
> > If I click on the system tray there are lots of options, but all seem 
> > directed to create a new connection: wireless, dial-up, router etc, not to 
> > join an existing connection.
> > 
> > 
> > Hope there is an easy answer... Thanks
> > Best
> > Fran
> 
> If I recall, the current release notes for windows-tools says that the system 
> tray icon will show no network even tho there is and it works. It is like 
> this for me and I just accept it. 
> 
> If someone works out a workaround, cool. But currently, this is expected 
> behaviour.

I've had this issue for a long time, and it prevented me from activating Office 
365 (which I have to do at every boot for some reason).

I solve it by changing the IP in Windows settings to match the DNS IP - so eg 
10.137.10.1 instead of 10.137.10.28.

This does not *actually* have to be DNS IP. I'm not sure exactly what's 
happening, but I'm assuming that when DHCP service is selected in networking 
settings Windows attempts to verify the internet connection using that 
information. Obviously QubesNetworkService will override the information, and a 
conflict occurs.

I think as long as you set a static IP, you are fine. For example, if you set 
your Windows 7 TemplateVM to its DNS IP, your AppVM network connection should 
still work properly even though it may be on a different firewall.

You can verify via ipconfig that even though you have selected the DNS IP in 
network settings, you are still connected on the proper IP for Qubes networking.

-- 
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/531666b5-8d49-4f42-b15a-472cc7e7e9b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Error: VM Kernel does not exist:

[wordswithnemo]

> Known bug: https://github.com/QubesOS/qubes-issues/issues/2757
> 
> Workaround (in dom0):
> 
> $ for VM in `qvm-ls --raw-list`; do qvm-prefs -s $VM kernel default; done
> 
The recent dom0 update caused this issue for me again (I've had it before), and 
it was quickly fixed by the command above.

-- 
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/32651069-3656-4405-8fe1-a84dbfac08c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[wordswithnemo]

On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote:
> If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED 
> (SSD or spinning platter) drive, then you can create a range, install 
> the bootstrap/OS, and then mark that range as read-only.
> 
> After doing that *nothing* will be able to write to that area without 
> the password unlocking that range first, even Dom0 root user, but then 
> it will also need to be unlocked using that same password at the 
> appropriate moment during any update to the bootstrap/Xen code during 
> appropriate Dom0 updates. This same range can also protect the partition 
> table, MBR, and boot menu, etc. Multiple ranges can be set with 
> different attributes/encryption keys.
> 
> The tool you would need for doing this is "msed" (name given in my 
> fedora distro) or "sedutil" (from the drive trust alliance) which allows 
> you to talk to the drive via sata (not usb afaik) to encrypt or protect 
> defined ranges that you set up.
> 
> Just be careful to learn/test on a test system, because if you create an 
> encrypted range everything previously there disappears instantly, 
> including partitions. Its the world fastest way I know to completely 
> wipe a drive, flip one bit in the key, poof. Like magic. You can always 
> reset back to the factory default erasing everything on the drive.
> 
> Calculate your ranges, partition, setup encryption ranges, and install 
> stuff, then finally mark your /boot range as read-only. Don't encrypt 
> your /boot or you will need to install Pre-Boot-Authentication (PBA) and 
> supply a password at boot time.
> 
> Sedutil source and docs
> https://github.com/Drive-Trust-Alliance
> 

This is interesting. I suppose this would be a way to secure your system, and 
then you could add AEM over it? That way you are using the security features of 
the hardware, but not trusting them.

-- 
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/8935704e-0147-4df9-8504-b8bd731ad4d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[wordswithnemo]

> Plus, you always need to
> disconnect all untrusted USB devices while rebooting Qubes, regardless
> of whether you have USB qube set up or not.
> 

I just want to make sure that this is not always the case - according to 
https://www.qubes-os.org/doc/usb/, if you create the USB VM automatically 
during install, then Qubes will be set to hide USB devices from dom0 on boot.

>(Note: Beginning with R3.2, rd.qubes.hide_all_usb is set automatically if you 
>opt to create a USB qube during installation. This also occurs automatically 
>if you choose to create a USB qube using the qubesctl method, which is the 
>first pair of steps in the linked section.)

-- 
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/82488fb4-7482-464c-a977-fd4fa06707bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Network problems with Windows 7 HVM and AppVM

[wordswithnemo]

> I was able to gain network access by changing the network adapter IPv4 
> address to the same IP address set for the DNS, class A subnet mask, and no 
> gateway. I did receive a warning that this IP was in use. I have not however 
> seen any issues arise. I have internet access on my windows vm with tools 
> installed, as well as internet access on other vm's.

This worked for me as well, but it does bother me... I guess Windows thinks 
that it's taken that IP, but in reality is hasn't? It doesn't seem to affect 
anything outside of the Windows VM itself...

-- 
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/4eba9b18-14d7-4a6e-afaa-4a89c3e2ee32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows 7 HVM - suddenly no networking / Starting of Qubes Network Setup fails

[wordswithnemo]

On Tuesday, March 22, 2016 at 1:22:21 PM UTC-4, piitb...@gmail.com wrote:
> Hello,
> 
> after updating my windows 7 machine to the latest version, suddenly the 
> network conmectivity seems to be broken.
> If i try an ipconfig /release and ipconfig /renews I get the following Error 
> Message:
> 
> "RPC-Server is not available"
> 
> After some troubleshooting I found out that the "Qubes Network Setup" is not 
> started.
> When I start it manually via cmd I get an error message
> 
> c:\Program Files\Invisible Things Lab\Qubes Tools\bin\network-setup.exe 
> -service
> 
> Error:
> 
> [...] SvcMainLoop: StartServiceCtrlDispatcher failed with error 1063: 
> 
> Any ideas where to  continue from here?
> 
> As I have made a clone of the windows VM after installing, I retry the 
> setup/updates to figure out at which point the network connectivity gets 
> broken.
> 
> - Piit

I am having the same problem. Did you ever find a solution?

-- 
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/6f207011-daf2-4a1b-8a2b-0e5bb621b63c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Temporarily disabling xfce keyboard shortcuts while fulscreen

[wordswithnemo]

I'm looking to create a close-to-original-as-possible Windows 7 environment 
that I can run in fullscreen mode.

I'd like to keep Alt+Space and CTRL+Shift+C/V enabled, but disable the rest of 
the xfce shortcuts and pass that input directly to the VM (eg Alt+Tab).

Is there a simple way to do this? I've looked into xfconf-query, but I'm not 
satisfied with how well/consistently it functions (eg I can instantly change 
Alt+Tab to up_key, but I cannot instantly restore Alt+Tab to cycle_windows_key).

-- 
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/7d7d6c65-bd4e-474b-8c62-a771df907c35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: cognitive issues when default is to use tor

[wordswithnemo]

My understanding is that you shouldn't be accessing Tor through anything but 
anon-whonix or a copy of that VM (this might be wrong). I'm not sure what 
metadata your work applications may leak that will compromise the anonymity of 
your Tor connection. You should do some reading up on whonix.

But if you don't trust Tor more than https, when are you using it?

If you want to create a secure connection to your office, I think the best tool 
to use is VPN.

I'm not sure what kind of trigger you're looking for, but I'm sure that you 
could write a script that will make it happen.

-- 
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/732d15d1-7d44-4c15-85e6-bd8c716f2946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

On Thursday, June 29, 2017 at 2:11:15 PM UTC-4, Vít Šesták wrote:
> I feel this to be controversial. It is right as long as you implement it 
> carefully (How would you handle the separator being present in the content of 
> the file? How would you sanitize the filenames? And so on…) AND you don't 
> exceed the complexity of tar format.
> 
> Regards,
> Vít Šesták 'v6ak'

For my uses, I would trust tar over my own ability to handle the sanitization.

As for potential compromise to the destination VM - all qvm-copy-to-vm should 
be done moving down the ladder of trustworthiness anyway, right? If this file 
were going to compromise the destination VM, then presumably it's come from a 
VM that is not trustworthy to begin with.

-- 
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/822e10f6-8250-4280-9bbb-7bc829bf63e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

On Wednesday, June 28, 2017 at 4:21:36 PM UTC-4, Chris Laprise wrote:
> On 06/28/2017 12:19 PM, wordswithn...@gmail.com wrote:
> > Thanks, and point taken on not focusing on security implications.
> >
> > I found a thread from last year where some third-party devs are concerned 
> > about the implications of letting qvm-run -p run wild:
> >
> > https://github.com/SietsevanderMolen/i3-qubes/issues/15
> >
> > It's a good idea, but I think I'm looking for a more secure solution - if 
> > it's out there.
> >
> 
> IIUC, having dom0 parse the file list is whats worrying you? Otherwise, 
> passing data through dom0 (no parsing) should be considered secure.
> 
> You can have dom0 pipe between machines like so:
> qvm-run -p sys-net "tar -cf - /etc/NetworkManager/system-connections" | 
> qvm-run -p sys-net-profiles "tar -xf -"
> 
> This entails a small amount of risk to the profiles VM (because tar file 
> is parsed there), but not to dom0.
> 
> -- 
> 
> Chris Laprise, tas...@openmailbox.org
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

So in this case, sys-net could return whatever malicious file it desired, it 
would be passed through dom0 one character at a time without absolutely no 
interpretation, ending up at the destination VM?

Or would dom0 collect the entire text of the file, and then pipe it in one 
piece to the destination VM?

-- 
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/61e35a4f-70be-4fd9-b53b-42a1cccfecf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

On Thursday, June 29, 2017 at 1:26:57 AM UTC-4, Vít Šesták wrote:
> It might be pointless to consider risks of passing result of qvm-run -p to 
> dom0 Bash expansion when you have path traversal in the first place. When 
> command «ls 
> /etc/NetworkManager/system-connections/» in sys-net returns paths like 
> “../.bashrc ../../.bashrc ../../../.bashrc” and the cat command returns some 
> arbitrary shell commands, you are close to be totally compromised by a 
> malicious sys-net.
> 
> Regards,
> Vít Šesták 'v6ak'

Thanks, you identified the problem more precisely than I would know how to.

-- 
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/0f4b6782-3320-4d14-831c-ee35425ea00d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

> 
> Thanks, and point taken on not focusing on security implications.
> 
> I found a thread from last year where some third-party devs are concerned 
> about the implications of letting qvm-run -p run wild:
> 
> https://github.com/SietsevanderMolen/i3-qubes/issues/15
> 
> It's a good idea, but I think I'm looking for a more secure solution - if 
> it's out there.

I'm trying this for a solution:

- Creating sys-transfer-station VM
- Set it as internal VM (this VM will never be used for anything but 
transferring files)
- qubes.Filecopy policy: $anyvm  sys-transfer-station  allow
- As the computer shuts down, add to qubes.Filecopy policy: 
sys-transfer-station sys-net-profiles allow
- Transfer files
- Remove "sys-transfer-station sys-net-profiles allow"

I think this might do the trick... any comments on how this would be insecure? 
Seems somewhat similar to the qubes-dom0-update mechanism with sys-firewall.

-- 
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/42ad2989-7b08-459f-976e-e89a58670c54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

On Wednesday, June 28, 2017 at 11:53:51 AM UTC-4, qubenix wrote:
> wordswithn...@gmail.com:
> > On Wednesday, June 28, 2017 at 10:07:04 AM UTC-4, qubenix wrote:
> >> qubenix:
> >>> wordswithn...@gmail.com:
>  I want to copy network connection profiles from sys-net to 
>  sys-net-profiles as my computer shuts down.
> 
>  I'm creating a bash script in dom0 to help with this.
> 
>  I could use 
> 
>  qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
>  /etc/NetworkManager/system-connections/*"
> 
>  ...but that will spawn a dom0 confirmation dialogue that I'd rather 
>  avoid (after all, dom0 is initiating the copy).
> 
>  I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I 
>  don't want to trust sys-net to initiate this copy on its own.
> 
>  Is there any way to directly copy files from one VM to another, executed 
>  directly from dom0?
> 
> >>>
> >>> Not sure if it's the best solution, but this should work for avoiding
> >>> prompt (briefly tested):
> >>>
> >>> for i in $(qvm-run -a -p -u root sys-net "ls
> >>> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
> >>> /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
> >>> sys-net-profiles $i; done
> >>>
> >>
> >> Oops small typo (forgot to name "sys-net" one time). Fixed:
> >>
> >> for i in $(qvm-run -a -p -u root sys-net "ls
> >> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root
> >> sys-net "cat /etc/NetworkManager/system-connections/$i" > $i;
> >> qvm-move-to-vm sys-net-profiles $i; done
> >>
> >> -- 
> >> qubenix
> >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> > 
> > How much of a risk do you think this is, passing the file contents through 
> > dom0 via qvm-run -ap?
> > 
> 
> Yeah, this is moderately secure IMHO. You are copying everything from
> /etc/NetworkManager/system-connections dir to dom0 before being moved to
> destination vm without check. So theoretically something malicious could
> be placed there. However, I don't see how it would be executed in dom0
> (should the file be malicious). I took no consideration for security,
> only to solve the problem of prompt.
> 
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

Thanks, and point taken on not focusing on security implications.

I found a thread from last year where some third-party devs are concerned about 
the implications of letting qvm-run -p run wild:

https://github.com/SietsevanderMolen/i3-qubes/issues/15

It's a good idea, but I think I'm looking for a more secure solution - if it's 
out there.

-- 
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/7f8f1a63-d5ab-4062-9522-b64a90fb5c6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Copying between VMs from dom0

[wordswithnemo]

On Wednesday, June 28, 2017 at 10:07:04 AM UTC-4, qubenix wrote:
> qubenix:
> > wordswithn...@gmail.com:
> >> I want to copy network connection profiles from sys-net to 
> >> sys-net-profiles as my computer shuts down.
> >>
> >> I'm creating a bash script in dom0 to help with this.
> >>
> >> I could use 
> >>
> >> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
> >> /etc/NetworkManager/system-connections/*"
> >>
> >> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid 
> >> (after all, dom0 is initiating the copy).
> >>
> >> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I 
> >> don't want to trust sys-net to initiate this copy on its own.
> >>
> >> Is there any way to directly copy files from one VM to another, executed 
> >> directly from dom0?
> >>
> > 
> > Not sure if it's the best solution, but this should work for avoiding
> > prompt (briefly tested):
> > 
> > for i in $(qvm-run -a -p -u root sys-net "ls
> > /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
> > /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
> > sys-net-profiles $i; done
> > 
> 
> Oops small typo (forgot to name "sys-net" one time). Fixed:
> 
> for i in $(qvm-run -a -p -u root sys-net "ls
> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root
> sys-net "cat /etc/NetworkManager/system-connections/$i" > $i;
> qvm-move-to-vm sys-net-profiles $i; done
> 
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

How much of a risk do you think this is, passing the file contents through dom0 
via qvm-run -ap?

-- 
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/bfac61d0-8624-4b88-b69a-d74b2c615579%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Copying between VMs from dom0

[wordswithnemo]

I want to copy network connection profiles from sys-net to sys-net-profiles as 
my computer shuts down.

I'm creating a bash script in dom0 to help with this.

I could use 

qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles 
/etc/NetworkManager/system-connections/*"

...but that will spawn a dom0 confirmation dialogue that I'd rather avoid 
(after all, dom0 is initiating the copy).

I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't 
want to trust sys-net to initiate this copy on its own.

Is there any way to directly copy files from one VM to another, executed 
directly from dom0?

-- 
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/d0300dc5-5a52-479a-ae3e-ef7e19cca404%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Introducing the Qubes Admin API

[wordswithnemo]

On Tuesday, June 27, 2017 at 9:58:04 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> Joanna has just published a new post: "Introducing the Qubes Admin API".
> You can view the post on the Qubes website here:
> 
> https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/
> 

> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZUwzvAAoJENtN07w5UDAw8lwQAMYYeoornBeK61MZzET23hYX
> +U8J5VvCxH1TKvgYv8Rc+ls2NHDmqFOVeMuyVPYoShyPS2GIuo2yvX6kZJ64nvGr
> mUa/QsMWaemBZFqNbMSoLvlvHzzW8hCh6mPzJPJSGTPF1Cri15VcT92+w6Cr0FUL
> //Hy9f4zG7B2fdTeFn7hweXBeoUTIdYQRp3MRVH1HUHsiAThmizI5MhhaRX2MaSa
> 7P0RWt038r0p7pVTk1NDjTprzUripyUA+vgXiyDuHZ8wWAPorJh87fdQBHMYwnzv
> mTx24MbuLzq6kKwYon0+JD2ZNhMMjVtqmKzyQNrLN2qDFfo5xxMlrMI6UiUfZxM4
> GgyTNLYDV/N/iaO6/rDNfYgoD4HuZsY4ri7hmMH//160APqE0UgZhn0skf0EftYp
> 2fqQqcqDXPQu0m+sGgjskep8oOeSSYv33RfPyTrtteFUJJx750i+M3WQ8YD6H99r
> fu23Nc/jZra3Qvdn5D7RlYEKzrXQ4WtfUBMBGWE21preVtHNNEGw3a+uwoCBCXDE
> SUSYRFr1q7Z7kLktA0r1YPrpTy8AXuQiuxsx0Iy2f0Oj6N974vE5VGaOVtgjD66C
> switMvZ9SiYSVbTSnCxHKXoRFvT+zJl6TsPJEuxsS1CQQ/G4ZulUDCmxligR33NW
> 47uWB02S+EXTcCZ2/lA9
> =6oUu
> -END PGP SIGNATURE-

Congrats to the Qubes team on the birth of this new feature! Here's hoping that 
this speeds adoption among corporate users and opens a new funding stream for 
the project.

-- 
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/7316b0f7-f2f3-4b3b-836a-975bcd6f309f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Introducing the Qubes Admin API

[wordswithnemo]

On Tuesday, June 27, 2017 at 9:58:04 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> Joanna has just published a new post: "Introducing the Qubes Admin API".
> You can view the post on the Qubes website here:
> 
> https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/
> 
> The full Markdown source is reproduced below, and the image from the post
> is attached to this message.
> 
> - 
> 8<--
> 
> - ---
> layout: post
> title: "Introducing the Qubes Admin API"
> categories:
>  - articles
>  - security
> author: Joanna Rutkowska
> - ---
> 
> This post starts the "cool things coming in Qubes 4.0" series and focuses on
> what we call the "Qubes Admin API." This should not be confused with Qubes 
> [Salt
> Stack integration], which we have already introduced in Qubes 3.2.
> 
> ## High-level overview
> 
> Let's start with a high-level architecture picture of how the Admin API fits
> into the Qubes OS architecture:
> 
> ![Qubes Admin API architecture](/attachment/wiki/posts/admin-api.png)
> 
> As we can see, the main concept behind the Admin API is to let _select_ VMs
> preform various _select_ administrative functions over the Qubes OS system.
> 
> If this idea scares the hell out of you, then, my dear reader, we're on the 
> same
> side. Indeed, if we're not careful, we can use the Admin API to shoot 
> ourselves
> in the foot.  Moreover, it might look like we're actually adding complexity 
> and
> enlarging the amount of trusted code (TCB) in Qubes OS. All good intuitions. 
> But
> below I argue that the opposite actually holds, i.e. that the Admin API allows
> us to actually _shrink_ the amount of trusted code, _simplify_ trust
> relationships in the system, and ultimately to improve the overall security at
> the end of the day. It's a bit like comparing SSH to Telnet. Admittedly, at
> first sight, the SSH protocol has much more complexity than Telnet, yet no one
> questions today that SSH is actually significantly more secure than the much
> simpler Telnet.
> 
> So, let's first quickly look at examples of why we have introduced the Admin
> API, i.e. what problems it helps to solve and how.
> 
> ## Management VMs
> 
> For Qubes OS to become suitable for use in large organizations and/or 
> corporate
> environments, it inevitably must become remotely manageable by entities such 
> as
> corporate IT departments. There are, of course, many ways to implement this, 
> but
> most would punch too many holes in the Qubes security model.  For example, if 
> we
> wanted to run some management agent in dom0, this would not only open up
> possible ways of attacking the whole system by exploiting potential bugs in 
> the
> agent itself, but it would also require us to allow networking in dom0, 
> exposing
> it to a number of additional attacks.
> 
> The Admin API solves this problem elegantly without requiring network access 
> to
> dom0, and we show exactly how below.
> 
> Additionally, the Admin API nicely complements our existing [Salt Stack
> integration]. While the latter is perfect for pre-configuration at install 
> time,
> the former is ideal for ongoing system maintenance, monitoring, and on-demand
> provisioning of VMs.
> 
> Last but not least, we've designed the Admin API with the goal of allowing 
> very
> strict "need to know" (and "need to do" for that matter) rules. This means 
> that
> it should be possible to have admin roles (implemented as specific VMs) that
> would be able to e.g. provision and manage a user's AppVMs, **but not be able 
> to
> read the user's data!** Of course, this is more tricky than it might seem when
> we look at the diagram above, and I discuss some of the catches and solutions
> below. We hope this will pave the way for organizations to embrace the idea of
> **non-privileged admins**.
> 
> ## The GUI domain
> 
> In the current Qubes architecture we've combined two different subsystems: 1)
> the (trusted) GUI subsystem and 2) the Admin stack. They're both in the same 
> VM:
> the almighty dom0.
> 
> This has somewhat made sense, since the GUI subsystem, which comprises the
> Window Manager, X server and graphics drivers, must be trusted anyway. After
> all, the GUI subsystem "sees" all your sensitive data, and it can also mimic 
> any
> user actions by injecting keystrokes and/or mouse movements.
> 
> Also, in contrast to traditional desktop systems, the Qubes GUI subsystem is
> very well isolated from the external world (user apps, USB devices, 
> networking,
> etc.), which means there is very little chance of compromising it from the
> outside.
> 
> Yet, there are several good reasons to move the GUI code away from the Admin 
> VM
> (i.e. dom0) to a separate, _less_ trusted and _less_ privileged VM:
> 
> 1. The possibility of efficiently separating the user and admin roles. This is
>somewhat complementary to the admin 

[qubes-users] So you accidentally attached your SATA controller to sys-usb

[wordswithnemo]

Just sharing a bit of knowledge recently-gained knowledge.

If you accidentally attach a device to sys-usb that you shouldn't have, Qubes 
may refuse to boot.

Here's how to fix the problem:

1) Boot into Recovery/Rescue mode from the Qubes Install USB
2) Qubes will mount your drive after you enter your LUKS password
3) Edit your /var/lib/qubes.xml file to remove all entries from "pcidevs=" for 
your sys-usb (note that it is not sufficient to turn off auto-starting, the 
system still will not start)

If Qubes Recovery/Rescue doesn't automatically mount your LUKS drive

1) Boot Fedora on live USB
2) Follow the instructions here to mount your LUKS-encrypted disk 
https://alvinabad.wordpress.com/2012/09/22/how-to-recover-a-luks-encrypted-disk/
3) Edit your /var/lib/qubes.xml file to remove all entries from "pcidevs=" for 
your sys-usb

-- 
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/997accc2-d4c1-4f7c-ba6e-3242adff244f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] T470 - High temp/short battery life despite low/no CPU load

[wordswithnemo]

I'm running the 4.9.29-17 testing kernel on dom0, because my display requires 
it.

At idle, my CPU runs around 40-45C. This is when I'm not using the laptop and 
Qubes VM Manager, as well as dom0 system tools, show ~0% CPU usage.

Under load it can spike as high as 75C. Load in this case might be browsing an 
SAAS tool or viewing a YouTube video.

I have an internal battery plus the largest external battery available, 94 Wh 
in total. Normally, on Windows, this would translate into 12 to 17 hours of 
battery life, but on Qubes I'm looking at 6 or less.

I'm assuming this has something to do with power management, so here is what 
I'm seeing in xenpm while the system is under light to moderate load and the 
system is hovering around 50C:

-

dom0: xenpm start 60

Timeout set to 60 seconds
Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ...
Elapsed time (ms): 6

CPU0:   Residency(ms)   Avg Res(ms)
  C017208   (28.58%)0.08
  C142991   (71.40%)0.20
  C29   ( 0.02%)0.30
  C30   ( 0.00%)0.00

  P00   ( 0.00%)
  P1868 ( 5.53%)
  P213  ( 0.09%)
  P30   ( 0.00%)
  P47   ( 0.05%)
  P567  ( 0.43%)
  P685  ( 0.54%)
  P769  ( 0.44%)
  P820  ( 0.13%)
  P994  ( 0.60%)
  P10   61  ( 0.39%)
  P11   137 ( 0.87%)
  P12   92  ( 0.59%)
  P13   64  ( 0.41%)
  P14   406 ( 2.59%)
  P15   13719   (87.33%)
  Avg freq  1036370 KHz

CPU1:   Residency(ms)   Avg Res(ms)
  C017209   (28.58%)0.08
  C142992   (71.41%)0.20
  C27   ( 0.01%)0.36
  C30   ( 0.00%)0.00

  P00   ( 0.00%)
  P1925 ( 5.89%)
  P218  ( 0.12%)
  P333  ( 0.21%)
  P438  ( 0.25%)
  P550  ( 0.32%)
  P638  ( 0.25%)
  P767  ( 0.43%)
  P837  ( 0.24%)
  P9104 ( 0.66%)
  P10   91  ( 0.58%)
  P11   156 ( 1.00%)
  P12   73  ( 0.47%)
  P13   59  ( 0.38%)
  P14   444 ( 2.83%)
  P15   13580   (86.39%)
  Avg freq  1036370 KHz

CPU2:   Residency(ms)   Avg Res(ms)
  C017408   (28.91%)0.07
  C142792   (71.07%)0.17
  C27   ( 0.01%)0.40
  C30   ( 0.00%)0.00

  P00   ( 0.00%)
  P1895 ( 5.67%)
  P217  ( 0.11%)
  P320  ( 0.13%)
  P460  ( 0.38%)
  P517  ( 0.11%)
  P646  ( 0.30%)
  P7104 ( 0.66%)
  P821  ( 0.13%)
  P994  ( 0.60%)
  P10   50  ( 0.32%)
  P11   175 ( 1.11%)
  P12   85  ( 0.54%)
  P13   43  ( 0.28%)
  P14   494 ( 3.13%)
  P15   13685   (86.54%)
  Avg freq  1036370 KHz

CPU3:   Residency(ms)   Avg Res(ms)
  C017389   (28.88%)0.06
  C142814   (71.11%)0.15
  C24   ( 0.01%)0.27
  C30   ( 0.00%)0.00

  P00   ( 0.00%)
  P1888 ( 5.63%)
  P211  ( 0.07%)
  P30   ( 0.00%)
  P434  ( 0.22%)
  P559  ( 0.38%)
  P637  ( 0.24%)
  P765  ( 0.41%)
  P840  ( 0.26%)
  P988  ( 0.56%)
  P10   60  ( 0.39%)
  P11   143 ( 0.91%)
  P12   53  ( 0.34%)
  P13   100 ( 0.63%)
  P14   523 ( 3.32%)
  P15   13660   (86.64%)
  Avg freq  1036370 KHz

Socket 0
 Core 0 CPU 0
 Core 1 CPU 2

---

And what xenpm is showing for frequency parameters

---

cpu id   : 0
affected_cpus: 0
cpuinfo frequency: max [2801000] min [40] cur [80]
scaling_driver   : acpi-cpufreq
scaling_avail_gov: userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific  :
sampling_rate: max [1000] min [1] cur [2]
up_threshold : 80
scaling_avail_freq   : 2801000 280 270 250 240 220 200 
180 160 150 130 110 80 70 60 *40
scaling frequency: max [280] min [40] cur [40]
turbo mode   : enabled

cpu id   : 1
affected_cpus: 1
cpuinfo frequency: max [2801000] min [40] cur [80]
scaling_driver   : acpi-cpufreq
scaling_avail_gov: userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific  :
sampling_rate: max [1000] min [1] cur [2]
up_threshold : 80
scaling_avail_freq   : 2801000 280 270 250 240 220 200 
180 160 150 130 110 80 70 60 *40
scaling frequency: max [280] min [40] cur [40]
turbo mode   : enabled

cpu id   : 2
affected_cpus: 2
cpuinfo frequency: max [2801000] min [40] cur [80]
scaling_driver   : acpi-cpufreq
scaling_avail_gov: userspace 

Re: [qubes-users] Lenovo T470 - x startup failed

[wordswithnemo]

On Saturday, June 3, 2017 at 3:48:57 AM UTC-4, wordsw...@gmail.com wrote:
> On Wednesday, May 31, 2017 at 8:24:59 PM UTC-4, cooloutac wrote:
> > On Wednesday, May 31, 2017 at 1:39:00 PM UTC-4, wordsw...@gmail.com wrote:
> > > On Monday, May 29, 2017 at 12:21:35 AM UTC-4, Mike Freemon wrote:
> > > > On 05/28/2017 08:12 PM, wordswithn...@gmail.com wrote:
> > > > > I'm attempting to install on my new T470:
> > > > >
> > > > > i7-7600U
> > > > > Intel HD Graphics 620
> > > > > 500GB HDD
> > > > >
> > > > > Starting the installer, I get this error:
> > > > >
> > > > > X startup failed, falling back to text mode
> > > > >
> > > > > I'm assuming there is some graphics card issue, but I can't find any 
> > > > > reports of people working to solve installer problems with the Intel 
> > > > > 620. It seems to be just issues after installation.
> > > > >
> > > > > I tried to install in text mode, but I got an error when autoparting 
> > > > > the disk (something to do with LUKS key) which seems to be universal 
> > > > > and not to have a solution.
> > > > >
> > > > > I took the recommended steps for installing on a Lenovo with UEFI.
> > > > >
> > > > > Any suggestions on the next step for troubleshooting?
> > > > 
> > > > https://groups.google.com/forum/#!msg/qubes-users/Eq2zZU5yXEs/qs94AX1uAAAJ
> > > 
> > > Thanks for referring me to this.
> > > 
> > > I followed that thread to this one which included a very helpful 
> > > kickstart config:
> > > 
> > > https://groups.google.com/forum/#!msg/qubes-users/-9qRHSkwfy8/CCx08nnTVEAJ
> > > 
> > > I was able to install completely, but now Qubes freezes at "[OK] Starting 
> > > Accounts Service." I'll post another thread on that.
> > 
> > looks like you still having gpu driver problems. I would still suggest my 
> > earlier suggestions.
> 
> Can you help me with implementing these?
> 
> > Try to change kernel options from grub to add nomodeset. see if anything 
> > diff happens.
> 
> Not sure how to do this.
> 
> > enable testing repo and install latest kernel.
> 
> I can't start Qubes, so how can I do this?

Never mind, I've figured out both of these. Unfortunately, it doesn't help, 
although installing the new kernel does get X working. I'm still stuck on [OK] 
Starting Accounts Service.

I'm guessing there's something in the kickstart config that's causing the 
problem.

I wonder if there's a way to update the kernel for the installer? Some way to 
boot the USB to a text console, then update the kernel, then start the 
installation process.

-- 
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/e4688118-8649-418a-acad-205bd322f851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Lenovo s230u "Twist"

[wordswithnemo]

On Tuesday, April 18, 2017 at 2:50:02 AM UTC-4, wordsw...@gmail.com wrote:
> qubes-hcl-report document is attached.
> 
> Here are my notes:
> 
> * Required steps to address hardware issues before installation
> ** Option 1: Immediately replace Broadcom PCIe WIFI chip with Intel Centrino 
> 2230 (as explained below)
> ** Option 2: Remove Broadcom PCIe WIFI chip during installation
> *** Qubes launches sys-net on boot (if setup during installation), and 
> initiates the attached WIFI chip, causing an unrecoverable system freeze.
> *** Disabling the WIFI chip in BIOS may also be a solution.
> *** Once Qubes is installed, you may remove the WIFI device from sys-net and 
> reinstall the hardware. You can troubleshoot this hardware by creating a 
> sequestered NetVM (eg sys-net-broadcom) and using your ethernet connection in 
> sys-net.
> 
> * Hardware changes I made
> ** Swapped out the original PCIe WIFI adapter (a Broadcom chip) which doesn't 
> seem to be compatible - possibly with non-free firmware
> ** Replaced with an Intel Centrino 2230BNHMW
> *** Only selected devices are compatible with the Lenovo motherboard 
> whitelist.
> *** Purchased here 
> https://www.amazon.com/Intel-Centrino-Express-Bluetooth-2230BNHMW/dp/B009DAFJRM.
> *** "FRU P/N: 04W3765" from the image references the Field Replacement Unit 
> product number from Lenovo documentation. My chip did not arrive with that 
> FRU indicated on the label, but it worked anyway.
> *** No additional firmware required.
> *** Downside is this chip does not work on 5Ghz bands. I have not yet tested 
> bluetooth.
> ** Replaced HDD with SSD
> 
> * Outstanding security issues
> ** TPM is present but I have not enabled/tested it yet.
> 
> * Outstanding non-security issues
> ** Keyboard
> *** The keyboard will "freeze" intermittently on a fresh (from power off) 
> boot. If the keyboard freezes during FDE password input, or during user login 
> you must restart the system and try again. Once you are past user login, the 
> Power button fix below will help.
> ** Touchpad/nipple
> *** Touchpad/nipple does not work on a fresh boot.
> ** Touchscreen
> *** I have not been able to make the touchscreen work yet, but I'm 
> optimistic. It does work on other distributions.
> 
> * Suggested approach for working around non-security issues
> ** As soon as possible after first boot, set the power button to activate 
> Standby mode
> *** Putting the system in Standby will "reset" the frozen keyboard.
> ** Use an external mouse instead of touchpad/nipple
> *** This will allow for mouse movement when freshly booted.
> 
> * Alternative approach for working around non-security issues
> ** Always reboot your laptop immediately after login on a fresh boot, using 
> the xfce "Log Out" menu
> *** This will enable the touchpad/nipple and prevent the keyboard from 
> freezing, once Qubes restarts.

Upgrading to kernel 4.9.29-17 (from the testing repo) fixed the mouse and 
keyboard issues!

It has apparently caused my Intel PCIe WiFi card to crash when returning from 
suspend, requiring a reboot of sys-net.

** First install the new kernel package **

dom0: qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel

dnf may ask you to add --best --allowerasing to remove conflicts. I did this, 
and it erased kernel 4.4.14-11, which is fine.

** Then update your boot files **

*legacy*

dom0: sudo grub2-mkconfig -o /boot/grub2/grub.cfg

*(U)EFI*

dom0: sudo nano /boot/efi/EFI/qubes/xen.cfg

(note that you will not be able to enter the directory manually, you have to 
run nano from another directory)

Confirm that your xen.cfg has the new kernel set as default, and has an entry 
at the bottom that looks similar to the entries for the other kernels.

If it doesn't, copy one of the entries from another kernel and adjust the 
kernel version. Then change the default entry at the top.

** Reboot **

And you should be in good shape!

-- 
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/2a0c4dc0-ced3-4060-bc9f-940649f2e698%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Lenovo T470 - x startup failed

[wordswithnemo]

On Wednesday, May 31, 2017 at 8:24:59 PM UTC-4, cooloutac wrote:
> On Wednesday, May 31, 2017 at 1:39:00 PM UTC-4, wordsw...@gmail.com wrote:
> > On Monday, May 29, 2017 at 12:21:35 AM UTC-4, Mike Freemon wrote:
> > > On 05/28/2017 08:12 PM, wordswithn...@gmail.com wrote:
> > > > I'm attempting to install on my new T470:
> > > >
> > > > i7-7600U
> > > > Intel HD Graphics 620
> > > > 500GB HDD
> > > >
> > > > Starting the installer, I get this error:
> > > >
> > > > X startup failed, falling back to text mode
> > > >
> > > > I'm assuming there is some graphics card issue, but I can't find any 
> > > > reports of people working to solve installer problems with the Intel 
> > > > 620. It seems to be just issues after installation.
> > > >
> > > > I tried to install in text mode, but I got an error when autoparting 
> > > > the disk (something to do with LUKS key) which seems to be universal 
> > > > and not to have a solution.
> > > >
> > > > I took the recommended steps for installing on a Lenovo with UEFI.
> > > >
> > > > Any suggestions on the next step for troubleshooting?
> > > 
> > > https://groups.google.com/forum/#!msg/qubes-users/Eq2zZU5yXEs/qs94AX1uAAAJ
> > 
> > Thanks for referring me to this.
> > 
> > I followed that thread to this one which included a very helpful kickstart 
> > config:
> > 
> > https://groups.google.com/forum/#!msg/qubes-users/-9qRHSkwfy8/CCx08nnTVEAJ
> > 
> > I was able to install completely, but now Qubes freezes at "[OK] Starting 
> > Accounts Service." I'll post another thread on that.
> 
> looks like you still having gpu driver problems. I would still suggest my 
> earlier suggestions.

Can you help me with implementing these?

> Try to change kernel options from grub to add nomodeset. see if anything diff 
> happens.

Not sure how to do this.

> enable testing repo and install latest kernel.

I can't start Qubes, so how can I do this?

-- 
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/c345b10c-7387-48b3-8e24-58245d1ebc1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Lenovo T450 UEFI Troubleshooting - what does this mean?

[wordswithnemo]

>From https://www.qubes-os.org/doc/thinkpad-troubleshooting/:

Instructions for getting your Lenovo 450 laptop working with Qubes/Linux

Lenovo 450 uses UEFI, so some settings are needed to get Qubes (or Fedora) to 
boot, otherwise Qubes install USB stick will reboot right after boot selector 
screen and not continue install.
Setting UEFI options to get Qubes install to boot

Enable Legacy USB mode
Disable all Secure Boot and UEFI options, but leave this enabled: Config / 
USB / USB UEFI BIOS SUPPORT
Save settings and reboot
Install Qubes

… and now enjoy :) These settings may be needed also in other UEFI computers.

Does this mean the installation will be legacy? I installed via this method (on 
a T470) and the computer will not begin to boot except in legacy mode.

-- 
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/1436c0a4-3252-4d8c-9503-95ed8832be97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Lenovo T470 - x startup failed

[wordswithnemo]

On Monday, May 29, 2017 at 12:21:35 AM UTC-4, Mike Freemon wrote:
> On 05/28/2017 08:12 PM, wordswithn...@gmail.com wrote:
> > I'm attempting to install on my new T470:
> >
> > i7-7600U
> > Intel HD Graphics 620
> > 500GB HDD
> >
> > Starting the installer, I get this error:
> >
> > X startup failed, falling back to text mode
> >
> > I'm assuming there is some graphics card issue, but I can't find any 
> > reports of people working to solve installer problems with the Intel 620. 
> > It seems to be just issues after installation.
> >
> > I tried to install in text mode, but I got an error when autoparting the 
> > disk (something to do with LUKS key) which seems to be universal and not to 
> > have a solution.
> >
> > I took the recommended steps for installing on a Lenovo with UEFI.
> >
> > Any suggestions on the next step for troubleshooting?
> 
> https://groups.google.com/forum/#!msg/qubes-users/Eq2zZU5yXEs/qs94AX1uAAAJ

Thanks for referring me to this.

I followed that thread to this one which included a very helpful kickstart 
config:

https://groups.google.com/forum/#!msg/qubes-users/-9qRHSkwfy8/CCx08nnTVEAJ

I was able to install completely, but now Qubes freezes at "[OK] Starting 
Accounts Service." I'll post another thread on that.

-- 
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/e8203807-975d-414d-9eaa-73023c464c1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Lenovo T470 - x startup failed

[wordswithnemo]

On Sunday, May 28, 2017 at 10:41:33 PM UTC-4, cooloutac wrote:
> On Sunday, May 28, 2017 at 10:41:00 PM UTC-4, cooloutac wrote:
> > On Sunday, May 28, 2017 at 9:12:44 PM UTC-4, wordsw...@gmail.com wrote:
> > > I'm attempting to install on my new T470:
> > > 
> > > i7-7600U
> > > Intel HD Graphics 620
> > > 500GB HDD
> > > 
> > > Starting the installer, I get this error:
> > > 
> > > X startup failed, falling back to text mode
> > > 
> > > I'm assuming there is some graphics card issue, but I can't find any 
> > > reports of people working to solve installer problems with the Intel 620. 
> > > It seems to be just issues after installation.
> > > 
> > > I tried to install in text mode, but I got an error when autoparting the 
> > > disk (something to do with LUKS key) which seems to be universal and not 
> > > to have a solution.
> > > 
> > > I took the recommended steps for installing on a Lenovo with UEFI.
> > > 
> > > Any suggestions on the next step for troubleshooting?
> > 
> > so you mean it installs fine but then doesn't boot into desktop gui?
> > 
> > doublecheck bios settings and disable any other gpu.
> > 
> > Try to change kernel options from grub to add nomodeset. see if anything 
> > diff happens.
> 
> enable testing repo and install latest kernel.

No, the problem occurs during install. Are these steps I can take on the 
installer, or only once install is complete?

-- 
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/fb5fc09f-60c1-421b-a1ce-420a7fb6467c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Lenovo T470 - x startup failed

[wordswithnemo]

I'm attempting to install on my new T470:

i7-7600U
Intel HD Graphics 620
500GB HDD

Starting the installer, I get this error:

X startup failed, falling back to text mode

I'm assuming there is some graphics card issue, but I can't find any reports of 
people working to solve installer problems with the Intel 620. It seems to be 
just issues after installation.

I tried to install in text mode, but I got an error when autoparting the disk 
(something to do with LUKS key) which seems to be universal and not to have a 
solution.

I took the recommended steps for installing on a Lenovo with UEFI.

Any suggestions on the next step for troubleshooting?

-- 
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/14c385fe-9510-4f41-a042-520390c7eb46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to download and install Broadcom BCM43224 to Qubes

[wordswithnemo]

On Wednesday, May 10, 2017 at 12:27:45 PM UTC-4, Urfey wrote:
> When I try initial setup,Qubes always freeze at networking setup.
> 
>  So I didn't coufigure anything. Then I created sys-net and sys-firewall 
> manually. 
> 
> But when I started the VMs,it freezed again.
> 
> 
> 
> I guess because of my wireless device.My wireless device is Broadcom BCM43224.
> 
> 
> 
> So I want to install Broadcom BCM43224 firmware. But I don't know how I can 
> download and install to the firmware package to Qubes.
> 
> 
> 
> So could you teach me how to do it?
> 
> 
> 
> I created sys-net by Debian-based VM. 
> 
> 
> 
> thank you.

I came up against this same chip, and personally was not able to make it work. 
I purchased another, more linux-friendly chip that was compatible with my 
system.

Best of luck.

-- 
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/3abfa5cb-4afc-4b2f-b3cc-13cbc3696bc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QSB #30: Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)

[wordswithnemo]

On Tuesday, May 2, 2017 at 8:10:13 AM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes community,
> 
> We have just published Qubes Security Bulletin (QSB) #30:
> Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
> 
> The text of this QSB is reproduced below. This QSB and its accompanying
> signatures will always be available in the Qubes Security Pack 
> (qubes-secpack).
> 
> View QSB #30 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and read it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> ```
> 
> 
>  ---===[ Qubes Security Bulletin #30 ]===---
> 
>  May 2, 2017
> 
> 
> Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)
> 
> 
> Summary
> 
> 
> Today the Xen Security Team has disclosed two bugs related to PV memory
> handling affecting Qubes OS: XSA-213 [1] and XSA-214 [2].
> 
> An attacker who exploits either of these bugs can break Qubes-provided
> isolation. This means that if an attacker has already exploited another
> vulnerability, e.g. in a Web browser or networking or USB stack, then
> the attacker would be able to compromise a whole Qubes system.
> 
> Technical details
> ==
> 
> Xen Security Advisory XSA-213 [1]:
> 
> |   x86: 64bit PV guest breakout via pagetable use-after-mode-change
> |
> | 64-bit PV guests typically use separate (root) page tables for their
> | kernel and user modes. Hypercalls are accessible to guest kernel
> | context only, which certain hypercall handlers make assumptions on.
> | The IRET hypercall (replacing the identically name CPU instruction)
> | is used by guest kernels to transfer control from kernel mode to user
> | mode. If such an IRET hypercall is placed in the middle of a multicall
> | batch, subsequent operations invoked by the same multicall batch may
> | wrongly assume the guest to still be in kernel mode. If one or more of
> | these subsequent operations involve operations on page tables, they may
> | be using the wrong root page table, confusing internal accounting. As
> | a result the guest may gain writable access to some of its page tables.
> 
> 
> Xen Security Advisory XSA-214 [2]:
> 
> |   grant transfer allows PV guest to elevate privileges
> | 
> | The GNTTABOP_transfer operation allows one guest to transfer a page to
> | another guest.  The internal processing of this, however, does not
> | include zapping the previous type of the page being transferred.  This
> | makes it possible for a PV guest to transfer a page previously used as
> | part of a segment descriptor table to another guest while retaining the
> | "contains segment descriptors" property.
> | 
> | If the destination guest is a PV one of different bitness, it may gain
> | access to segment descriptors it is not normally allowed to have, like
> | 64-bit code segments in a 32-bit PV guest.
> | 
> | If the destination guest is a HVM one, that guest may freely alter the
> | page contents and then hand the page back to the same or another PV
> | guest.
> | 
> | In either case, if the destination PV guest then inserts that page into
> | one of its own descriptor tables, the page still having the designated
> | type results in validation of its contents being skipped.
> 
> The second bug requires cooperation between two VMs of different types,
> which somewhat limits its applicability.
> 
> The Xen Security Team also announced a third advisory today: XSA-215
> "possible memory corruption via failsafe callback"[3].
> 
> | Only x86 systems with physical memory extending to a configuration
> | dependent boundary (5Tb or 3.5Tb) may be affected.  Whether they are
> | actually affected depends on actual physical memory layout.
> 
> We believe this bug is extremely unlikely to affect any Qubes users due
> to the very high hardware requirements (5Tb or 3.5Tb of physical
> memory).
> 
> Patching
> =
> 
> Patched packages will be built and uploaded to the security-testing
> repository shortly after this advisory is published. We have recently
> implemented and published the details of a new, transparent build
> infrastructure. [4] In this new infrastructure, the source code for
> packages is pushed to a public repository, and logs from the build
> process are also publicly published. However, the Xen security policy
> does not permit us to make this data public until after the embargo has
> been lifted. [5] While we have already privately built and tested these
> packages, we must wait until the embargo has been lifted before
> transparently building the public packages using our new infrastructure.
> 
> The specific packages that resolve the problem discussed in this
> bulletin are as follows:
> 
>   For Qubes 3.2:
>   - Xen 

[qubes-users] Re-adding dom0 shortcuts to Start Menu

[wordswithnemo]

Not sure how, but I've randomly lost all my dom0 shortcuts, eg Logout, System 
Settings, Terminal. Possibly through running the Qubes Automated Build System 
or by attempting a dom0 update when there was none available.

How can I rebuild the menu, or manually re-add these shortcuts?

-- 
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/939fd521-9b07-4097-8b47-b54f550b390f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Issues with building debian-8-minimal in Qubes Automated Build System

[wordswithnemo]

On Tuesday, May 2, 2017 at 4:52:01 PM UTC-4, u+q...@bestemt.no wrote:
> wordswithn...@gmail.com  [2017-05-02 20:48 +0200]:
> > 'make install-deps' and manually attempting to install the dependencies 
> > confirms that they're all installed.
> 
> I got this error when I tried to build debian-8-minimal in
> fedora-25-minimal (I believe). Do you use fedora-23 as your build
> environment?
> 
> -- 
> ubestemt

I used fedora-25. Is fedora-23 preferred?

-- 
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/e9fad6c1-7c40-4132-af45-44d19cd8d26f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Issues with building debian-8-minimal in Qubes Automated Build System

[wordswithnemo]

I'm stuck partway through the process.

I'm following the directions here: 
https://www.qubes-os.org/doc/building-archlinux-template/

with substitutions for debian-8-minimal.

I've gotten through with minimal problems (had to manually create 
~/qubes-builder/keyring folders), but came across a major issue during the make:

[user@development qubes-builder]$ make qubes-vm
Currently installed dependencies:
git-2.9.3-3.fc25.x86_64
rpmdevtools-8.9-1.fc25.noarch
rpm-build-4.13.0.1-1.fc25.x86_64
createrepo-0.10.3-10.fc25.noarch
debootstrap-1.0.87-1.fc25.noarch
dpkg-dev-1.17.27-1.fc25.noarch
package python-sh is not installed
dialog-1.3-5.20160828.fc25.x86_64
dpkg-dev-1.17.27-1.fc25.noarch
debootstrap-1.0.87-1.fc25.noarch
ERROR: call 'make install-deps' to install missing dependencies
Makefile:199: recipe for target 'check-depend.rpm' failed
make: *** [check-depend.rpm] Error 1
[user@development qubes-builder]$

'make install-deps' and manually attempting to install the dependencies 
confirms that they're all installed.

There's another very random development: I've lost all of the dom0 shortcuts 
from the Qubes Start menu.

-- 
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/393d31b9-8107-47cc-95ee-b5b07790b22d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Mounting folder from one VM on another?

[wordswithnemo]

On Wednesday, April 26, 2017 at 5:13:52 PM UTC-4, wordsw...@gmail.com wrote:
> I'm looking for a solution similar to qvm-copy-to-vm, but without all the 
> copying.
> 
> I'd like to mount /home/user/foo from Secure appvm at /home/user/foo on 
> Personal appvm. The folder would be mounted as read only.
> 
> Rather than copy the files and waste space, I'd like to just have them 
> accessible.
> 
> Is this possible?

Never mind... this is done by mounting the image of the Secure appvm in the 
Personal appvm

In dom0:

qvm-block -A --ro Personal dom0:/var/lib/qubes/appvms/Secure/private.img
qvm-run -p Personal 'sudo mkdir /media/Secure'
qvm-run -p Personal 'sudo mount /dev/xvdi /media/Secure'

-- 
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/3bd0aaaf-9e82-48f6-9f4b-1da26841f2b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Mounting folder from one VM on another?

[wordswithnemo]

I'm looking for a solution similar to qvm-copy-to-vm, but without all the 
copying.

I'd like to mount /home/user/foo from Secure appvm at /home/user/foo on 
Personal appvm. The folder would be mounted as read only.

Rather than copy the files and waste space, I'd like to just have them 
accessible.

Is this possible?

-- 
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/4045dccf-036c-4993-b0af-69359e5292c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Lenovo s230u "Twist"

[wordswithnemo]

qubes-hcl-report document is attached.

Here are my notes:

* Required steps to address hardware issues before installation
** Option 1: Immediately replace Broadcom PCIe WIFI chip with Intel Centrino 
2230 (as explained below)
** Option 2: Remove Broadcom PCIe WIFI chip during installation
*** Qubes launches sys-net on boot (if setup during installation), and 
initiates the attached WIFI chip, causing an unrecoverable system freeze.
*** Disabling the WIFI chip in BIOS may also be a solution.
*** Once Qubes is installed, you may remove the WIFI device from sys-net and 
reinstall the hardware. You can troubleshoot this hardware by creating a 
sequestered NetVM (eg sys-net-broadcom) and using your ethernet connection in 
sys-net.

* Hardware changes I made
** Swapped out the original PCIe WIFI adapter (a Broadcom chip) which doesn't 
seem to be compatible - possibly with non-free firmware
** Replaced with an Intel Centrino 2230BNHMW
*** Only selected devices are compatible with the Lenovo motherboard whitelist.
*** Purchased here 
https://www.amazon.com/Intel-Centrino-Express-Bluetooth-2230BNHMW/dp/B009DAFJRM.
*** "FRU P/N: 04W3765" from the image references the Field Replacement Unit 
product number from Lenovo documentation. My chip did not arrive with that FRU 
indicated on the label, but it worked anyway.
*** No additional firmware required.
*** Downside is this chip does not work on 5Ghz bands. I have not yet tested 
bluetooth.
** Replaced HDD with SSD

* Outstanding security issues
** TPM is present but I have not enabled/tested it yet.

* Outstanding non-security issues
** Keyboard
*** The keyboard will "freeze" intermittently on a fresh (from power off) boot. 
If the keyboard freezes during FDE password input, or during user login you 
must restart the system and try again. Once you are past user login, the Power 
button fix below will help.
** Touchpad/nipple
*** Touchpad/nipple does not work on a fresh boot.
** Touchscreen
*** I have not been able to make the touchscreen work yet, but I'm optimistic. 
It does work on other distributions.

* Suggested approach for working around non-security issues
** As soon as possible after first boot, set the power button to activate 
Standby mode
*** Putting the system in Standby will "reset" the frozen keyboard.
** Use an external mouse instead of touchpad/nipple
*** This will allow for mouse movement when freshly booted.

* Alternative approach for working around non-security issues
** Always reboot your laptop immediately after login on a fresh boot, using the 
xfce "Log Out" menu
*** This will enable the touchpad/nipple and prevent the keyboard from 
freezing, once Qubes restarts.

-- 
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/dcf7800a-6328-4d8b-a30b-be7bc9878046%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-3347CTO-20170418-020125.yml
Description: Binary data