Re: [qubes-users] Qubes 3.1 and 3.2(rc2) video driver question

[mwbangert]

> Sorry to resurrect this thread. The link above doesn't really help (probably 
> because I'm a newbie and missing some solid background in linux and xen). 
> Here's the driver I'm trying to install - 
> https://01.org/linuxgraphics/downloads 
> (intel-linux-graphics-installer-1.4.0-23.intel20161.x86_64.rpm). So far I was 
> able to download it through one of the VMs, then copy to Dom0. It's missing a 
> dependency - libproxy-mozjs 0.4.10. I can download and copy it to Dom0, but 
> for some reason Dom0 doesn't even see the file, let alone install it. What am 
> I missing? I really need a decent video driver, the default one is only good 
> for terminal. 
>  Appreciate your help  Thank You

Sorry to resurrect the resurrection from before, I know how much everybody in 
this world loves necromancy-- however, I was having a similar problem with 
Intel integrated [HD Graphics 530] and solved the problem by creating an 
xorg.conf file in the /etc/X11 folder of dom0 containing the following:

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "sna"
   Option "TearFree" "true"
EndSection

I ended up needing to reboot the machine, but this could have been due to 
taking the server down and up with init... whatever the reason it needed to be 
rebooted.

As a note of caution, I am by no means a security guru or even really a power 
user of Qubes. Take anything I say with a grain of salt. It might work great 
for you, something might melt [or otherwise be rendered hideously insecure, 
though I don't readily see how].

Hope this helps!

-- 
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/98da26da-8b64-4e55-a67d-a77f5b0b682b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Detection - Best Way

[Asterysk]

It struck me that Qubes could be very useful for Detection of "malware" by 
placing a monitoring capability . My question is in two parts:

(1) Is Wireshark the best tool to use for this within Qubes
(2) Should it be placed in Dom 0 (if indeed thats possible) or in the sys-net 
or 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/34752164-f1de-4429-93d6-b07a38e589ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: All audio on streaming video out of sync

[raahelps]

On Friday, January 13, 2017 at 9:03:03 PM UTC-5, Gaijin wrote:
> All of the audio for videos played on my AppVMs, regardless of what 
> template it's based on (Fedora 24/Debian 8), or what browser I try 
> (Firefox/Chrome/Vivaldi), is completely out of sync. It's not just 
> YouTube, but Vimeo, self-hosted, etc.
> 
> I tried uncommenting audio_low_latency in /etc/qubes/quid.conf in dom0
> That didn't fix things.
> I tried playing with the realtime-priority in /etc/pulse/daemon.conf
> That didn't seem to make any difference.
> 
> Are there any other places where I could try to fix this latency issue? 
> I assume it's dom0 as everything is affected.

whats your pc specs/ what soundcard?

-- 
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/1c5619e2-90e5-4ab4-a682-36f18100b11b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Fw: Re: Problem: Convert to Trusted PDF Hangs

[raahelps]

On Saturday, January 14, 2017 at 9:03:15 AM UTC-5, Pushpins4u wrote:
> Forwarding to list.
> 
> 
> 
> 
> 
> copy the file to some other untrusted or disposablevm and see if it works 
> there.
> 
> 
> 
> That gave a clue.  Copying the untrusted PDF to my untrusted domain and 
> attempting the conversion there resulted in the same behavior.  However, 
> instead of receiving a "script hanging" error I received this message:
> 
> "Merging pages failed: convert: unable to extent pixel cache `No such file or 
> directory' @ fatal/cache.c/CacheSignalHandler/3394."
> 
> 
> 
> Each time after I received the OS pop-up message:
> 
> "Warning: insufficient memory to start disp"
> 
> 
> 
> And this error window:
> 
> "The remote party return invalid no of pages, aborting!"
> 
> 
> 
> -pp4u
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> 
> 
>  Original Message 
> 
> Subject: Re: Problem: Convert to Trusted PDF Hangs
> 
> Local Time: January 13, 2017 9:26 PM
> 
> UTC Time: January 13, 2017 9:26 PM
> 
> From: raah...@gmail.com
> 
> To: qubes-users 
> 
> pushp...@protonmail.com
> 
> 
> 
> On Friday, January 13, 2017 at 8:19:38 AM UTC-5, Pushpins4u wrote:
> 
> > Greetings,
> 
> > 
> 
> > 
> 
> > 
> 
> > I recently began downloading PDFs in an anon-whonix VM and wanted to 
> > sanitize them to move over to an offline VM attached to a storage USB.  
> > Weeks ago I was able to navigate to my downloaded PDFs in the anon-whonix 
> > Tor Browser folder, right-click, and convert the PDFs successfully.  
> > Copying them to my offline VM and attached USB drive worked fine.
> 
> > 
> 
> > 
> 
> > 
> 
> > When I try this process now, the PDF conversion progress window gets to 
> > like 95% full and then hangs.  I'm notified that a script appears to have 
> > hung and asked if it should be terminated.  This is happening consistently 
> > with the same PDF.
> 
> > 
> 
> > 
> 
> > 
> 
> > I'm up-to-date on my dom0.  Running on an HP EliteBook with i5 processor.
> 
> > 
> 
> > 
> 
> > 
> 
> > Ideas?
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks,
> 
> > 
> 
> > PP
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Sent with ProtonMail Secure Email.
> 
> 
> 
> copy the file to some other untrusted or disposablevm and see if it works 
> there.

well maybe someone who knows what those errors mean can chime in.   so only 
with the same pdf?  is it a very large file?  u sure you not running out of ram 
or space?  Are you using fedora or debian?  whats your pc specs?

-- 
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/8bb4d7e6-f3c8-4ab1-8357-802b8f360d5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Prob installing VLC in Fedora24 Template

[raahelps]

On Saturday, January 14, 2017 at 12:15:17 PM UTC-5, Arnulf Maria Bultmann wrote:
> > > did you try this?  You can remove cached packages by executing 'dnf clean 
> > > packages'
> > 
> > Yes I tried it several times with the same result
> 
> I solved my problem by downloading the rpm in a appvm and then copying it to 
> the template vm. But it should work in the template vm without work around. 
> Or?

ya weird.  not sure why,  did you make any changes to the template?

-- 
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/c8997baf-88e6-44b9-977a-cf8ec2705121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: AppVM unexpectedly changes kernel

[raahelps]

On Monday, January 16, 2017 at 11:57:30 AM UTC-5, Doug Hill wrote:
> Recently two appvms refused to start, reporting that:
> 
> VM: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.12-9/vmlinuz
> 
> Qubes Manager shows the kernel is set to 4.4.38-11.
> 
> Using 'qvm-prefs myappvm -s kernel 4.4.38.11' fixed the issue.
> 
> The appvm templates are debian-8 and whonix-ws based. Anything I should
> be concerned about here?
> 
> Thanks!

you can always just wipe the whole vm and recreate it to be on the safe side 
lol.

-- 
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/960e87e9-a30d-4c79-b6ea-e136a9f2646c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Accidental malware protection effect

[raahelps]

On Monday, January 16, 2017 at 2:38:40 PM UTC-5, Alex wrote:
> Has it ever been considered a feature the fact that all of the activity
> of a user in Qubes OS happens in a VM, from the point of view that a lot
> of malware has anti-debugging features that usually alter their
> behaviour when they detect they are run in a VM?
> 
> I don't have any statistic data for malware having such protections, and
> I believe that some anti-debugging features just compare hardware cpu
> timers to better discern an actual debugging session from a running VM
> (otherwise, this could prevent the malware from running on vps
> platforms). But it could be a nice side effect...
> 
> -- 
> Alex

probably,  I know some malware will do this if detects user running monitoring 
programs.

-- 
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/cb50900c-1ad1-4c16-9b2b-a03ee324bdec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: qubes-windows-tools installation failure

[raahelps]

On Tuesday, January 17, 2017 at 5:30:38 PM UTC-5, Hariharan Gopalan wrote:
> Hello Group
> 
> I am getting the following error while trying to install qubes-windows-tools:
> 
> [1848:184C][2017-01-17T22:22:27]i299: Plan complete, result: 0x0
> [1848:184C][2017-01-17T22:22:27]i300: Apply begin
> [1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to wait for 
> child to connect to pipe.
> [1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to connect to 
> elevated child process.
> [1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to actually 
> elevate.
> [1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to elevate.
> [1848:184C][2017-01-17T22:23:03]i399: Apply complete, result: 0x800700e8, 
> restart: None, ba requested restart:  No
> 
> I followed the instructions on the page:  
> https://www.qubes-os.org/doc/windows-appvms.
> 
> Thanks
> Hari

What windows version?

-- 
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/73effc12-413b-4b2c-bff1-33591e3b3a32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network hardware not recognized in Debian-based NetVM

['Joshua Bashir Gabriel' via qubes-users]

 Original Message 
Subject: Re: [qubes-users] Network hardware not recognized in Debian-based NetVM
Local Time: January 11, 2017 5:26 PM
UTC Time: January 11, 2017 10:26 PM
From: a...@qubes-os.org
To: Joshua Bashir Gabriel , 
qubes-users@googlegroups.com 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/11/17 14:18, 'Joshua Bashir Gabriel' via qubes-users wrote:
> Hello,
>
> Although the default NetVM in Qubes is based on Fedora, I wanted to
> be able to use NetworkManager 1.4.2 to automatically spoof my MAC
> address when connecting to networks. In order to do this, I
> followed the instructions here:
>
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>
> I created a new template for Debian 9 as instructed, then created a
> new NetVM from that template and added the Network Connections app
> to it, as well as my WiFi adapter (under the Devices tab).
>
> However, the Debian-based NetVM will not see the hardware. The
> Fedora-based NetVM can see it fine, but when I power that down and
> power up the Debian-based VM, no such luck.
>
> I am running Qubes 3.2 with all the latest updates applied. This
> email was sent from a Firefox session inside a disposable VM, so I
> know using the Fedora-based NetVM works. I also created additonal
> NetVMs based on Fedora, Debian 8, and Debian 9. The Debian-based
> NetVMs do not see my WiFi card. The Fedora-based NetVM does.
>
> Any advice would be very appreciated.
>
>
> Thanks, Bash
>

Perhaps you have the required drivers in your Fedora template but not
your Debian template. You may want to investigate whether they're
available in a Debian package.

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

iQIcBAEBCgAGBQJYdrEHAAoJENtN07w5UDAweZMP/jdYXuWNLHJ4oxdan5YOWimx
OltWijWNGkUjmA0D//hpSso8UAro8eBK2sWj0CcH0qlRi25gD7Dvpf4ufscd2X9S
O1kZ6ztq2rQKy8A87HWO/vTd5MR8Wu4meYOZtOJ7PHwkzZb/6x0v9QSoqwMDE5Xu
yAKpCV1LY5WdsFTlAi75vcPmiUKpmPcuCmhuD+2Y89Y83jEKJpAR0OxqVnEt/XQp
vorA5IIFvp7DN+mPnVloFS430JgEWCziM6WW1rMUvnXjU1sveVjtFFs+aU02BOPa
vRPOGDw7IzULN+NiZp3i1L/93dKkxEihoqm3ebwYSl0hGc9mxhyyRkDc6TP0NvxL
/oUe47FY3ieqgt95drE9icX2kNlF+46xkh42dSZuMU4/9FTaSqTDiE1OvEEhvzxq
qBPTwG+pRwRTmVqTZTE7PrYnQJX09hMj9BgleMwdt9NkJfh4A3NhNd8ZPYaImwDR
vlBPGqNLlsThvE12GJTpmE+Ct+93x5EmF7AcRNkpeJK51jN1GzqZ/pR0rGjjISBT
JNdtX9nfYbJCTLdL3T2RqF8F9fOY+OuMGY3DS5y0VR51kG88oQa0uKM+aA5ynAFJ
aa4TxYNHKA1tKzU7FFa6hD1EgR6/gGVMeqI32xDS3dFLcEhMH/oXoaTVcE5jtLX1
27Q0w19AY1LSWluGcrmF
=/OP4
-END PGP SIGNATURE-

Update: Got it working. It needed the wifi drivers for Debian 8/9, as well as a 
couple of other utilities, found here: https://wiki.debian.org/WiFi.

Also, I added the client for PrivateInternetAccess.com to the Net VM so I have 
a single netvm with always-on VPN.


Cheers,
Bash

-- 
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/GBA3VSFlt9Y7MCwnbvkNVQIi-Pht4sSrWpwFQ8WE_XRpt1nblToF1Ghv5KANWZx485UC32q54JpgJURRD06p6kWBJdwVLsIZgdJX1ml8ccs%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qubes-windows-tools installation failure

[Hariharan Gopalan]

Hello Group

I am getting the following error while trying to install qubes-windows-tools:

[1848:184C][2017-01-17T22:22:27]i299: Plan complete, result: 0x0
[1848:184C][2017-01-17T22:22:27]i300: Apply begin
[1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to wait for 
child to connect to pipe.
[1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to connect to 
elevated child process.
[1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to actually 
elevate.
[1848:184C][2017-01-17T22:23:02]e000: Error 0x800700e8: Failed to elevate.
[1848:184C][2017-01-17T22:23:03]i399: Apply complete, result: 0x800700e8, 
restart: None, ba requested restart:  No

I followed the instructions on the page:  
https://www.qubes-os.org/doc/windows-appvms.

Thanks
Hari

-- 
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/0b11a681-63e3-4aa0-9fc2-0800170f253f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to install Qubes : Black Screen - reboot - several EFI parameters tested w/ success

[iamnotanumber666]

Thanks answering.
I'll try with Refind, and let you know.
But as speaking of my issue someone told me too that my p may be too old for 
that (no VT-d afaik), anyway i'll check the cpu and MB specs.

-- 
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/834971ff-edd0-4ded-ba81-3767722417af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: kali failing to start as a HVM (bootable iso)

[cubit]

17. Jan 2017 00:31 by spfmcgu...@gmail.com:

> What steps did you do before this step? Did you create the HVM using 
> qvm-create?
>
> Have you referenced the Docs page for setting up Kali? 
> https://www.qubes-os.org/doc/pentesting/kali




I followed https://www.qubes-os.org/doc/pentesting/kali/#hvm




With step 2 being done through Qubes VM manager (VM > Create VM)


Name: kali

color: red

HVM: standalone

Allow networking: sys-firewal




Then on to step 3 which gives the error as last email














 

-- 
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/KahqK3l--3-0%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows HVM and two monitors (dual head - dual headache ;-) ). Help appreciated.

[daltong defourne]

On Tuesday, January 17, 2017 at 7:32:08 PM UTC+3, Opal Raava wrote:
> On Tuesday, January 17, 2017 at 10:23:15 AM UTC+1, daltong defourne wrote:
> > Well, first, the good thing:
> > Dual head windows HVM booted without issue.
> > 
> > (Qubes proper is also working with the second monitor and extending the 
> > qubes desktop to it, all fine)
> > 
> > Now, the bad thing - apparently, enabling "extend desktop to this monitor" 
> > in windows does literally nothing (seamless GUI disabled)
> > 
> > The second monitor still shows qubes desktop wallpaper.
> > 
> > Going fullscreen does nothing (windows VM occupies first screen allright, 
> > second screen remains "qubes wallpaper")
> > 
> > So far I am working around the following manner:
> > I disable second monitor in windows, then make windows VM's window "snap" 
> > to minimum size by dragging it upwards, then extend it so it covers both 
> > monitors in "qubes view"
> > 
> > Then I manage my windows in Windows (pardon the pun) with winsplit 
> > revolution (The only window splitter thingie that worked okay in Qubes VM 
> > for me)
> > 
> > What I'd like is capability for non-seamless windows VM to go into "full 
> > full" screen and occupy both monitors while doing so (in order not to waste 
> > any "pixel estate" to window borders and panel and such)
> 
> I dont know much about this topic as I dont have a dual screen. 
> 
> What I do know is that 'full full' screens are not really something you would 
> want. A malicous software could grab that 'full full' screen and start asking 
> for sensitive information. 
> 
> I also had an issue with 'full full' screen and then using RDP (that's what I 
> use windows for anyway) and then not being able to regain control into my 
> dom0 window manager, because something crashed or got stuck I was actually 
> forced to reboot my machine.
> I ended up using windows non-seamless, as a 'qubes-normal full screen' on my 
> very last xfce desktop. thats where my windows lives and I'm happy with that 
> setup. 
> 
> Your situation is different, but this is just my two cents on how it works 
> best for me.

I know that and do bear that in mind. Having said that, my windows HVM has no 
internet connection and if my Photoshop/Coreldraw/Excel/Word asks me for 
sensitive information, I'll be wary :)

-- 
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/71d5519e-476f-459f-b172-5a66d1d7851e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kali VM is unusable

[adonis28850]

On Tuesday, January 17, 2017 at 12:17:32 PM UTC-5, J. Eppler wrote:
> Hello,
> 
> try the following:
> 
> 1) select the VM you want to upgrade in Qubes OS manager
> 2) do a right click and select VM settings
> 3) switch to the Firewall rules tab
> 4) enable allow full access for x minutes
> 
> try to upgrade again.

I could swear I did try that, but I'll do it again when I get home later on and 
let you know how it goes.

It is very strange, cause VMs (including templates) update without any issue 
when doing it through the GUI (Right click -> Update 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/e5e98482-faa3-4201-b321-f8e59fbddce4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Archlinux Community Template Qubes OS 3.2

[J. Eppler]

Hello,

I have the same issue.



-- 
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/738757e8-5ba7-49eb-b655-bf258130cf8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows HVM and two monitors (dual head - dual headache ;-) ). Help appreciated.

[Opal Raava]

On Tuesday, January 17, 2017 at 10:23:15 AM UTC+1, daltong defourne wrote:
> Well, first, the good thing:
> Dual head windows HVM booted without issue.
> 
> (Qubes proper is also working with the second monitor and extending the qubes 
> desktop to it, all fine)
> 
> Now, the bad thing - apparently, enabling "extend desktop to this monitor" in 
> windows does literally nothing (seamless GUI disabled)
> 
> The second monitor still shows qubes desktop wallpaper.
> 
> Going fullscreen does nothing (windows VM occupies first screen allright, 
> second screen remains "qubes wallpaper")
> 
> So far I am working around the following manner:
> I disable second monitor in windows, then make windows VM's window "snap" to 
> minimum size by dragging it upwards, then extend it so it covers both 
> monitors in "qubes view"
> 
> Then I manage my windows in Windows (pardon the pun) with winsplit revolution 
> (The only window splitter thingie that worked okay in Qubes VM for me)
> 
> What I'd like is capability for non-seamless windows VM to go into "full 
> full" screen and occupy both monitors while doing so (in order not to waste 
> any "pixel estate" to window borders and panel and such)

I dont know much about this topic as I dont have a dual screen. 

What I do know is that 'full full' screens are not really something you would 
want. A malicous software could grab that 'full full' screen and start asking 
for sensitive information. 

I also had an issue with 'full full' screen and then using RDP (that's what I 
use windows for anyway) and then not being able to regain control into my dom0 
window manager, because something crashed or got stuck I was actually forced to 
reboot my machine.
I ended up using windows non-seamless, as a 'qubes-normal full screen' on my 
very last xfce desktop. thats where my windows lives and I'm happy with that 
setup. 

Your situation is different, but this is just my two cents on how it works best 
for me.

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

Re: [qubes-users] a few things about salt

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jan 17, 2017 at 04:40:24PM +0100, john.david.r.smith wrote:
> > > 6)
> > > currently i really don't like the way the configuration works.
> > > i have a top file where i execute some states for dom0
> > > these states create and configure my vms.
> > > then in some top files i choose some vms and configure them again (but 
> > > this
> > > time it is some config i am doing in the domu).
> > > 
> > > so it kind of looks like this:
> > > top.top
> > > -
> > > base:
> > >   dom0:
> > > - create-cfg-vm1
> > >   vm1:
> > > - some-cfg-in-domu
> > > 
> > > 
> > > now i have two layers of configuration (in top and sls).
> > > for some config stuff i have to change a sls and for other i have to 
> > > change
> > > the top
> > > is there a plan to change this?
> > > 
> > > e.g. some kind of virtual minions?
> > > 
> > > i would like to write something like this:
> > > top.top
> > > -
> > > base:
> > >   dom0:
> > > - copy-sequence.Strg-Alt-Shift-C
> > >   vm1:
> > > - create#this affects dom0
> > > - color.red #this affects dom0
> > > - netvm.sys-tor #this affects dom0
> > > - mail  #this affects domU
> > > 
> > > then i could see all my domU config in the top file.
> > > 
> > > i currently hacked something but this only works in a sls file and for 
> > > dom0
> > > config (but has this style of syntax)
> > > 
> > > i am currently looking whether i can do the same in a top file (but i 
> > > doubt
> > > it, since there is no templating in top files)
> > 
> > And the last sentence is exactly the reason why it's tricky to have it
> > in one place. Rendering sls files (may) require getting data (grains) from
> > target system and we don't want to parse that data from VM in dom0.
> > To limit attack surface. So, we can't render sls for VMs in dom0, we
> > need to decide what goes where at 'top' files level.
> > 
> > I think the only think that can be improved here, is some "automatic"
> > creation of VMs mentioned in top file - something like you've described
> > above. But it's tricky to do it, while keeping flexibility of salt...
> > Using valid salt syntax like yours, to achieve different effect looks
> > like asking for troubles. If going that way, IMO it would be better to
> > have something that isn't valid salt syntax here and have a pre-processor
> > script to create actual salt configuration.
> 
> i am currently working at something like this:
> i have a top file activating a dom0 sls
> in this sls i do dom0 config, create vms and configure them (dom0 config AND
> domU config).
> all domU config is used to generate a generated.top file activating the
> correct states for the correct minions.
> 
> then everything is in one file (not the top file, but this sls file has the
> function of a top file)
> the disadvantage would be that i always need to run dom0 to generate up to
> date files for my minions. (but in my opinion the advantages beat the
> disadvantages)

This should work as long as you don't need to render anything in domU
sls files (like {{ grains['os'] }}). Otherwise salt will render that
using dom0 data, not domU data. Unless you use some escaping...

> > > how is the order of execution?
> > > will dom0 always be executed before any domU is started?
> > 
> > Yes. In particular you can create VMs using states for dom0, just to
> > have them configured a moment later using states for VM.
> > 
> > > when are the files for domU read?
> > > after dom0 is configured? (then i could write state files during dom0
> > > configuration)
> > 
> > Yes, those files are loaded just before configuring VM.
> 
> i noticed that, but it could have been possible you do something like this
> (maybe because salt does things like this):
> a) copy all files to some cache
> b) run dom0 (using the files from the cache)
> c) run domU (using the files from the cache)
> 
> in this case i would not be able to generate files in b to use in c

But that's not the case :)

> > > 8)
> > > is there some way to execute some dom0 scripts after configuration of 
> > > domu?
> > > (e.g. trim-template)
> > 
> > Currently no.
> 
> do you plan to add something like this?

We don't have such plans, but will accept a patch for this ;)
 
> > > there probably are files in the management vm, but this vm gets deleted.
> > > is there an option to stop the deletion of the management vm?
> > 
> > There is no option for that, but you can suspend qubesctl execution
> > (Ctrl-Z) to prevent that. You need to do that when you see that target
> > VM is being starting (at this moment dom0 have already send all required
> > data and all the execution is in management VM).
> > 
> > The above I've debugged exactly this way:
> > 1. Ctrl-Z on qubesctl.
> > 2. Open terminal in disp-mgmt-fedora-24-minimal.
> > 3. Look at /etc/qubes-rpc/qubes.SaltLinuxVM - this is what is executed.
> > 4. Get the last two lines and execute them, fix problems, repeat.

Re: [qubes-users] a few things about salt

[john.david.r.smith]

1)
even when some states fail for some vm, the cli tool displays ok. it would
be better, if it displayed error in case of an error (some errors are
displayed).


Can you provide example error which wasn't detected? Regardless of the
result, output is logged to /var/log/qubes/mgmt-*.log in dom0.



i somehow fail to reproduce the case. (i just noticed it when playing 
around with salt)
there were some states failed inside domu (i think some package 
installation)

i will try to reproduce it later.


5)
are there plans to add some functionality to the interface?


Yes, "qvm" module will be extended for new features in Qubes 4.0. Is it
what you've asked about?


yeah. the question was just about any planned additions.


I think there is currently no sane way to setup global defaults (other
than cmd.run: qubes-prefs ...). So, we'll work on that too.


nice


6)
currently i really don't like the way the configuration works.
i have a top file where i execute some states for dom0
these states create and configure my vms.
then in some top files i choose some vms and configure them again (but this
time it is some config i am doing in the domu).

so it kind of looks like this:
top.top
-
base:
  dom0:
- create-cfg-vm1
  vm1:
- some-cfg-in-domu


now i have two layers of configuration (in top and sls).
for some config stuff i have to change a sls and for other i have to change
the top
is there a plan to change this?

e.g. some kind of virtual minions?

i would like to write something like this:
top.top
-
base:
  dom0:
- copy-sequence.Strg-Alt-Shift-C
  vm1:
- create#this affects dom0
- color.red #this affects dom0
- netvm.sys-tor #this affects dom0
- mail  #this affects domU

then i could see all my domU config in the top file.

i currently hacked something but this only works in a sls file and for dom0
config (but has this style of syntax)

i am currently looking whether i can do the same in a top file (but i doubt
it, since there is no templating in top files)


And the last sentence is exactly the reason why it's tricky to have it
in one place. Rendering sls files (may) require getting data (grains) from
target system and we don't want to parse that data from VM in dom0.
To limit attack surface. So, we can't render sls for VMs in dom0, we
need to decide what goes where at 'top' files level.

I think the only think that can be improved here, is some "automatic"
creation of VMs mentioned in top file - something like you've described
above. But it's tricky to do it, while keeping flexibility of salt...
Using valid salt syntax like yours, to achieve different effect looks
like asking for troubles. If going that way, IMO it would be better to
have something that isn't valid salt syntax here and have a pre-processor
script to create actual salt configuration.


i am currently working at something like this:
i have a top file activating a dom0 sls
in this sls i do dom0 config, create vms and configure them (dom0 config 
AND domU config).
all domU config is used to generate a generated.top file activating the 
correct states for the correct minions.


then everything is in one file (not the top file, but this sls file has 
the function of a top file)
the disadvantage would be that i always need to run dom0 to generate up 
to date files for my minions. (but in my opinion the advantages beat the 
disadvantages)




how is the order of execution?
will dom0 always be executed before any domU is started?


Yes. In particular you can create VMs using states for dom0, just to
have them configured a moment later using states for VM.


when are the files for domU read?
after dom0 is configured? (then i could write state files during dom0
configuration)


Yes, those files are loaded just before configuring VM.


i noticed that, but it could have been possible you do something like 
this (maybe because salt does things like this):

a) copy all files to some cache
b) run dom0 (using the files from the cache)
c) run domU (using the files from the cache)

in this case i would not be able to generate files in b to use in c


8)
is there some way to execute some dom0 scripts after configuration of domu?
(e.g. trim-template)


Currently no.


do you plan to add something like this?


9)
the fedora-24-min template can't really be configured with salt.
there is the package file missing.
after i installed the package i still got an error: "Target 'fedora-24-min'
did not return any data, probably due to an error. exit code 20"


The important thing is what is your default template - it is used for
that intermediate VM from where target VMs are configured. Is it also
fedora-24-min?
salt-ssh requirements in the target VM are really minimal - I think any
shell + python should be enough. For me it works, but it's possible that
my minimal template is no longer such minimal...
Ok, tried on fresh minimal template and found the problem: sudo
So, packages needs to be installed:
 - file
 

Re: [qubes-users] New Lenovo laptops: X1 (4th Gen), T460/p, and T560

[steve . pantony]

On Saturday, January 14, 2017 at 3:26:04 PM UTC+4, qmast...@gmail.com wrote:
> 26 December 2016 г., 18:00:43 UTC-5 tai...@gmx.com написал:
> > Lenovo is a shitty company if you care about security, they have stuck 
> > irremovable rootkits their BIOS 4 separate times and they are partially 
> > owned by the PRC government
> 
> Having a PRC backdoor is better than NSA one! (most laptop companies are 
> American, so...) By the way, why not to get a Lenovo G505S laptop?
> 1) It is the latest AMD-based laptop which is supported by coreboot open 
> source BIOS (so no closed source BIOS backdoors), and it does not have Intel 
> ME backdoor. G505S's APUs are Richland - the last generation before AMD 
> started to embed their own version of Intel ME, "AMD Security Processor" or 
> PSP ( 
> http://www.extremetech.com/wp-content/uploads/2013/11/AMDRoadmap-Mobility.png 
> ) Although a closed source vga blob is still required for working graphics, 
> luckily a coreboot's YABEL prevents the possible undocumented accesses of vga 
> blob to other PCI devices
> 2) Supported by Qubes 3.2 - see HCL, 
> https://groups.google.com/d/msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ . Most 
> likely to be supported by Qubes 4.0 ( HVM=y, IOMMU=y, SLAT=y) and seems to 
> meet its certification criteria so far - 
> https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ <-- 
> webcam could be covered, speakers and wireless card are not soldered and 
> could be removed, and just checked the last concerning thing - embedded 
> microphone is a PCI device, not USB connected ;) 
> 3) High end version of G505S has a top of the Richland generation A10-5750M 
> APU, 3352 score at Passmark cpu-benchmark. If to compare with i5-6200U of 
> Lenovo T460s, 3933 score - 17% faster. But i5-6200U is dual core, while 
> A10-5750M is quad core. Also, despite being three years older, A10-5750M 
> integrated graphics is faster than of i5-6200U. According to Passmark: Intel 
> HD 520 - 844 G3D score, AMD HD 8650G - 950 G3D score, 13% faster.
> 3) In contrast with many modern laptops, G505S has two slots for RAM (instead 
> of one) and its RAM is not soldered. That means: when your RAM fails a 
> memtest after some years, instead of paying a fortune for the RAM chips 
> replacement you could just remove RAM and install a new one. Also you could 
> easily upgrade to 16 GB RAM (2x8GB), which helps not to think of RAM usage 
> while using Qubes (currently running 14 VMs at the same time, with a lot of 
> applications started, and they eat just 13 GB out of 16 GB)
> 4) G505S has either integrated or both integrated and discrete graphics 
> (depends on G505S version). In any case, it is AMD only - which has great 
> open source drivers for Linux. No need for NVIDIA closed source proprietary 
> drivers with telemetry...
> 5) Almost all the components could be replaced by user, even a CPU is not 
> soldered. Easy to tear down a laptop and assemble it back. Thanks to open 
> source BIOS, no WiFi card whitelist, so possible to install any wireless card 
> which has open source drivers for Linux (such as AR9462)
> Currently it is almost impossible to buy a new G505S, but the used ones are 
> selling for cheap (e.g. 3 auctions currently at eBay for G505S version with 
> A10-5750M APU, 1 UK and 2 US-based, one of them with buy it now price $250 - 
> half of the original $500)

I have an old G505 kicking around somewhere, will give it a go with Qubes 3.2 
and then try Coreboot. Thanks for the reminder ! Wonder if this means I can get 
the KDE Desktop Cube animation to work. 

-- 
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/f4c06106-90b7-48eb-bf16-a4c758faaa78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DispVM does not work anymore

[Robert Mittendorf]

> I suspect you too may be suffering
> https://github.com/QubesOS/qubes-issues/issues/2182
>
> Look at /var/log/libvirt/libxl/libxl-driver.log and see if there is a
> line like 
>  xc: error: X86_PV_VCPU_MSRS record truncated: length 8, min 9: Internal
> error
>
> The reason that directly booting the dvn works is that the problem lies
> in restoring the savefile (and the buggy creation of it).
>
> There are some patches fixing it, but you would need to recompile xen :/
/var/log/libvirt/libxl
(dom0) contains only 2 empty folders ("dump" and "save")

raahelps suggestion to recreate the dvm worked

-- 
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/44233a6b-dadc-8766-8916-63cc9da62ba3%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installation Problems; Qubes 3.2

[qmastery16]

вторник, 4 октября 2016 г., 22:10:17 UTC+3 пользователь habib.b...@gmail.com 
написал:
> I have a brand new Lenovo t450s I just bought for the purpose of installing 
> qubes onto it and I have thoroughly followed all the instructions
> 
> Iam using a USB device which I used Rufus to instal the ISO image in DD mode 
> and then I went into xen.cfg and did exactly as instructions stated to add 
> 
> mapbs=1
> noexitboot=1
> 
> To each kernel but it keeps getting stuck in boot loop
> 
> Someone please help
> Thanks

You could try installing Qubes 3.1 and then upgrading it to Qubes 3.2
Yes, it is time consuming and not really a solution, but maybe it could help to 
clarify what is wrong

-- 
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/cd6a2e3a-d091-4cad-995f-95e08eac7a9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New Lenovo laptops: X1 (4th Gen), T460/p, and T560

[sboresch]

Hi,

delayed thanks for your feedback. I guess this should work, and one could
probably replace the kernel rpms (to be installed) with the newer ones, but the 
hurdle for me was to get a valid iso image back to the usb stick .. [I assume 
this is simple, provided one knows how to ..]

Anyways, time for the screwdriver .. and I can confirm that installing
vanilla qubes 3.2 on a supported laptop and upgrading the kernel to 4.8.x (from
the unstable repo) resulted in a (mostly) working system.

The first boot in the target hardware led to several failures of service VMs not
starting, as the wrong PCI devices had been passed through to them. 
Fortunately, some qvm-pci commands and a reboot later, this was resolved.

At present, I have working graphics, Ethernet and WIFI. Sound is
working as well. After waking up from
sleep, the network is gone, but I am optimistic that this can be sorted out.
(Had this problem in the past ..)

I will report for the HCL when this is really up and running.

For future reference, it would be great though if there were a howto for making
an updated install usb / image ...

Thanks,

Stefan
 

Am Freitag, 13. Januar 2017 00:43:14 UTC+1 schrieb Ángel:
> sbore...@gmail.com wrote:
> > Thus, is there a (documented) way to add a newer kernel to the 3.2 install 
> > image? I'd rather avoid taking the SSD out and install qubes in my older
> > machine.
> > 
> > Thanks in advance,
> > 
> > Stefan
> 
> For booting the install or for being installed?
> 
> I expect that changing the kernel being used during the install should
> be as simple as replacing the isolinux/vmlinuz* / EFI/BOOT/vmlinuz plus
> initrd in the install media.
> 
> Changing the kernel that is getting installed may be harder, although it
> can surely be inserted into Packages/ but anyway you could drop the
> right file into the boot partition just until you get to install it
> correctly.
> 
> Make sure you only replace them with a trusted binary, though.

-- 
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/a4712db1-97cc-477a-97bd-d6edce4ff624%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kali VM is unusable

[J. Eppler]

Hello,

the better way is to create Kali template or standalone VM. Here is the guide:
https://www.qubes-os.org/doc/pentesting/kali/

the advantage it integrates better into Qubes. The disadvantage you will not be 
able to use the normal 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/2bd33406-6cf2-4074-9403-a96d3145878b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Solving the IME Problem with Virtualization

[john . mayorga]

I'm not a Xen expert, so don't flog me too harshly, and I did search the posts 
for this subject, but couldn't find it.

There is a painfully well known problem of having to "trust" Intel to properly 
implement their "Intel Management Engine". Only very recently has there been a 
hardware solution to fixing that problem on more recent chipsets, however, I 
have not heard much from the Qubes community on this point. Reference: 
http://hackaday.com/2016/11/28/neutralizing-intels-management-engine/

Xen is capable of booting a VM with its own BIOS. Why would it not be possible, 
for extreme privacy cases, to Xen virtualize Qubes (nested VMs) such that IME 
does not matter, as IME would only affect Xen on the hardware, not the VM with 
the open source BIOS which is running Qubes. Reference: 
https://wiki.xenproject.org/wiki/Hvmloader

I realize this is hardly efficient, but, if it would work, it would eliminate 
having to "trust" Intel.

...or, what, would the Intel hardware still be able to peek into the the 
hardware, even though the hardware, the Xen VM with Qubes in it, and the Qubes 
VMs are all running VT-x and VT-d?

Thanks,

John E. Mayorga

-- 
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/7021fc83-ace4-4d63-b98b-7a46ca6167a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Windows HVM and two monitors (dual head - dual headache ;-) ). Help appreciated.

[daltong defourne]

Well, first, the good thing:
Dual head windows HVM booted without issue.

(Qubes proper is also working with the second monitor and extending the qubes 
desktop to it, all fine)

Now, the bad thing - apparently, enabling "extend desktop to this monitor" in 
windows does literally nothing (seamless GUI disabled)

The second monitor still shows qubes desktop wallpaper.

Going fullscreen does nothing (windows VM occupies first screen allright, 
second screen remains "qubes wallpaper")

So far I am working around the following manner:
I disable second monitor in windows, then make windows VM's window "snap" to 
minimum size by dragging it upwards, then extend it so it covers both monitors 
in "qubes view"

Then I manage my windows in Windows (pardon the pun) with winsplit revolution 
(The only window splitter thingie that worked okay in Qubes VM for me)

What I'd like is capability for non-seamless windows VM to go into "full full" 
screen and occupy both monitors while doing so (in order not to waste any 
"pixel estate" to window borders and panel and such) 

-- 
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/1bdc8625-7823-4d75-a6f3-8c492c02938f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.