Re: [qubes-users] Can't connect a VPN before Tor

[3n7r0py1]

On Tuesday, September 13, 2016 at 11:56:53 PM UTC, nishi...@gmail.com wrote:
> Le samedi 10 septembre 2016 20:36:38 UTC+2, 3n7r...@gmail.com a écrit :
> > [First, a rant. I hate mailing lists. How am I supposed to attribute quotes 
> > from earlier posts in the thread not contained in the previous post?]
> > 
> > nishi:
> > >Any advices on how to set up Qubes to have a VPN + sys-whonix working 
> > >together (or VPN + a TorVM proxy) in a good anonymous way would be really 
> > >appreciated :)
> > 
> > As you know, you can either connect to a VPN from a non-Whonix proxyVM or 
> > set up the VPN directly in the Whonix-Gateway. Both methods have the goal 
> > of preventing "unintentional" leaks and have the property of 
> > failing-closed. IMO, since you are using Qubes already, the proxyVM method 
> > is easier to configure and provides more flexibility. If you're short on 
> > RAM and/or need to operate multiple Whonix-Gateways with each having a 
> > separate VPN, you may be better off connecting to the VPN from within the 
> > Gateway. From a security/anonymity perspective, neither is obviously better 
> > than the other. A Gateway compromise would most likely be game-over in 
> > either scenario.
> > 
> > Speaking generally, you've got a whole bunch of moving parts. You need to 
> > troubleshoot by isolating each piece. 
> > 
> > **This step reveals that you use Tor. Only proceed if safe to do so.
> > 
> > 1. sys-net <- appVM: Do I have general connectivity?
> > 2. sys-net <- vpn-VM <- appVM: Does my VPN work?
> > 3.** sys-net <- appVM w/ Tor Browser Bundle: Does Tor work?
> > 4.** sys-net <- whonix-gateway: Run whonixcheck. Does Whonix-Gateway work?
> > 5. sys-net <- vpn-vm <- whonix-gateway
> > 
> > My suggestion is to start with a fresh proxyVM and follow Chris' Qubes VPN 
> > documentation step by step. (Or take a look at his [git 
> > repo](https://github.com/ttasket/Qubes-vpn-support) ). If the vpn-VM allows 
> > successful connections from the appVM, then it's simply a matter of 
> > assigning it to the Whonix-Gateway as its netVM. No Whonix-specific 
> > configuration is necessary since it's all transparent to Whonix.
> > 
> > * Make sure that the Qubes firewall (Qubes VM Manager) is open on the 
> > Whonix-Gateway. I don't remember what the default setting is.
> > 
> > * Both TCP and UDP are fine for upstream VPNs. Tor can not carry UDP but it 
> > can be carried on UDP, if that makes sense.
> > 
> > * Don't add any additional firewalls until you can get this working.
> > 
> > 
> > nishi:
> > >Which gives in Qubes something a pattern like this one below (I don't know 
> > >if all firewall VMs are really needed though) :
> > >
> > >AppVM => sys-vpn-firewall => sys-vpn => sys-whonix-firewall (or 
> > >TorVM-firewall) => sys-whonix (or TorVM) => sys-firewall => sys-net
> > 
> > Firewalls have limited usefulness as described here: 
> > https://www.qubes-os.org/doc/data-leaks/
> > 
> > rustybird's Corridor can ensure that all traffic goes to a Tor Entry Guard 
> > (but obviously, can't guarantee that the Entry Guard is trustworthy).
> > 
> > 
> > nishi:
> > >When I purchased a VPN subscription, I saw it as a way to improve 
> > >anonymity, now I feel it is more a tool to provide security.
> > 
> > VPNs don't necessarily improve anonymity OR security. They simply shift the 
> > trust that you place in your ISP to someone else. That may be good or bad.
> > 
> > 
> > Chris:
> > >Although its straightforward to get the opposite working (Tor -> VPN ->
> > Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
> > vpn vm)
> > 
> > Just to clarify, to achieve user -> Tor -> VPN -> Internet, sys-whonix 
> > needs to be connected as the *netVM* for the vpn-vm. If vpn-vm is the netVM 
> > for sys-whonix, the resulting traffic is user -> VPN -> Tor -> Internet. I 
> > may be forgetting something, but I believe both configurations work out of 
> > the box.
> 
> Hello,
> 
> Thank you for your answer. Yes I agree with you, the proxyVM is easier to 
> configure and provide more flexibility. I don't know if you can make your VPN 
> autostart if you install it inside the whonix gateway, so I rather prefer to 
> have it directly installed in an AppVM, because I find it is a great Qubes 
> feature : )
> 
> Also as I said directly in the Whonix-forum site, I don't believe building a 
> fortress in a gateway that will become the main target for hackers is what 
> will necessarily will make us all more secure out there. Whonix or Qubes are 
> targets right now... You have too many hacking intrusion exploits nowadays to 
> build a fail-safe system for everyone. If you just type list in metasploit on 
> kali Linux you know what I mean... I feel like people working on Whonix would 
> be a really more usefull to random noobs like me and most of the internet 
> community by trying to act like hackers, idea being to create a code able to 
> send back nukes to people entering your own private space. I see 

[qubes-users] Re: Is there any way to mount a Qubes volume from an external drive..?

[Drew White]

On Wednesday, 14 September 2016 11:33:44 UTC+10, neilh...@gmail.com  wrote:
> I have an external HDD with a Qubes installation on it, i.e Qubes installed 
> direct to an external HDD.
> 
> I want to be able to get the data from it, but my laptop won't boot up the 
> drive for some reason. Maybe it's a problem with my laptop, but either way, I 
> can't seem to get it to boot.
> 
> However, when I plug in the HDD, I can see that the files are very much still 
> on it... It has the EFI folder, and the main Qubes encrypted drive on there.
> 
> So, is there any way of mounting this HDD in Qubes..?
> 
> I have Qubes running now, but it's installed on the local disk.
> 
> I want to mount a Qubes installation from an external HDD.
> 
> Thanks

Just plug it in, and it recognises (depending on version of Qubes.

Could you please notify the versions?

-- 
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/1acb5341-5f86-450e-8de5-eb03d4ded794%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: 3.2-rc3 is awesome...but where is NetworkManager?

[Drew White]

On Wednesday, 14 September 2016 07:55:24 UTC+10, georgew...@gmail.com  wrote:
> I just installed 3.2-rc3 on a Thinkpad T460s and it's great...but the 
> NetworkManager widget is gone.  Is there a way to get that or something 
> equivalent on the XFCE panel?  I've tried launching NetworkManager from the 
> terminal and that didn't work.  
> 
> nmcli works fine for configuring WiFi, and I get notifications about network 
> changes in the top-right corner of the screen, but still no GUI widget.

On Panel, place Notification Area, and in the Guest make sure you have under 
Services either "network-manager" or "NetworkManager", otherwise it won't show 
up.

-- 
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/6b6c1780-24dd-4c00-a71c-617502f8d915%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Is there any way to mount a Qubes volume from an external drive..?

[neilhardley]

I have an external HDD with a Qubes installation on it, i.e Qubes installed 
direct to an external HDD.

I want to be able to get the data from it, but my laptop won't boot up the 
drive for some reason. Maybe it's a problem with my laptop, but either way, I 
can't seem to get it to boot.

However, when I plug in the HDD, I can see that the files are very much still 
on it... It has the EFI folder, and the main Qubes encrypted drive on there.

So, is there any way of mounting this HDD in Qubes..?

I have Qubes running now, but it's installed on the local disk.

I want to mount a Qubes installation from an external HDD.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6c606b47-bdc1-4c13-8e28-1ae6b71b0ee0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Display problems with VT-D enabled [ T410 (2537P81) ]

[Boris Kourtoukov]

On Sunday, November 8, 2015 at 4:13:30 PM UTC-5, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, Nov 08, 2015 at 12:57:14PM -0800, Boris Kourtoukov wrote:
> > Does this just mean that the VT-d implementation is broken on this hardware 
> > and I should grab something else?
> 
> This is one possibility (slightly more likely). The other one is buggy driver.
> 
> 
> > Thanks 
> > 
> > On Wednesday, October 28, 2015 at 10:54:03 PM UTC-4, Boris Kourtoukov wrote:
> > >
> > > This issue was described but not followed up on from this topic: 
> > > https://groups.google.com/d/topic/qubes-users/WsHQ_GqXdT4/discussion
> > >
> > > If VT-d is enabled in the BIOS the display:
> > >
> > >Works fine when viewing the boot options for Qubes (start Qubes/start 
> > > in Advanced mode, etc.) 
> > >Shows a bunch of jumbled graphics artifacts on the HD encryption view.
> > >Completely fails after that.
> > >
> > > If VT-d is disabled:
> > >
> > >All visuals behave correctly. 
> > >
> > > Please note that the HCL currently states that VT-d works correctly on 
> > > both of the T410's listed there. (Which it may be, just this display 
> > > issue)
> > >
> > > Hardware details:
> > >
> > > Lenovo Thinkpad T410 (2537P81)
> > > BIOS: 6IET85WW (1.45)
> > >
> > > Qubes: 3.0
> > > XEN: 4.4.2
> > > Kernel: 3.19.8-100
> > >
> > > VGA: Intel ... (rev 02) (prog-if 00 [VGA controller])
> > >
> > > HVM: Active
> > > I/O MMU: Not Active (while disabled)
> > > TPM: Device Present
> > >
> > > Any help would be greatly appreciated! 
> > >
> > 
> 
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBCAAGBQJWP7r0AAoJENuP0xzK19csMvoH/1GQvMvk1rJgnzjpWPpWI58p
> LRCHydMt1EsMWUzeyDV4xY0YoOOamu76Xbh8EPUxBh5sulQ2MUrO17rN0F0tCGzj
> AJKql/eOsv05JITcTgrOIDVuhGpV3HIV1NWQoOuW7LPeZ+FpM47phP9Hz1zxaPHH
> oGV0b61v/yK7E+VrKGtYdW/eHdDhr1W7v24bXic0h4SKNrc/an31VOZc9qQfREov
> CRrjBSYBJLdDAU10gfuThQdHabIDPGhEfR+CEi61SBC6F23msEeup/Q9oNcsVCeN
> x9boU2X6Wc2nmZIjSOrWzC+kChrFQLJFagjilA1ZiyIhAgmiUhpzSBWJYXtQybw=
> =5aVw
> -END PGP SIGNATURE-

Bumping it for search results on T410, the following Qubes wiki entry fixes 
this issue for me: https://www.qubes-os.org/doc/thinkpad_x201/

Thanks to this thread: 
https://groups.google.com/d/msg/qubes-users/7Q7C81AI3Aw/A7zzU2ajAwAJ

A year later I have VT-d! :)

-- 
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/665dd20e-5ef2-40ef-9995-bf49dd346b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: netvm doesn't recognize physical hardware switch state

[Boris Kourtoukov]

On Tuesday, September 13, 2016 at 8:35:54 PM UTC-4, Boris Kourtoukov wrote:
> On Tuesday, September 13, 2016 at 7:59:03 PM UTC-4, Boris Kourtoukov wrote:
> > On Tuesday, September 13, 2016 at 7:12:02 PM UTC-4, Connor Page wrote:
> > > does it work in plain Fedora?
> > > your problem most probably is not directly related to the network card 
> > > itself. it could be caused by bios settings and wrong acpi config in 
> > > kernel. I used to have the same problem when I first tried Qubes R2 on 
> > > Lenovo Yoga 2 13. ideapad_laptop module back then would work for all 
> > > models except for my Yoga. nothing could help but patching the module and 
> > > recompiling dom0 kernel. then around kernel version 3.18 it was fixed 
> > > upstream and Qubes kernel has been good for me ever since. live distros 
> > > based on Debian stable ( kernel version 3.16) can never initialise the 
> > > built-in wifi card. i found the patch on some Ubuntu forum.
> > > you haven't provided any information about the kernel and Qubes versions 
> > > that you've tried but I hope this information can be helpful. and check 
> > > your bios settings just in case.
> > 
> > Hi,
> > 
> > I am using Qubes 3.2 and have currently tested with Kernel 4.4.14-11. I 
> > will double check the Bios settings, haven't thought of that possibility. 
> > 
> > Thanks for your reply, if you think of anything else please give me a shout!
> > Boris
> 
> Hey,
> 
> I haven't checked the BIOS settings in a while and recalled my previous issue 
> here: https://groups.google.com/d/msg/qubes-users/ulmQOVxkP38/nJYy6c2lAAAJ
> 
> Due to that I've had vt-d disabled (vt-x enabled) this whole time. 
> 
> Would you say that disabled vt-d could prevent the wifi switch from working? 
> 
> I looked over the rest of the settings and wifi is enabled everywhere it is 
> listed.
> 
> (By any chance has there been any vt-d related display glitch workarounds in 
> the last year? HCL says that T410 is all green :/)
> 
> Thanks for taking a look,
> Boris

Sorry for the spam, looks like someone has had a similar issue with vt-d on 
Thinkpads and fixed it in this thread: 
https://groups.google.com/d/msg/qubes-users/7Q7C81AI3Aw/A8DrF2XqAgAJ 

I now have vt-d, but the wifi switch is still not seen. So I am ruling vt-d out 
as a possible problem. 

Back to square one!

Boris

-- 
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/cbab7d47-7eee-43eb-83db-59488617588c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: netvm doesn't recognize physical hardware switch state

[Boris Kourtoukov]

On Tuesday, September 13, 2016 at 7:59:03 PM UTC-4, Boris Kourtoukov wrote:
> On Tuesday, September 13, 2016 at 7:12:02 PM UTC-4, Connor Page wrote:
> > does it work in plain Fedora?
> > your problem most probably is not directly related to the network card 
> > itself. it could be caused by bios settings and wrong acpi config in 
> > kernel. I used to have the same problem when I first tried Qubes R2 on 
> > Lenovo Yoga 2 13. ideapad_laptop module back then would work for all models 
> > except for my Yoga. nothing could help but patching the module and 
> > recompiling dom0 kernel. then around kernel version 3.18 it was fixed 
> > upstream and Qubes kernel has been good for me ever since. live distros 
> > based on Debian stable ( kernel version 3.16) can never initialise the 
> > built-in wifi card. i found the patch on some Ubuntu forum.
> > you haven't provided any information about the kernel and Qubes versions 
> > that you've tried but I hope this information can be helpful. and check 
> > your bios settings just in case.
> 
> Hi,
> 
> I am using Qubes 3.2 and have currently tested with Kernel 4.4.14-11. I will 
> double check the Bios settings, haven't thought of that possibility. 
> 
> Thanks for your reply, if you think of anything else please give me a shout!
> Boris

Hey,

I haven't checked the BIOS settings in a while and recalled my previous issue 
here: https://groups.google.com/d/msg/qubes-users/ulmQOVxkP38/nJYy6c2lAAAJ

Due to that I've had vt-d disabled (vt-x enabled) this whole time. 

Would you say that disabled vt-d could prevent the wifi switch from working? 

I looked over the rest of the settings and wifi is enabled everywhere it is 
listed.

(By any chance has there been any vt-d related display glitch workarounds in 
the last year? HCL says that T410 is all green :/)

Thanks for taking a look,
Boris

-- 
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/365ac767-e265-432c-ac67-53c025f683a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: netvm doesn't recognize physical hardware switch state

[Boris Kourtoukov]

On Tuesday, September 13, 2016 at 7:12:02 PM UTC-4, Connor Page wrote:
> does it work in plain Fedora?
> your problem most probably is not directly related to the network card 
> itself. it could be caused by bios settings and wrong acpi config in kernel. 
> I used to have the same problem when I first tried Qubes R2 on Lenovo Yoga 2 
> 13. ideapad_laptop module back then would work for all models except for my 
> Yoga. nothing could help but patching the module and recompiling dom0 kernel. 
> then around kernel version 3.18 it was fixed upstream and Qubes kernel has 
> been good for me ever since. live distros based on Debian stable ( kernel 
> version 3.16) can never initialise the built-in wifi card. i found the patch 
> on some Ubuntu forum.
> you haven't provided any information about the kernel and Qubes versions that 
> you've tried but I hope this information can be helpful. and check your bios 
> settings just in case.

Hi,

I am using Qubes 3.2 and have currently tested with Kernel 4.4.14-11. I will 
double check the Bios settings, haven't thought of that possibility. 

Thanks for your reply, if you think of anything else please give me a shout!
Boris

-- 
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/5a000bb9-a224-4139-a494-1cfdc6b59784%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] netvm doesn't recognize physical hardware switch state

[Connor Page]

does it work in plain Fedora?
your problem most probably is not directly related to the network card itself. 
it could be caused by bios settings and wrong acpi config in kernel. I used to 
have the same problem when I first tried Qubes R2 on Lenovo Yoga 2 13. 
ideapad_laptop module back then would work for all models except for my Yoga. 
nothing could help but patching the module and recompiling dom0 kernel. then 
around kernel version 3.18 it was fixed upstream and Qubes kernel has been good 
for me ever since. live distros based on Debian stable ( kernel version 3.16) 
can never initialise the built-in wifi card. i found the patch on some Ubuntu 
forum.
you haven't provided any information about the kernel and Qubes versions that 
you've tried but I hope this information can be helpful. and check your bios 
settings just in case.

-- 
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/930c8f51-0690-45c4-a2f9-dfe868b80e6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2-rc3 RAID and nvme

[joseph . yarbrough]

On Tuesday, September 13, 2016 at 4:02:13 AM UTC-4, ludwig jaffe wrote:
> hw raid or kernel raid?
> 
> #cat /proc/mdstat

It is PCIe NVMe RAID, so Intel RST powered. It is skylake, so I don't think it 
is supported in this version of the kernel in NVMe mode. I believe SATA disks 
would be though.

no devices listed in mdstat or /dev/nvme*

On Tuesday, September 13, 2016 at 4:14:40 AM UTC-4, Marek Marczykowski-Górecki 
wrote:
> What do you mean by "EFI won't boot"? Does it crash/hang during startup,
> or isn't detected at all? Take a look here:
> https://www.qubes-os.org/doc/uefi-troubleshooting/
> 

It shows up, but it immediately returns to the EFI selection menu when I try it.

I found that page through Google before asking. No joy from any of that. 

> Also take a look at those threads:
> https://groups.google.com/forum/#!topic/qubes-users/8Ui1csb2S9Q
> https://groups.google.com/d/topic/qubes-users/kBKABl9-A3g/discussion

In legacy mode, Qubes does not boot from the USB media. It tries but it 
immediately reboots my laptop.

I did not try: efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda 
-p 1
I used the last option string. 

My laptop is new with the latest BIOS.

I appreciate the help, but I realized that I'm going to have to wait until 
Qubes has more up to date kernel / software. It doesn't let me shutdown. The 
light stays lit and something keeps it HOT until it runs the battery down. It 
doesn't come back from suspend to disk or suspend to ram.

I need to get it functional for work, as sad as I am to be limited to user 
security.

-- 
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/b6d87097-ab5d-40b1-86e1-ff0e1cab46a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] installing Signal on Qubes mini-HOWTO

[IX4 Svs]

On Wed, Sep 7, 2016 at 11:38 PM, IX4 Svs  wrote:

> On Thu, Sep 1, 2016 at 8:41 AM, IX4 Svs  wrote:
>
>> On Thu, Sep 1, 2016 at 2:21 AM, Andrew David Wong 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 2016-08-31 15:50, IX4 Svs wrote:
>>> > On Wed, Aug 24, 2016 at 11:10 PM, Andrew David Wong 
>>> > wrote:
>>> >
>>> >>
>>> >> On 2016-08-15 14:43, IX4 Svs wrote:
>>> >>> On Mon, Aug 15, 2016 at 10:19 AM, Andrew David Wong <
>>> a...@qubes-os.org>
>>> >>> wrote:
>>> >>>
>>> 
>>>  On 2016-08-14 15:22, IX4 Svs wrote:
>>> > Just spent a few minutes to figure this out so I thought I'd
>>> > share.
>>> >
>>> 
>>>  Thanks, Alex! Would you mind if we added this to the docs at some
>>>  point?
>>> 
>>> 
>>> >>> Not at all - especially if you improve my clumsy way of creating the
>>> >> custom
>>> >>> shortcut (steps 7-12) and use the proper Qubes way that Nicklaus
>>> >>> linked to.
>>> >>>
>>> >>> Cheers,
>>> >>>
>>> >>> Alex
>>> >>>
>>> >>
>>> >> Added:
>>> >>
>>> >> https://www.qubes-os.org/doc/signal/
>>> >>
>>> >>
>>> > Andrew, thanks for adding this to the documentation.
>>> >
>>> > I'm afraid my DIY shortcut kludge does not survive some(potentially
>>> boot
>>> > time) script and is wiped away from the taskbar, only to be replaced
>>> by a
>>> > default "Chrome browser" shortcut. I admit I don't quite comprehend
>>> what
>>> > the actual implementation of
>>> > https://www.qubes-os.org/doc/managing-appvm-shortcuts/#tocAnchor-1-1-1
>>> > should be.
>>>
>>> Neither do I. I've always make my custom shortcuts the same general way
>>> you do.
>>>
>>>
>> Ah, we have a usability issue here then.
>>
>>
>>> > A worked example that replaces all but the first step of the "
>>> Creating a
>>> > Shortcut in KDE" section of https://www.qubes-os.org/doc/signal/
>>> would be
>>> > very much welcome.
>>> >
>>>
>>> Agreed.
>>>
>>
>> Can someone who has figured out how to create one-click buttons to launch
>> arbitrary applications in AppVMs chime in with an example please? I'll then
>> test it and Andrew can stick it in the wiki for all Qubes users to benefit.
>>
>
> I had a look myself and may have figured out the "proper" way of creating
> a shortcut to launch Signal. By the way I submitted a pull request for the
> documentation at https://www.qubes-os.org/doc/m
> anaging-appvm-shortcuts/#tocAnchor-1-1-1 because its language is slightly
> inaccurate.
>
> These instructions (after verification) should replace the shortcut kludge
> of the signal page you created:
>
> My Signal AppVM uses the fedora-23 template, and I have renamed the
> .desktop file that Chrome created on that AppVM's desktop to
> signal.desktop. Now what?
>
> 1. Open a dom0 terminal, cd to /var/lib/qubes/vm-templates/fedora-23/
> 2. Copy Signal:/home/user/Desktop/signal.desktop to
> dom0:/var/lib/qubes/vm-templates/fedora-23/apps.templates/signal.desktop
> 3. Lightly edit 
> dom0:/var/lib/qubes/vm-templates/fedora-23/apps.templates/signal.desktop
> to be as follows:
>
> [Desktop Entry]
> Version=1.0
> Type=Application
> Terminal=false
> X-Qubes-VmName=%VMNAME%
> Icon=%VMDIR%/apps.icons/signal.png
> Name=%VMNAME%: Signal Private Messenger
> GenericName=%VMNAME%: Signal
> Comment=Private Instant Messenger
> Exec=qvm-run -q --tray -a %VMNAME% -- 'qubes-desktop-run
> /home/user/Desktop/Signal.desktop'
>
> 4. Copy Signal:/rw/home/user/.local/share/icons/hicolor/48x48/
> apps/chrome--Default.png
>  to dom0:/var/lib/qubes/vm-templates/fedora-23/apps.
> templates/apps.icons/signal.png
>
> 5. Copy dom0:/var/lib/qubes/vm-templates/fedora-23/apps.
> templates/apps.icons/signal.png to dom0:/var/lib/qubes/vm-
> templates/fedora-23/apps.templates/apps.tempicons/signal.png
>
> 6. At this point you should be all set. Ensure Qubes knows about the new
> menu item you created by starting the fedora-23 template VM and then
> running in a dom0 terminal: qvm-sync-appmenus fedora-23
>
> 7. You should now be able to go back to the GUI and from the Q menu: Q ->
> Domain: Signal -> Signal: Add more shortcuts...
> In the window that will appear, you should now have "Signal Private
> Messenger" on the left list of available apps. I moved this to the
> "Selected" list and hit OK, which put the entry in my Q menu.
>
> 8. Then I went to Q -> Domain: Signal. I right-clicked on "Signal:Signal
> Private Messenger" and selected "Add to panel".
>
> 9. Success! I now have a button in my KDE panel with which I can launch
> Signal with one click.
>
> Hope these steps get documented in the wiki (I'm not attempting a direct
> edit lest I break something) and are helpful to people.
>
> Alex
>

Alas, even after doing this "the right way" the shortcut disappears from
the panel, via no action of my own... I notice that the menu entry I
created for "Signal Private Messenger" no longer has an icon. Not sure what
may have triggered this. So for me, the proper 

[qubes-users] 3.2-rc3 is awesome...but where is NetworkManager?

[georgewalkeriv]

I just installed 3.2-rc3 on a Thinkpad T460s and it's great...but the 
NetworkManager widget is gone.  Is there a way to get that or something 
equivalent on the XFCE panel?  I've tried launching NetworkManager from the 
terminal and that didn't work.  

nmcli works fine for configuring WiFi, and I get notifications about network 
changes in the top-right corner of the screen, but still no GUI widget.

-- 
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/2101a5b4-40bd-472c-9e4c-471be0976a8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for test: Re: [qubes-users] Fedora 24?

[pixel fairy]

i think fedora24 should be the default template for qubes 3.2. were all testing 
it, cant see any problems. we cant have an EOL release for appvms. 

-- 
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/4599d5d1-b258-4d5f-9447-eb57fdc7bcd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 5:21:35 PM UTC, 3n7r...@gmail.com wrote:
> On Tuesday, September 13, 2016 at 5:16:48 PM UTC, 3n7r...@gmail.com wrote:
> > On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> > > On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek 
> > > Marczykowski-Górecki wrote:
> > > > I haven't tested this version on 3.1, but I think it should work. Just
> > > > uploaded to current-testing.
> > > 
> > > Thanks!
> > > 
> > > Everything I tested is flawless **until the #updates stage**.
> > > 
> > > =
> > > 
> > > installation: no issues (up to #updates - see below)
> > > 
> > > multi-monitor: not tested
> > > tested resolution: 4 megapixels
> > > seamless mode: working
> > > full desktop mode: working
> > > 
> > > secure clipboard: working
> > > private storage: working
> > > qvm-block: working
> > > qvm-run: working
> > > qvm-open-in-vm: working
> > > qvm-copy-to-vm: working
> > > auto-networking: working
> > > 
> > > =
> > > 
> > > Test Procedure
> > > 
> > > #install windows
> > > 
> > > QubesVMM: create templateHVM: "win-7"
> > > netVM: none; vCPU: 4; RAM: 4GB
> > > Private Storage: 10GB; System Storage: 40GB
> > > 
> > > qvm-start win-7 --cdrom=appVM:/path/to/iso
> > > iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> > > 
> > > disable UAC
> > > disable updates
> > > enable auto-logon
> > > bcdedit /set testsigning on
> > > shutdown
> > > 
> > > #install QWT
> > > 
> > > qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> > > qubes-windows-tools
> > > clone win-7 to win-7-qwt-1, win-7-qwt-2
> > > 
> > > for each qwt clone:
> > > qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> > > qvm-start win-7-qwt-? --install-windows-tools
> > > 
> > > [note re: PV disk drivers. For my first test (with just 1 vm), I disabled 
> > > PV disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. 
> > > No idea if there is any causality there. Reason for enabling PV disk is 
> > > that installing .Net package required 30 minutes just to see any movement 
> > > in the progress bar. (Might not all be due to PV disk - slowness might be 
> > > causing other things to timeout?) With PV disk enabled, the update took 
> > > less than 10 secs. I might guess that many bug reports are due to the 
> > > INSANELY slow non-PV disk ops being mistaken for system hangs... To be 
> > > fair, Virtualbox similarly has bad disk performance prior to installing 
> > > Guest Additions. Surprisingly, no issues at all installing PV disk.]
> > > 
> > > #update Windows **Problems here**
> > > 
> > > wsusoffline update
> > > 
> > > [future steps:
> > >   enable netVM
> > >   windows activation
> > >   windows update
> > > ]
> > > 
> > > =
> > > 
> > > Made it to the end of the offline update process with 2 identical clones 
> > > following the exact same procedure. One boots and is ready to go. The 
> > > other received dom0 notice about outdated GUI protocol. Will not complete 
> > > boot after repeated attempts. I can't make any sense of the logs - can't 
> > > even figure out which ones are relevant. Just to rule out any difference 
> > > in procedure that I might have overlooked, I have trashed both clones and 
> > > brought 2 fresh clones to just prior to the update process. Please let me 
> > > know how to proceed, ie which logs to collect.
> > > 
> > > One oddity that I noticed was that the Qubes VM Window name doesn't 
> > > appear to be consistent. For example, with a Windows TemplateHVM named 
> > > "win-7" and a user/domain of user@host; the name of the Windows window 
> > > will alternate? between "[win-7] win-7" and "[win-7] host". Is this 
> > > noteworthy at all?
> > > 
> > > I don't envy you Rafał. Thanks for working on this.
> > 
> > 
> > So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. 
> > They were installed with networking off so they should be identical. QWT 
> > (complete install) was installed without any errors.
> > 
> > I've been starting and shutting down each of them repeatedly with these 
> > results (Qubes logs attached):
> > 
> > win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
> > win7-qwt1-2-success: successful boot to desktop
> > win7-qwt1-3-fail: no desktop; qrexec error
> > win7-qwt1-4 success: successful boot to desktop
> > (no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
> > (no logs) #6: success (named "host")
> > (no logs) #7: success (named "host")
> > 
> > win7-qwt2-1-success
> > win7-qwt2-2-fail: hanging yellow
> > win7-qwt2-3-success
> > (no logs) #4: fail
> > (no logs) #5: fail
> > (no logs) #6: success (named "host")
> > (no logs) #7: fail
> > (no logs) #8: fail
> > (no logs) #9: success (named "win7-qwt2")
> > 
> > As stated before, the VM window title is unpredictable - sometimes, the 
> > window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] 
> > 

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 5:16:48 PM UTC, 3n7r...@gmail.com wrote:
> On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> > On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek 
> > Marczykowski-Górecki wrote:
> > > I haven't tested this version on 3.1, but I think it should work. Just
> > > uploaded to current-testing.
> > 
> > Thanks!
> > 
> > Everything I tested is flawless **until the #updates stage**.
> > 
> > =
> > 
> > installation: no issues (up to #updates - see below)
> > 
> > multi-monitor: not tested
> > tested resolution: 4 megapixels
> > seamless mode: working
> > full desktop mode: working
> > 
> > secure clipboard: working
> > private storage: working
> > qvm-block: working
> > qvm-run: working
> > qvm-open-in-vm: working
> > qvm-copy-to-vm: working
> > auto-networking: working
> > 
> > =
> > 
> > Test Procedure
> > 
> > #install windows
> > 
> > QubesVMM: create templateHVM: "win-7"
> > netVM: none; vCPU: 4; RAM: 4GB
> > Private Storage: 10GB; System Storage: 40GB
> > 
> > qvm-start win-7 --cdrom=appVM:/path/to/iso
> > iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> > 
> > disable UAC
> > disable updates
> > enable auto-logon
> > bcdedit /set testsigning on
> > shutdown
> > 
> > #install QWT
> > 
> > qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> > qubes-windows-tools
> > clone win-7 to win-7-qwt-1, win-7-qwt-2
> > 
> > for each qwt clone:
> > qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> > qvm-start win-7-qwt-? --install-windows-tools
> > 
> > [note re: PV disk drivers. For my first test (with just 1 vm), I disabled 
> > PV disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. 
> > No idea if there is any causality there. Reason for enabling PV disk is 
> > that installing .Net package required 30 minutes just to see any movement 
> > in the progress bar. (Might not all be due to PV disk - slowness might be 
> > causing other things to timeout?) With PV disk enabled, the update took 
> > less than 10 secs. I might guess that many bug reports are due to the 
> > INSANELY slow non-PV disk ops being mistaken for system hangs... To be 
> > fair, Virtualbox similarly has bad disk performance prior to installing 
> > Guest Additions. Surprisingly, no issues at all installing PV disk.]
> > 
> > #update Windows **Problems here**
> > 
> > wsusoffline update
> > 
> > [future steps:
> >   enable netVM
> >   windows activation
> >   windows update
> > ]
> > 
> > =
> > 
> > Made it to the end of the offline update process with 2 identical clones 
> > following the exact same procedure. One boots and is ready to go. The other 
> > received dom0 notice about outdated GUI protocol. Will not complete boot 
> > after repeated attempts. I can't make any sense of the logs - can't even 
> > figure out which ones are relevant. Just to rule out any difference in 
> > procedure that I might have overlooked, I have trashed both clones and 
> > brought 2 fresh clones to just prior to the update process. Please let me 
> > know how to proceed, ie which logs to collect.
> > 
> > One oddity that I noticed was that the Qubes VM Window name doesn't appear 
> > to be consistent. For example, with a Windows TemplateHVM named "win-7" and 
> > a user/domain of user@host; the name of the Windows window will alternate? 
> > between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all?
> > 
> > I don't envy you Rafał. Thanks for working on this.
> 
> 
> So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. 
> They were installed with networking off so they should be identical. QWT 
> (complete install) was installed without any errors.
> 
> I've been starting and shutting down each of them repeatedly with these 
> results (Qubes logs attached):
> 
> win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
> win7-qwt1-2-success: successful boot to desktop
> win7-qwt1-3-fail: no desktop; qrexec error
> win7-qwt1-4 success: successful boot to desktop
> (no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
> (no logs) #6: success (named "host")
> (no logs) #7: success (named "host")
> 
> win7-qwt2-1-success
> win7-qwt2-2-fail: hanging yellow
> win7-qwt2-3-success
> (no logs) #4: fail
> (no logs) #5: fail
> (no logs) #6: success (named "host")
> (no logs) #7: fail
> (no logs) #8: fail
> (no logs) #9: success (named "win7-qwt2")
> 
> As stated before, the VM window title is unpredictable - sometimes, the 
> window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] 
> host". This is true of both vm's. A race condition? I am inclined to suggest 
> that the VMs function more properly when they are named "host". Also, after 
> all the starts and stops, I've got a leftover VM window that wasn't cleaned 
> up properly and can't be closed.

-- 
You received this message because you are subscribed to 

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek Marczykowski-Górecki 
> wrote:
> > I haven't tested this version on 3.1, but I think it should work. Just
> > uploaded to current-testing.
> 
> Thanks!
> 
> Everything I tested is flawless **until the #updates stage**.
> 
> =
> 
> installation: no issues (up to #updates - see below)
> 
> multi-monitor: not tested
> tested resolution: 4 megapixels
> seamless mode: working
> full desktop mode: working
> 
> secure clipboard: working
> private storage: working
> qvm-block: working
> qvm-run: working
> qvm-open-in-vm: working
> qvm-copy-to-vm: working
> auto-networking: working
> 
> =
> 
> Test Procedure
> 
> #install windows
> 
> QubesVMM: create templateHVM: "win-7"
> netVM: none; vCPU: 4; RAM: 4GB
> Private Storage: 10GB; System Storage: 40GB
> 
> qvm-start win-7 --cdrom=appVM:/path/to/iso
> iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> 
> disable UAC
> disable updates
> enable auto-logon
> bcdedit /set testsigning on
> shutdown
> 
> #install QWT
> 
> qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
> clone win-7 to win-7-qwt-1, win-7-qwt-2
> 
> for each qwt clone:
> qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> qvm-start win-7-qwt-? --install-windows-tools
> 
> [note re: PV disk drivers. For my first test (with just 1 vm), I disabled PV 
> disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. No 
> idea if there is any causality there. Reason for enabling PV disk is that 
> installing .Net package required 30 minutes just to see any movement in the 
> progress bar. (Might not all be due to PV disk - slowness might be causing 
> other things to timeout?) With PV disk enabled, the update took less than 10 
> secs. I might guess that many bug reports are due to the INSANELY slow non-PV 
> disk ops being mistaken for system hangs... To be fair, Virtualbox similarly 
> has bad disk performance prior to installing Guest Additions. Surprisingly, 
> no issues at all installing PV disk.]
> 
> #update Windows **Problems here**
> 
> wsusoffline update
> 
> [future steps:
>   enable netVM
>   windows activation
>   windows update
> ]
> 
> =
> 
> Made it to the end of the offline update process with 2 identical clones 
> following the exact same procedure. One boots and is ready to go. The other 
> received dom0 notice about outdated GUI protocol. Will not complete boot 
> after repeated attempts. I can't make any sense of the logs - can't even 
> figure out which ones are relevant. Just to rule out any difference in 
> procedure that I might have overlooked, I have trashed both clones and 
> brought 2 fresh clones to just prior to the update process. Please let me 
> know how to proceed, ie which logs to collect.
> 
> One oddity that I noticed was that the Qubes VM Window name doesn't appear to 
> be consistent. For example, with a Windows TemplateHVM named "win-7" and a 
> user/domain of user@host; the name of the Windows window will alternate? 
> between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all?
> 
> I don't envy you Rafał. Thanks for working on this.


So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. They 
were installed with networking off so they should be identical. QWT (complete 
install) was installed without any errors.

I've been starting and shutting down each of them repeatedly with these results 
(Qubes logs attached):

win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
win7-qwt1-2-success: successful boot to desktop
win7-qwt1-3-fail: no desktop; qrexec error
win7-qwt1-4 success: successful boot to desktop
(no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
(no logs) #6: success (named "host")
(no logs) #7: success (named "host")

win7-qwt2-1-success
win7-qwt2-2-fail: hanging yellow
win7-qwt2-3-success
(no logs) #4: fail
(no logs) #5: fail
(no logs) #6: success (named "host")
(no logs) #7: fail
(no logs) #8: fail
(no logs) #9: success (named "win7-qwt2")

As stated before, the VM window title is unpredictable - sometimes, the window 
is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] host". This is 
true of both vm's. A race condition? I am inclined to suggest that the VMs 
function more properly when they are named "host". Also, after all the starts 
and stops, I've got a leftover VM window that wasn't cleaned up properly and 
can't be closed.

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

Re: [qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Sep 13, 2016 at 08:29:59AM -0700, ludwig jaffe wrote:
> Am Montag, 12. September 2016 01:29:14 UTC+2 schrieb neilh...@gmail.com:
> > Qubes uses VT-D to protect against DMA attacks on things such as WiFi chip.
> > 
> > But are there any proven DMA attacks against wired networking, i.e. 
> > Ethernet..?
> > 
> > Hackers can exploit a buffer overflow on the network card's firmware, and 
> > use that to take control of the network card, and issue a DMA attack to 
> > take control of the entire host computer.
> > 
> > I previously posted a thread about this on qubes-users ("Question on DMA 
> > attacks")
> > ... and Marek mentioned WiFi when speaking of DMA attacks.
> > 
> > Is Ethernet also vulnerable...? Or just WiFi..?
> > 
> > I say this because I wanted to build a Tor router that sits between Qubes 
> > and my main router... so that even if Qubes gets hacked, they can only see 
> > what I'm doing, and not WHO I am. The theory being, that there are no 
> > exploits for Tor itself, and only for the Firefox browser. Thus, the IP 
> > address is always obscured behind the Tor router.
> > 
> > So my router box is going to have Ethernet only, because if my Qubes is 
> > hacked, then it could just use WiFi to scan for nearby routers, including 
> > my own WiFi router, and thus identify me.
> > 
> > So, wired networking is a must.
> > 
> > And thus, I wanted to know if Ethernet is vulnerable to DMA attacks, 
> > because if it is, then I would have to use Qubes for the Tor box in the 
> > middle.. or at least, use some OS that supports VT-D, even if it's not 
> > Qubes.
> > 
> > Qubes has high system requirements, thus I'd prefer to have a cheap 
> > computer as the Tor router in the middle.. But if there truly are exploits 
> > against Ethernet, then I'll just have to use Qubes.
> 
> VT-d can do memory insulation, and should assign a memory range (pci-address 
> space of a pci device) exclusively to one VM, so the attacker of that hw can 
> do DMA into that VM, if done properly.
> But there is that evil ME in the Northbridge. How does the ME-processor 
> behave regarding VT-d? Can it be assigned exclusively to a honey-pot-vm that 
> runs windows2000?

AFAIR ME can bypass VT-d :(

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

iQEcBAEBCAAGBQJX2ChPAAoJENuP0xzK19cs2uIH/0yJViqxqwkhtcnmAKZGCS6I
T+PTZyoupW+MVYCAyruNn476iz5wKlFEzmNpyNl2M7tKp13zThyZ80QYFBXcL3dX
gSfIRAG1o5/e6UJBkGEu6XHo2YdH1agr8Yv1UL5s46ptOMJqzG0z5yJjFxU6CfAU
FCKSwo+YlYMmXjEkGyoBtOfLGdNKiSUJKjZutwYzYw2dIAToJhRAliWEjoXoLdFG
9eSBVIq/OUmeRS5LOSw0KVCoFHnHI8li+DOW/OD43tFdeJR5p+tbYMbI0AVA55pw
x6tjyw96DnXTefBcqqSb9hfjc3jWVG4f7wl/IgQ597cdI4kE0W8Zka0Nw9O3xZ8=
=gv/y
-END PGP SIGNATURE-

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

[qubes-users] Re: Using virt-viewer for remote systems

[pixel fairy]

On Tuesday, September 13, 2016 at 9:20:33 AM UTC-7, pixel fairy wrote:
> On Tuesday, September 13, 2016 at 8:26:10 AM UTC-7, ludwig jaffe wrote:
> 
> > Can one use virtviewer to give another remote user control about one 
> > guest-vm?
> > This would be a cool feature, if there is authentication of remote users 
> > against a role based system, so that remote users are able to run certain 
> > VMs on the machine.
> > How could this be made?
> 
> are you talking about screen sharing? there are already tools for this. vnc 
> and rdp are the most common.
> 
> to directly connect to the vms gui, with the os on the vm, would need access 
> to dom0, and basically break qubes security model.

meant to say without the os or any software on the vm being involved

-- 
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/e020b48b-a348-425b-abaf-b8a8a87fb541%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Using virt-viewer for remote systems

[pixel fairy]

On Tuesday, September 13, 2016 at 8:26:10 AM UTC-7, ludwig jaffe wrote:

> Can one use virtviewer to give another remote user control about one guest-vm?
> This would be a cool feature, if there is authentication of remote users 
> against a role based system, so that remote users are able to run certain VMs 
> on the machine.
> How could this be made?

are you talking about screen sharing? there are already tools for this. vnc and 
rdp are the most common.

to directly connect to the vms gui, with the os on the vm, would need access to 
dom0, and basically break qubes security model.

-- 
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/8ff27d1e-cb96-475a-8da6-d74bb2efc402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?

[pixel fairy]

On Tuesday, September 13, 2016 at 8:57:14 AM UTC-7, johny...@sigaint.org wrote:
> > Am Montag, 12. September 2016 01:29:14 UTC+2 schrieb neilh...@gmail.com:
> >> Qubes uses VT-D to protect against DMA attacks on things such as WiFi
> >> chip.

by having a separate tor gateway, you now have two machines to worry about. 
depending on your threat model, your probably better off just using whonix in 
qubes.

> >>
> >> But are there any proven DMA attacks against wired networking, i.e.
> >> Ethernet..?

this is what VT-D is for.

> But if any internal firmware of a network card, say, is compromised
> through some buffer overflow or whatever, it can just go ahead and
> initiate DMA operations at will?

we have to assume yes.

> But if you're not running any (potentially compromised) BIOS ROM or
> compromised driver, is it possible for a rogue Net card to just start
> writing to memory at will without any OS support/setup?

have you seen the exploits of fancy graphics cards? especially nvidia! same bus.
 
> (I guess a rogue netcard firmware is free to modify any network payload,
> which is powerful as well; but short of that, can it actually compromise a
> system or a VM?)

should just be the vm, unless the exploit can break out of it.

> JJ

-- 
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/3d02a0b1-c612-4c9f-862c-97b28cc6bbb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Sep 13, 2016 at 03:57:00PM -, johnyju...@sigaint.org wrote:
> > Am Montag, 12. September 2016 01:29:14 UTC+2 schrieb neilh...@gmail.com:
> >> Qubes uses VT-D to protect against DMA attacks on things such as WiFi
> >> chip.
> >>
> >> But are there any proven DMA attacks against wired networking, i.e.
> >> Ethernet..?
> >>
> >> Hackers can exploit a buffer overflow on the network card's firmware,
> >> and use that to take control of the network card, and issue a DMA attack
> >> to take control of the entire host computer.
> 
> I've often wondered this.
> 
> I figured that most modern operating systems didn't use any device BIOS,
> but used their own (e.g. Linux) drivers instead.
> 
> But if any internal firmware of a network card, say, is compromised
> through some buffer overflow or whatever, it can just go ahead and
> initiate DMA operations at will?

Yes, it can.

> In my (ancient) experience with DMA, a driver would typically set things
> up to be transferred via DMA when the data is available, or whatever,
> indicating where the transfer should occur, and so forth.

Yes, the driver typically send some request to the device to do this and
that on memory address xyz. But device can act on its own without such
request. In normal cases device would not know where is the buffer
prepared by the driver, but in malicious case it is no longer about such
prepared buffer.

VT-d act as a kind of firewall allowing device to access only certain
memory areas.

> (I guess that memory address is likely given to the device to use when the
> time comes, and not necessarily needed by the OS for the transfer?)
> 
> But if you're not running any (potentially compromised) BIOS ROM or
> compromised driver, is it possible for a rogue Net card to just start
> writing to memory at will without any OS support/setup?

Yes.

> (I guess a rogue netcard firmware is free to modify any network payload,
> which is powerful as well; but short of that, can it actually compromise a
> system or a VM?)
> 
> JJ
> 

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

iQEcBAEBCAAGBQJX2CSIAAoJENuP0xzK19csNQUH/0mq+bChVYdVEW7c18oackFH
bDjsY43jWO/o7IoPd7ejl8YijpDZBYBoo0nGlP1ATV7xERiA5IS1WamnSYj7tWFH
9+8MIYxtN1CgAdYWKH70+GL6tjZtUrPNyHw8sB+hAofJOrSmAwuxgE3CkPvC9Yvk
4d5wvHFThrmk4qQzoAyB8tQG06t3oY49sOsxU0unaXTD1PAyPUYWEkEFZczv/dM3
CJozmwSemG9WI5X8HG+yoaJCkZ64yNtyzV5s5YAs00SLHw+A0kCDnF/0+wBO11BC
uWC7dXnDQcUISavIKoOTdoZv5bGu1jNNZtlqRVTK9pKhz0PqsD7IlM5m+s0XOEE=
=PTDa
-END PGP SIGNATURE-

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

[qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?

[ludwig jaffe]

Am Montag, 12. September 2016 01:29:14 UTC+2 schrieb neilh...@gmail.com:
> Qubes uses VT-D to protect against DMA attacks on things such as WiFi chip.
> 
> But are there any proven DMA attacks against wired networking, i.e. 
> Ethernet..?
> 
> Hackers can exploit a buffer overflow on the network card's firmware, and use 
> that to take control of the network card, and issue a DMA attack to take 
> control of the entire host computer.
> 
> I previously posted a thread about this on qubes-users ("Question on DMA 
> attacks")
> ... and Marek mentioned WiFi when speaking of DMA attacks.
> 
> Is Ethernet also vulnerable...? Or just WiFi..?
> 
> I say this because I wanted to build a Tor router that sits between Qubes and 
> my main router... so that even if Qubes gets hacked, they can only see what 
> I'm doing, and not WHO I am. The theory being, that there are no exploits for 
> Tor itself, and only for the Firefox browser. Thus, the IP address is always 
> obscured behind the Tor router.
> 
> So my router box is going to have Ethernet only, because if my Qubes is 
> hacked, then it could just use WiFi to scan for nearby routers, including my 
> own WiFi router, and thus identify me.
> 
> So, wired networking is a must.
> 
> And thus, I wanted to know if Ethernet is vulnerable to DMA attacks, because 
> if it is, then I would have to use Qubes for the Tor box in the middle.. or 
> at least, use some OS that supports VT-D, even if it's not Qubes.
> 
> Qubes has high system requirements, thus I'd prefer to have a cheap computer 
> as the Tor router in the middle.. But if there truly are exploits against 
> Ethernet, then I'll just have to use Qubes.

VT-d can do memory insulation, and should assign a memory range (pci-address 
space of a pci device) exclusively to one VM, so the attacker of that hw can do 
DMA into that VM, if done properly.
But there is that evil ME in the Northbridge. How does the ME-processor behave 
regarding VT-d? Can it be assigned exclusively to a honey-pot-vm that runs 
windows2000?

-- 
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/6197ee2d-d60c-4d33-b26f-618ab23e5eac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] netvm doesn't recognize physical hardware switch state

[Boris Kourtoukov]

Hi,

Running rfkill list all I get:

0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes

But this state doesn't change if I turn the wireless switch on or off.

The machine is a Thinkpad T410. Netvm is running a near vanilla Fedora 23 
template.

I am wondering if I need to assign other hardware to the netvm in order for it 
to see the state of the hardware switch? Currently it has the Network 
controller and the Ethernet controller.

I tried a few general solutions for other distros but they have not been 
entirely applicable to Qubes. 

The drivers appear to be enabled properly when I check with lspci -v, and the 
NetworkManager does list wireless appropriately with 'Wi-Fi is disabled by 
hardware switch' So it seems like recognizing the switch is the core issue. 

Any help would be greatly appreciated,
Boris

-- 
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/d0e42b4c-ed2a-4f78-9ec8-2affc33e686f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Usb device

[katerimmel]

Hello
I haven't understood yet how open an usb device in Qubes (or in VM that I
choose).
Can someone explain me how do I do?

Thank you

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

Re: [qubes-users] Re: Qubes OS 3.2 rc3: can not boot with VT-d enabled on DELL T7400 (XEON E5440, Intel 5400 chipset)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Sep 13, 2016 at 10:44:55AM +0200, ludwig jaffe wrote:
> Hi, can I somehow dump the debug info to serial interface, so I can log it,
> before it reboots. Also it would be nice to set a high verbosity level.
> How to do this?

If you're lucky owner of a machine with real serial port (not the one on
USB), then yes, it is possible. Add "console=com1 com1=115200,8n1
loglvl=all". For details see here:
http://xenbits.xen.org/docs/4.6-testing/misc/xen-command-line.html

In theory it is also possible to use USB debug port, but it require some
additional hardware.

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

iQEcBAEBCAAGBQJX18E7AAoJENuP0xzK19csRw4H/im7V3ce29zQppH3s6v8PeFe
QX7owldqpybm9wQW6asDZMkn883o54FSA7zbomDp+aQAC4/IsBRxsag6hDgWt6nE
ybiteA77M1JKeltBVqIwmvmkEgXtUlcXproBN52imgn9VBoJh1WTZ5/iFYyvgsWj
u6tcR798aBq2AvKO6XPi4cpjFfdV4l5oWke1w7zTU//S97gfct/ol4vUd7PbLzgR
CRblST63eJ8PS87Zu8B98FHA5020uiqkgIx3x03sBVYOdYAAmKv5TRGzJDYTpiIE
cYbCnofcHE8Z+cHXC9mMF/drVsFlVdbq+r+3DCbb4PFJEUJ8n/2PpDo//hj4XbI=
=ZXIw
-END PGP SIGNATURE-

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

Re: [qubes-users] multiple display support

[Achim Patzner]

Am 13.09.2016 um 08:44 schrieb Zrubi:

> It is only me or a general problem?
> is there ANY workaround for those problems?

This seems to be a general problem coming from the maximally stupid idea
of having multiple "crt"s making up one display (so a projector could
overlap a part of a screen" instead of doing it as X11 originally
intended and map one output device/connector to one display. My
workaround on other systems was assigning each of my output devices to
separate displays (after all that's what the y in host:x.y was invented
for) but I didn't spend the time on that for Qubes on my current machine
yet.


Achim

-- 
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/c5482002-863f-c596-e403-e6115bbb313d%40noses.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] multiple display support

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/13/2016 10:02 AM, Marek Marczykowski-Górecki wrote:

>> * panel are not sticked to my internal (primary) display. Both 
>> KDE and XFCE behaving this way. My panel gets replaced to the 
>> most left display instead of the primary one. Really annoying.
> 
> Can you elaborate? You have multiple panels, one for each display 
> and those are mixed up, right? I haven't seen such problem,
> because I have only one panel, on primary display.

No.

I have only one panel. And wanted to stick it on my primary display.
But whenever I attach an external screen that single panel moves to
the most left one instead of the primary (internal laptop screen)


But because of the other (deconfigure) bug/feature i can't even use
Xfce without major headache.



BTW I'm using a T450 with a docking station. It has 2 attached
external display. So every time I have to remove my laptop from the
docking station I lost my screen settings what i really can't tolerate
at work.

(I was using the same setup with a Dell 6430 with Qubes 2.0 then 3.1
before - without such problems)

- -- 
Zrubi

-- 
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/517f1d41-fb26-677b-f8bd-3cfda8207261%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS 3.2 rc3: can not boot with VT-d enabled on DELL T7400 (XEON E5440, Intel 5400 chipset)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Sep 13, 2016 at 01:00:02AM -0700, ludwig jaffe wrote:
> Am Dienstag, 13. September 2016 09:57:53 UTC+2 schrieb ludwig jaffe:
> > Qubes OS 3.2 rc3: can not boot with VT-d enabled on DELL T7400 (XEON E5440, 
> > Intel 5400 chipset)
> > 
> > Hi all, I can NOT boot on my machine, Dell T7400 (XEON E5440, Intel 5400 
> > chipset, LSI HW-RAID1 "DELL SAS6" and 4GB RAM - will become more) with VT-d 
> > enabled. 
> > When I disable VT-d in bios, the machine boots and can run several VMs.
> > 
> > VT-d is needed to assign certain pci-devices to VMs (e.g. scsi-controller 
> > to vm with some proprietary scanner application running windows).
> > 
> > How does it behave?
> > 
> > The grub screen is loaded, and one can select the options, here I edit to 
> > remove quiet as I want to see.
> > 
> > So grub loads, XEN, vmlinuz, initrd.img,
> > and then it crashes on the spot, causing the machine to reboot.
> > 
> > No debug output can be seen.
> > 
> > Any Ideas?
> > 
> > 
> > Thanks,
> > 
> > 
> > Ludwig
> 
> I want to clarify: with VT-d disabled, the machine behaves and runs, but it 
> is 
> impossible to assign pci devices to VMs, because this is what VT-d is for.
> With VT-d enabled, it chrashes after loading initrd.img

Remove also "console=none" parameter to see Xen messages.

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

iQEcBAEBCAAGBQJX17LyAAoJENuP0xzK19csdGgH/3AYg8AJf9ts2vf1yPXza/gj
99OUJa8C3TEs2y+LOHpvxd9l8xmk0tq+HCInTVI3mv5eWYQIKHCwgfqzwsTP4pJr
09+ABiexV/y2GBpZEoxbUtYxok7LhdsoXxn2wt/shmi+8rTOx9Qza399SycqxK9x
ADHZl65a8Ybi+RhCeP4njVEGh2yy9W4gbTEjLyAhsC10vDGJpqudiiHkCPZHea2c
U6r/VyqHLJhYdd4dI0x6jESHiW1jKNHzT01WqHYR81+L5w/fh7YsXXrYfkkIn62B
llkrSvXmlIjbRC7Dy/fwmyGuQWuWeZPfH3qE5V+EyEn2hk5nNRehXztA3bThMjk=
=c+06
-END PGP SIGNATURE-

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

Re: [qubes-users] multiple display support

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Sep 13, 2016 at 08:44:21AM +0200, Zrubi wrote:
> Hi,
> 
> Multiple (2 external +the internal) display support seems to be broken
> starting by Qubes 3.2rc*
> 
> At least for me it was working as expected up until I upgraded to
> 3.2rc3. The problems I have:
> 
> * display settings are not saved.
>  - under KDE it is saved somehow, but have to be disable composition
> for stable operation. But still not always keep after reboot :(
> 
>  - under XFCE even if I have the same session if I detach then attach
> again my external screens connected as disabled. I have to be move
> around and enable every time I connect them. In this way it is
> completely useless and broken.

Take a look at Setting -> Display -> Configure new displays when
connected. Not ideal, but somehow helps.

I'd very like to have X (server? window manager?) _not_ deconfigure my
external display when disconnected. It messes up all the carefully
placed windows.

It looks like a new X/Xfce "feature" :/

> * panel are not sticked to my internal (primary) display.
> Both KDE and XFCE behaving this way. My panel gets replaced to the
> most left display instead of the primary one. Really annoying.

Can you elaborate? You have multiple panels, one for each display and
those are mixed up, right? I haven't seen such problem, because I have
only one panel, on primary display.

> in previous releases I also had to disable composition (under KDE4) to
> get bug free multidisplay support - but at least that was WORKING.
> 
> 
> It is only me or a general problem?
> is there ANY workaround for those problems?

I have this:
$ cat /etc/X11/xorg.conf.d/10-disable-hotplug.conf 
Section "Device"
Identifier "intel"
Driver "intel"
Option "HotPlug" "false"
EndSection

It helps somehow, but still will detect that external display gets
disconnected when explicitly asked (`xrandr`). With all its
consequences...

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

iQEcBAEBCAAGBQJX17KZAAoJENuP0xzK19csqXEH/31FDjY2b5yhE7RoPEXvsLfL
OX/a78xKIqAlK9HZYBPfzJwsqHjSqdJ3CFGrv9tCz8SEQMfOkleMivLEjDeYJWxE
eqsGs+GIpEdtObzE8Pw3oaNH5kGBl6sBqEv5rkneijqh6wmJ3TklA+AwUwA6gsts
lXl9cbZO5JWmx8d0UKWo/vgP105YQbqCKAhZ7+isOySE/dQj0I+DCH5Meo5WdaPm
2KAJt4TJuvenirUCaOm9tw4R3weKUVRa0wrlufHUN6AEHHWGpF64hy7V4A8Dr1TG
6dG8rz2B76LRINLT9oP2/MOHXcobd88uVNq5yD9pMDfsitWWqpnBdi/HkBUlFhM=
=YGdZ
-END PGP SIGNATURE-

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

Re: [qubes-users] 4.0 ETA?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Sep 12, 2016 at 11:11:55PM -0700, Vít Šesták wrote:
> Why is it not planned to support in-place upgrade? Is it harder than usual?

Yes. There are at least two major changes:
1. qubes.xml format, including different VM types (for example there is
no more separate NetVM/ProxyVM type - those are just AppVM with
"provides_network" set to "true")
2. default storage backend for VMs disks switched to LVM thin, instead
of sparse files

The first one is probably manageable - in fact backup utility do have
the code to convert it. But the second is harder - there is no easy way
for in-place conversion of static LVM volume into LVM thin volume pool
(without using twice as much space for the operation). There will be
still some limited support for VM disks in sparse files, but - limited,
not all the features will work (for example Disposable VMs most likely
will not).

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

iQEcBAEBCAAGBQJX16/4AAoJENuP0xzK19cs2S0IAIIXF1CGJNP/ytnX9GKRlJcd
8uFWaolW+mwO2IOXANxbeIjlA4IFNWKAEFzzyi708hP+hVArzQVN28MVuxLtgKxt
iDx7wI05wWLnvfM+ffK5RWOUiRTO0pIEZ/+mD5qqWlsN1dgwP/dCszpdN3X4kOF2
q/N255rNn6A5XK4q54b2B85lQepufGeCLrX0/Z0phx8JT9C/zrOew2qudcvuz931
5/XK9W/84N19QNaRAfWNDUrA8lhQSClnz+Q27PQRW6p9ANFczvSiuINHjgzSt8TK
JSUYBcqQnSl8s0zAJmKW98N6KQvgdXRJjf3CahmpIaxodrWpuqApO4B0quDZgWg=
=y9xx
-END PGP SIGNATURE-

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

[qubes-users] multiple display support

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Multiple (2 external +the internal) display support seems to be broken
starting by Qubes 3.2rc*

At least for me it was working as expected up until I upgraded to
3.2rc3. The problems I have:

* display settings are not saved.
 - under KDE it is saved somehow, but have to be disable composition
for stable operation. But still not always keep after reboot :(

 - under XFCE even if I have the same session if I detach then attach
again my external screens connected as disabled. I have to be move
around and enable every time I connect them. In this way it is
completely useless and broken.

* panel are not sticked to my internal (primary) display.
Both KDE and XFCE behaving this way. My panel gets replaced to the
most left display instead of the primary one. Really annoying.



in previous releases I also had to disable composition (under KDE4) to
get bug free multidisplay support - but at least that was WORKING.


It is only me or a general problem?
is there ANY workaround for those problems?

Thanks.


- -- 
Zrubi

-- 
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/f507f8dd-66b5-5d61-7e82-34f43a308f62%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Is there any hope for Wayland?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-12 22:52, Vít Šesták wrote:
> Well, the points you have mentioned are also dubious for mainstream
> Linux environment, not only for Qubes, because they suppose a
> malicious app already installed in the system.
> 
> Other point are, however, accidental interferences with lockscreen.
> For example, I sometimes see Thunderbird popup on the lockscreen. I
> don't consider Thunderbird to be a malicious app (if it was, it would
> probably send my emails via Internet, which would be more practical),
> but it still leaks few information. There are also some complaints by
> other users, see discussions about Physlock (which might be also a
> way to address these problem).
> 

We should be careful to distinguish the claim that X11 screen lockers
*cannot* (even in principle) be secure (e.g., due to inherent
architectural limitations) from the claim that most (or even all)
*existing implementations* of X11 screen lockers are flawed, buggy,
or insecure.

Your and others' (legitimate) gripes about the screen lockers we
currently use are evidence of the latter (but not necessarily the
former) claim.

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

iQIcBAEBCgAGBQJX15c7AAoJENtN07w5UDAw12oP/ihA/AfRA/y6C6Zd9pAiA078
Lk6HiaRr5AyMEsD9jDkE/wXYzKTWXbz1g6aRsjsQHmkCDG4mFd7gahKtm8ipGTPe
OFLGqaKjBu+e7eJLebd11DAT4iuQxa02rz2+c99dNXKZtf5RszDK6BMPhakq7PMY
G6oD1A4jyq0X78sKKTBWCgg2kkMe0mQVogWThXo5rLCjD/yqREAG6WDn7Q+no8R/
FvCd6FrbsrVFdLgO/W4g9ovvec1Wi5Fy3Cgx1iruW1t9ARSeYLuCT3FAeNdmtOUx
FhJvbpYdwc/GlFUSE9p1Xc7YYiBH2VATr26R7vBa9B4IABtymdVYJ9ifM3IuY9SN
bbCOCFQcmgH971DFN/Tou6qKD26PMMP6ovX8QnxpEX48irqlQl5Od3TN0FZORgVf
4VV5mB3jQ0+qoiLHJsEi8tjJUrfbnCbBArzw/ABFAoDEoeX00iPfpogR+ZplRjpN
WuXDmEUo8fp/SCgtk8rFVoFbeTSzTXgan8roQ0fKo6IiHLylm8esojzzyXUsK2Ss
Hh3OHsq+zORZxMqrvHP6JgkL4sd263ez41ds685zCWvMSq1IUwSlVXq3EMDPx5GH
pVgSrtwnHM3kNOALPBgNaw80HGsnhAWqz2OFTfxFZ1W4T1dLwji+P6FcjK96rPI4
E4ANXZRzxWj9vvL8CQLA
=ubMd
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/09d27472-5a20-eede-7548-acb4b4729a4a%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?

[Vít Šesták]

4. It depends if you just disable Wi-Fi, or if you don't have the hardware.

Removing wireless radio, microphone and camera might be hard on laptops, so it 
depends on hardware you have. I wanted to note that staying anonymous with 
whole physical (or even a virtual) machine compromised might be hard, but is 
depends on your usage, your hardware and on your threat model. BTW, various 
deanonymization attacks are described on Whonix wiki. Some of them are rather 
trivial and target on nonskilled users, some are more advanced.

-- 
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/c65d316c-abe1-471a-b5d5-ba505310bcdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.