[qubes-users] Re: qvm-usb not functioning

[Marke50]

On Monday, September 18, 2017 at 10:36:18 PM UTC-4, Drew White wrote:
> On Friday, 15 September 2017 23:39:53 UTC+10, Marke50  wrote:
> > There should be better instructions and documentation on this and working 
> > with hardware within the vm's
> 
> I agree with you. But they do not really have decent documentation for Qubes 
> anywhere.
> 
> You ahve to get the basics then experiment.

https://www.qubes-os.org/doc/usb/
Scroll to the bottom until you find "How to attach USB drives"

I just tried this today and it worked well 

-- 
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/8e8431d1-65b7-4ce3-82bd-1fc3b01eed80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Privacy in Qubes

[Person]

Let's say you have an online identity that you want to keep separate from your 
personal information. On Qubes, is it possible to keep i information completely 
separate without physical separation? I have considered using a separate OS 
virtualized in Qubes, but it may possibly leak the same device data. 
Multibooting with Qubes is also not the safest idea. 

What is the best way to keep online information from being traced back to you 
on Qubes?

-- 
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/7e452b2b-19eb-44dc-8c5d-221ee985f1ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Unable to uninstall or reinstall Whonix

[Person]

I use Qubes-Whonix (precisely Qubes 3.2), and when I try to remove the Whonix 
Template VMs after removing the anon-whonix VM, it says that the command I used 
to remove is not found. Also, the Whonix template VMs no longer work.

I also tried to just install Whonix, but dom0 replies with "Update VM not 
found".

-- 
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/5a65736c-9f0d-4c3e-86e6-0580e3199979%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-usb not functioning

[Drew White]

On Saturday, 16 September 2017 05:11:47 UTC+10, P R  wrote:
> Hello Drew,
Hi P R,


> Can you provide more information:
Yes I can.
 
> - which Qubes Version?
Qubes 3.2
Linux dom0 4.9.45-21.pvops.qubes.x86_64 #1 SMP Tue Aug 29 14:21:02 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

> - Laptop / Mainboard Modell
I have a Dell T5500
and an HP EliteBook 8460p

> - Kind of USB VM (the stock USB VM?)
Whatever VM I use. Windows or Linux. Tools or not.

> - if you attach USB devices, do they appear in sys-usb?
I have no SYS USB, they appear in Qubes since sys-usb does not work in Qubes 
and is still flawed and doesn't work.

> - (...)
(...) ???

> - what kind of USB device are you trying to attach?
Printer, Drive Bay, Wireless Adaptor, 3G Dongle, USB-Ethernet, and more.

> - to which AppVM/Operating System are you attaching it to?
Whatever VM I use. Windows or Linux. Tools or not.

> - have you followed the docs at https://www.qubes-os.org/doc/usb/
I'm not using a USB Qube OR a sys-usb system, I am tryign to attach a USB 
device from Dom0 to a guest.


> more information first, answers will come second ;-)
Is that enough information?


> - PhR
- Drew

-- 
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/eff4e623-a65e-480d-a3d1-86b62d162fc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[Ted Brenner]

I thought I read somewhere that VMs make it harder to fingerprint using the
CPU, graphics card, etc. Did anyone else read that? That would be a feather
in Qubes's hat if true.

Any suggestions for a good anonymizing browser (besides the Tor browser of
course)? I would assume Firefox would have the most interest in that though
perhaps not as good. Not sure if Chromium is free of Google or not.

On Mon, Sep 18, 2017 at 4:47 PM,  wrote:

> Roger that, thank you Leo so it sounds as though Qubes ought to be up to
> snuff for all contemporary ad instustry practices that Google, Facebook,
> Doubleclick etc are liable to try but that Qubes + anonymizing browser is a
> better bet against more sophisticated tracking in case that were a concern.
>
> Great news. :)
>
> On Monday, September 18, 2017 at 2:39:34 PM UTC-7, Leo Gaspard wrote:
> > On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> > > Thank you Micah and Michał, but I am not actually asking about a
> standard as strong as 100% bulletproof anonymity or anything. I really am
> just concerned about whether any of the methods on that list that I linked
> to would be enough to leak cookie-like reference data between two separate
> Qubes security domains.
> >
> > Cookie-like reference data between two separate Qubes security domains
> > cannot happen. This would mean one VM is able to influence the hard disk
> > of another, which would be a vulnerability in Qubes.
> >
> > > Being tracked as I browse around *in* a given security domain is
> entirely my problem of course, and I understand that. My only concern is
> working to ensure that to an outside observer such as webservers and ad
> networks nothing short of the shared IP address (and via Tor or VPN or
> different IPs honestly allocated to different domains perhaps not even
> that) can act as a reliable indicator that web browsing activity in one
> Qubes security domain is "linked" to activity from another security domain
> via any secretly stored cookie-like reference identifiers that get somehow
> leaked across domains.
> >
> > What can however happen is things like hardware fingerprinting through
> > the browser, like CPU frequency measurements.
> >
> > Also, Qubes doesn't guarantee two VMs can't talk together, so if you
> > have at the same time a browser in two VMs in two websites they may be
> > able to talk together using such side channels (timing the cache,
> > ultra-low-level stuff like that).
> >
> > So even though supercookies and the like aren't shared in Qubes, if you
> > use an insufficiently anonymising web browser, a web site may be able to
> > fingerprint your hardware through the browser (Qubes/Xen does nothing to
> > prevent that for performance reasons), and then to link your hardware to
> > different identities you used to browse different pages in different VMs.
> >
> > I don't know of any website that would try to talk to others through
> > side-channels, but I seem to remember articles on hardware
> > fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
> > a few years back, so I guess against state-of-the-art tracking systems
> > Qubes will not be enough.
>
> --
> 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/68d78695-e01b-43d8-807d-ca6e7b795531%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sent from my Desktop

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

Re: [qubes-users] Anyone disabled the Intel ME yet?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

alexclay...@gmail.com:
> Has anyone here successfully disabled the Intel ME yet?
> 
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> 
> I'm hoping a future release of Qubes integrates this into the
> install process for us. Or be downloadable as a package like
> Anti-Evil Maid?

https://github.com/corna/me_cleaner

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZwEIxXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfNg8P/R29hIUOrlolKVQXjgQ27MX0
oWClVtfGX7+geO+mU3WYY0UQYeOCWyRJIxOrbsySrKf0WcqN2H0NwpxcJrHXYI8Z
mm1CVcC8VZcR7hMARHLWz61EFfBbSUL+azP1elPZQ/yuB1If3NpyR9PSM8Nrhs0v
Mdh9N2HdhYfxV6YNPhcUo1bVsaP9Z3X8/8T/whybN6KaMiF4y573wXqXwSc/lNsN
P5bpBH1GcAZI2BfH29dt1TU+t94pELekdAtZKDFW4riSLhhWW9nfDPThupqJ2kps
MXhFJxREXsUPpXOf6vc+JI667+8s1Cb4jfXovKPGgIG/4dh3qFIIyc9p/0q6pLca
UBN7V2GBkkpdpyRX/QhHHcbw+Ri2SKul/2LRMVZ7d/nqwRfHchxGmYKFIjFjYVdx
1bfVc8wgnX1WZGOg0EvEgx0vG8H0+DU+Yw5Wyuv4jO4UfILJ/FTBxa1KyMWv6xvS
lf9tjL28k+HBiwzDs5MCdV9rUJ9W0q/zySntZItI/7wd8UPC0YadzqwxF74xh/d4
SLy9rL/1aMwhpvd+rCFipn1B3wIlY/y/VPq3FpLsPrAjoesbZ1BeUmQ9wdvumTn3
sSwcUfUnt1N6mWWtPYtSPYQyD1A4r9I2RFEuq8YuLEyG3BveC9RanApNE5CboBFA
JKyVN0I7q5dmd0bk4IEm
=UlBw
-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/20170918220121.GA1088%40mutt.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[jesset]

Roger that, thank you Leo so it sounds as though Qubes ought to be up to snuff 
for all contemporary ad instustry practices that Google, Facebook, Doubleclick 
etc are liable to try but that Qubes + anonymizing browser is a better bet 
against more sophisticated tracking in case that were a concern.

Great news. :)

On Monday, September 18, 2017 at 2:39:34 PM UTC-7, Leo Gaspard wrote:
> On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> > Thank you Micah and Michał, but I am not actually asking about a standard 
> > as strong as 100% bulletproof anonymity or anything. I really am just 
> > concerned about whether any of the methods on that list that I linked to 
> > would be enough to leak cookie-like reference data between two separate 
> > Qubes security domains.
> 
> Cookie-like reference data between two separate Qubes security domains
> cannot happen. This would mean one VM is able to influence the hard disk
> of another, which would be a vulnerability in Qubes.
> 
> > Being tracked as I browse around *in* a given security domain is entirely 
> > my problem of course, and I understand that. My only concern is working to 
> > ensure that to an outside observer such as webservers and ad networks 
> > nothing short of the shared IP address (and via Tor or VPN or different IPs 
> > honestly allocated to different domains perhaps not even that) can act as a 
> > reliable indicator that web browsing activity in one Qubes security domain 
> > is "linked" to activity from another security domain via any secretly 
> > stored cookie-like reference identifiers that get somehow leaked across 
> > domains.
> 
> What can however happen is things like hardware fingerprinting through
> the browser, like CPU frequency measurements.
> 
> Also, Qubes doesn't guarantee two VMs can't talk together, so if you
> have at the same time a browser in two VMs in two websites they may be
> able to talk together using such side channels (timing the cache,
> ultra-low-level stuff like that).
> 
> So even though supercookies and the like aren't shared in Qubes, if you
> use an insufficiently anonymising web browser, a web site may be able to
> fingerprint your hardware through the browser (Qubes/Xen does nothing to
> prevent that for performance reasons), and then to link your hardware to
> different identities you used to browse different pages in different VMs.
> 
> I don't know of any website that would try to talk to others through
> side-channels, but I seem to remember articles on hardware
> fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
> a few years back, so I guess against state-of-the-art tracking systems
> Qubes will not be enough.

-- 
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/68d78695-e01b-43d8-807d-ca6e7b795531%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS 4.0 without IOMMU

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Sep 16, 2017 at 12:46:35PM -0700, damm swing wrote:
> By the way, is it possible that some AppVM could compromise NetVM (e.g. by a 
> hypothetical bug in Xen net backend) and then use the DMA attack?

Yes, it is theoretically possible. See for example here:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-023-2015.txt

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

iQEcBAEBCAAGBQJZwD1jAAoJENuP0xzK19cscIwH/AqpD+R6Ro2KWY2AVK1wfoSG
igZOQMYVwzwa4bRvisoYtd1xn1/1e4yL7BWwmwKjEr5RhkTa5hI3+qOCw7DW7znU
zkHNwh3yEYBr52d4RWWMtDYGC01Kv+66zvZlCsetbmbyn768ltpyndQzyUgVDBOw
Z5zD61r+kTxg4YsIZuwfbtsyyKgfC2gEjQRYjr417V/RYINgcOl8XSlcEBClWssM
tqZZcAQ4DCzFakyZZI2cgxgW4Wn/3u7UJbO7TS5TCe/qaUq0YVBc1FMus32v4BxN
vgZ+XX+ZFb64hJwotPLP3u4R8VSWyOL/2ichE/snID5VUbw5o2oEOMdXLs6EFdo=
=0CkL
-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/20170918214054.GA10540%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[Leo Gaspard]

On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> Thank you Micah and Michał, but I am not actually asking about a standard as 
> strong as 100% bulletproof anonymity or anything. I really am just concerned 
> about whether any of the methods on that list that I linked to would be 
> enough to leak cookie-like reference data between two separate Qubes security 
> domains.

Cookie-like reference data between two separate Qubes security domains
cannot happen. This would mean one VM is able to influence the hard disk
of another, which would be a vulnerability in Qubes.

> Being tracked as I browse around *in* a given security domain is entirely my 
> problem of course, and I understand that. My only concern is working to 
> ensure that to an outside observer such as webservers and ad networks nothing 
> short of the shared IP address (and via Tor or VPN or different IPs honestly 
> allocated to different domains perhaps not even that) can act as a reliable 
> indicator that web browsing activity in one Qubes security domain is "linked" 
> to activity from another security domain via any secretly stored cookie-like 
> reference identifiers that get somehow leaked across domains.

What can however happen is things like hardware fingerprinting through
the browser, like CPU frequency measurements.

Also, Qubes doesn't guarantee two VMs can't talk together, so if you
have at the same time a browser in two VMs in two websites they may be
able to talk together using such side channels (timing the cache,
ultra-low-level stuff like that).

So even though supercookies and the like aren't shared in Qubes, if you
use an insufficiently anonymising web browser, a web site may be able to
fingerprint your hardware through the browser (Qubes/Xen does nothing to
prevent that for performance reasons), and then to link your hardware to
different identities you used to browse different pages in different VMs.

I don't know of any website that would try to talk to others through
side-channels, but I seem to remember articles on hardware
fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
a few years back, so I guess against state-of-the-art tracking systems
Qubes will not be enough.

-- 
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/1720ec21-6433-8a0c-02bc-aeb17336fb8c%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anyone disabled the Intel ME yet?

[alexclaytor]

I see, thank you for the explanation. I had no idea ME versions were that 
fragmented. 

-- 
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/affa89af-208f-4ecc-8430-4e27a3e60935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[rysiek]

Hey,

Dnia Monday, September 18, 2017 12:27:21 PM CEST jes...@gmail.com pisze:
> My only concern is working to ensure that to an outside observer such as
> webservers and ad networks nothing short of the shared IP address (and via
> Tor or VPN or different IPs honestly allocated to different domains perhaps
> not even that) can act as a reliable indicator that web browsing activity in
> one Qubes security domain is "linked" to activity from another security
> domain via any secretly stored cookie-like reference identifiers that get
> somehow leaked across domains.

Right.

> For example: if I browse to a Flash or Silverlight website using Browser X
> in my [untrusted] domain, would those plugins be able to store any kinds of
> LSOs or HTML5 local storage or cached E-tags or anything else deep enough
> into the system backend that they could pull them back out again in my
> [work] domain when I browse back to that same site again?
> (...)

As far as I understand, the answer for Qubes is "this should absolutely not 
happen", but the Qubes developers should probably weigh-in on that. I for one 
would find a "how deep does the rabbit-hole get here" discussion on this very 
informative.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

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


signature.asc
Description: This is a digitally signed message part.

Re: [qubes-users] Anyone disabled the Intel ME yet?

[Alex]

On 09/18/2017 10:33 PM, alexclay...@gmail.com wrote:
> Has anyone here successfully disabled the Intel ME yet?
> 
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> 
> I'm hoping a future release of Qubes integrates this into the install
> process for us. Or be downloadable as a package like Anti-Evil Maid?
> 
> Thoughts?
> 
This is an extremely risky and highly ad-hoc procedure that cannot be
easily automated. As you can understand from the article, newer ME
versions manage the boot process so some level of functionality is
required just to have a working computer.

Being an opaque component, different versions have highly variable level
of built-in functionality and architecture position, so while some ME
versions on some chipsets could just be zapped away, others have to be
patched, reflashed, bypassed or replaced to be disarmed.

Hence, the operations to "disarm" ME still resemble more surgery than
patching; our only hopes are that Intel will give a simple way of
disabling the unneeded "services" (i.e. network services?) with
something reasonable like a hardware jumper of some sort. They will be
able to give the HAP guarantees to their customers without impairing
security for everybody else...

-- 
Alex

-- 
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/338cf7e2-e5ee-eafd-4187-6d829f2dbb01%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Anyone disabled the Intel ME yet?

[alexclaytor]

Has anyone here successfully disabled the Intel ME yet?

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

I'm hoping a future release of Qubes integrates this into the install process 
for us. Or be downloadable as a package like Anti-Evil Maid?

Thoughts? 

-- 
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/ebdfd4fb-c5df-45fd-b6bc-8f944703babe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[jesset]

Thank you Micah and Michał, but I am not actually asking about a standard as 
strong as 100% bulletproof anonymity or anything. I really am just concerned 
about whether any of the methods on that list that I linked to would be enough 
to leak cookie-like reference data between two separate Qubes security domains.

Being tracked as I browse around *in* a given security domain is entirely my 
problem of course, and I understand that. My only concern is working to ensure 
that to an outside observer such as webservers and ad networks nothing short of 
the shared IP address (and via Tor or VPN or different IPs honestly allocated 
to different domains perhaps not even that) can act as a reliable indicator 
that web browsing activity in one Qubes security domain is "linked" to activity 
from another security domain via any secretly stored cookie-like reference 
identifiers that get somehow leaked across domains.

For example: if I browse to a Flash or Silverlight website using Browser X in 
my [untrusted] domain, would those plugins be able to store any kinds of LSOs 
or HTML5 local storage or cached E-tags or anything else deep enough into the 
system backend that they could pull them back out again in my [work] domain 
when I browse back to that same site again?

>From a differential diagnostic perspective, I know that running two COMPLETELY 
>separate VMs via XenServer et al with completely separate OSen and completely 
>separate installs of the same browser and Flash plugin — where they don't even 
>view a single shred of the same filesystem — should be safe from any industry 
>standard client tracking data (EG, short of malware like Bluepill or direct 
>exploits against the incumbent hypervisor) leaking between said domains.

However two different browsers on the same computer/OS combo, such as Firefox 
and Opera, might get Flash installed via the same process which gives the Flash 
plugin on both browsers access to the same LSO store squirreled away somewhere.

So I'm just trying to confirm how close to case 1 Qubes security domains rate, 
even when you are still only installing the OS, the browser, and the Flash 
plugin once for use by both light VMs.

I hope this helps to clarify my inquiry, thank you!

- - Jesse

On Monday, September 18, 2017 at 11:02:31 AM UTC-7, rysiek wrote:
> Dnia Monday, September 18, 2017 10:56:33 AM CEST Micah Lee pisze:
> > Qubes security domains don't necessarily help solve this problem because
> > really the problem is how your web browsers are configured.
> > 
> > So a tracking company can't link your browsing activity between Qubes
> > domains -- your "personal" traffic and "work" traffic might look like
> > two separate people -- but within one of those domains, they can still
> > track you, and do all of those tricks.
> > 
> > If you want web privacy, you'll have to configure your browser within
> > Qubes the same way you have to outside of Qubes. Or, you can do all of
> > your browser in DisposableVMs. Or use Tor Browser, which has taken many
> > steps to prevent browser tracker as a design goal.
> 
> Damn, beat me to it!
> 
> -- 
> Pozdrawiam,
> Michał "rysiek" Woźniak
> 
> Zmieniam klucz GPG :: http://rys.io/pl/147
> GPG Key Transition :: http://rys.io/en/147

-- 
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/299c63e1-3e81-408b-a0cb-7c4fedfc7843%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] UEFI secureboot issue

[Wim Vervoorn]

Hello Marek,



This is clear. Do you have any plans to do this in the future?



Best regards,



Wim Vervoorn





Van: Marek Marczykowski-Górecki
Verzonden: zaterdag 16 september 2017 00:32
Aan: Wim Vervoorn
CC: taii...@gmx.com; 
qubes-users; 
raahe...@gmail.com
Onderwerp: Re: [qubes-users] UEFI secureboot issue



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Aug 15, 2017 at 07:20:01AM +, Wim Vervoorn wrote:
> Basically I am not asking for some type of religious war on Secure Boot. All 
> I am basically asking for is if the executables provided in the Qubes 
> distribution are signed and if so which keys have been used.
>
> If they are not and we should sign them ourselves (either for grub or 
> secureboot) this is good to know as well.

No, currently neither of those binaries (xen.efi, kernel, initramfs) are
signed. Only rpm packages carrying them.

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

iQEcBAEBCAAGBQJZvFTJAAoJENuP0xzK19csyYQIAJagCeOm29MPiQC8rG/tyxlA
/4OdRu/LmerqyxFW1jUjE19YeH0i+/Lr2VVOI07/NcZeEpH2VfoRmWZYeNExyH+x
FyxOBQIJjg+FyvihtHfPlGRHkRBtvAVrJcFCZgteUH5zN5fa/pY+05X3WjhnReNg
se9EQeMGY8VRyPHXxV4xKjfI77CUF6ezv4p5+1DwP3jbG/jPjFgskfUtfEHjP04N
aIpbbW204hAc4k6bWvRnGbEum+vXuYd318f8R7JzdEtJ1MVvv/DQt1JxQw8FPfUN
nLKv4tmHxqnQWIMktgqenT73t51eOFpdtEBcXnQvWk9XtiLfA8LQZ8b531ZogbU=
=CdQG
-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/1cdfa840052c4f00905bce0360c94545%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[rysiek]

Dnia Monday, September 18, 2017 10:56:33 AM CEST Micah Lee pisze:
> Qubes security domains don't necessarily help solve this problem because
> really the problem is how your web browsers are configured.
> 
> So a tracking company can't link your browsing activity between Qubes
> domains -- your "personal" traffic and "work" traffic might look like
> two separate people -- but within one of those domains, they can still
> track you, and do all of those tricks.
> 
> If you want web privacy, you'll have to configure your browser within
> Qubes the same way you have to outside of Qubes. Or, you can do all of
> your browser in DisposableVMs. Or use Tor Browser, which has taken many
> steps to prevent browser tracker as a design goal.

Damn, beat me to it!

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

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


signature.asc
Description: This is a digitally signed message part.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[rysiek]

Hey,

Dnia Monday, September 18, 2017 9:43:15 AM CEST jes...@gmail.com pisze:
> In the past I have used a Firefox plugin called "Better Privacy" to try to
> push back against multi-front user fingerprinting and analysis mechanisms
> such as the kind used by large advertising and user demographics companies
> which include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et
> al to confirm that the same user is browsing along a website or a
> distributed ad network even when they "clear private data" or use incognito
> mode, even when they switch to different browsers installed on the same
> machine, even if they're using coffee shop wifi or VPNs so that they appear
> from different IP addresses, etc.
> (...)

O..k. Straight from the bat, why not Incognito/Private window?

I mean, on my non-Qubes system I have a "work" browser (a normal Firefox 
window, keeping sessions, accepting cookies, etc); and a "fun" browser 
(Chromium Incognito) for everything that I am concerned might track me.

On Qubes, the disposable VM is probably what you're after. But remember, even 
in an incognito window or in a disposable VM, you can be tracked as long as 
the session lasts (i.e. until you close the browser, or reboot the VM).

> So I am curious to what extent Qubes security domains may be sufficiently
> complete as to defeat potentially all of these mechanisms simultaneously?
> Especially if end-user configures one or more domains to pipe all network
> traffic over a VPN or tor to additionally differentiate their IP address?

Most of these mechanisms are browser-bound. Use the browser in your disposable 
VM. Using it through a VPN or Tor is a good idea too.

> I am especially interested to hear about how Qubes security domains interact
> with Flash LSOs, and .. whatever-it-is that Silverlight and other
> multi-browser plugins do, and whether *that* data leaks between domains. :/

Think of each AppVM as a separate machine yoiu're running stuff on. Flash/
Silverlight/etc do not have a way to break out of a VM.

> Thank you for any insight you guys may have on this matter, as it sounds
> like it speaks directly to Qubes primary mission goals of security by
> compartmentalization. :D

Compartmentalization does not do much for anonymity. As in, you can use Qubes, 
and be tracked through each of your AppVMs. You'll have three "identities", 
but all of them will be tracked, since regular AppVMs keep state (including 
browser cookies, etc, unles sthe browser is explicitly configured otherwise).

To combat tracking, I would use the Incognito/Private mode in your browser, or 
a browser in a disposable VM in Qubes. Or both.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

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


signature.asc
Description: This is a digitally signed message part.

Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[Micah Lee]

Qubes security domains don't necessarily help solve this problem because
really the problem is how your web browsers are configured.

So a tracking company can't link your browsing activity between Qubes
domains -- your "personal" traffic and "work" traffic might look like
two separate people -- but within one of those domains, they can still
track you, and do all of those tricks.

If you want web privacy, you'll have to configure your browser within
Qubes the same way you have to outside of Qubes. Or, you can do all of
your browser in DisposableVMs. Or use Tor Browser, which has taken many
steps to prevent browser tracker as a design goal.


On 09/18/2017 09:43 AM, jes...@gmail.com wrote:
> In the past I have used a Firefox plugin called "Better Privacy" to try to 
> push back against multi-front user fingerprinting and analysis mechanisms 
> such as the kind used by large advertising and user demographics companies 
> which include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et 
> al to confirm that the same user is browsing along a website or a distributed 
> ad network even when they "clear private data" or use incognito mode, even 
> when they switch to different browsers installed on the same machine, even if 
> they're using coffee shop wifi or VPNs so that they appear from different IP 
> addresses, etc.
> 
> The take home being that it only takes one (1) fingerprint hit through one 
> (1) of the avenues available to tracking organizations to confirm that they 
> are dealing with the same end-user (or household unit, or something close 
> enough to pad their toxic dossier with) and thus to link every cookie 
> fingerprint that they know for this user across both domains under the same 
> umbrella.
> 
> A pretty thorough look at all of the strategies that I am at least aware of 
> can be had at this url: 
> https://www.chromium.org/Home/chromium-security/client-identification-mechanisms
> 
> So I am curious to what extent Qubes security domains may be sufficiently 
> complete as to defeat potentially all of these mechanisms simultaneously? 
> Especially if end-user configures one or more domains to pipe all network 
> traffic over a VPN or tor to additionally differentiate their IP address?
> 
> I am especially interested to hear about how Qubes security domains interact 
> with Flash LSOs, and .. whatever-it-is that Silverlight and other 
> multi-browser plugins do, and whether *that* data leaks between domains. :/
> 
> Thank you for any insight you guys may have on this matter, as it sounds like 
> it speaks directly to Qubes primary mission goals of security by 
> compartmentalization. :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/3e9cdccf-488c-fa1e-2bf0-b70c835108c5%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

[jesset]

In the past I have used a Firefox plugin called "Better Privacy" to try to push 
back against multi-front user fingerprinting and analysis mechanisms such as 
the kind used by large advertising and user demographics companies which 
include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et al to 
confirm that the same user is browsing along a website or a distributed ad 
network even when they "clear private data" or use incognito mode, even when 
they switch to different browsers installed on the same machine, even if 
they're using coffee shop wifi or VPNs so that they appear from different IP 
addresses, etc.

The take home being that it only takes one (1) fingerprint hit through one (1) 
of the avenues available to tracking organizations to confirm that they are 
dealing with the same end-user (or household unit, or something close enough to 
pad their toxic dossier with) and thus to link every cookie fingerprint that 
they know for this user across both domains under the same umbrella.

A pretty thorough look at all of the strategies that I am at least aware of can 
be had at this url: 
https://www.chromium.org/Home/chromium-security/client-identification-mechanisms

So I am curious to what extent Qubes security domains may be sufficiently 
complete as to defeat potentially all of these mechanisms simultaneously? 
Especially if end-user configures one or more domains to pipe all network 
traffic over a VPN or tor to additionally differentiate their IP address?

I am especially interested to hear about how Qubes security domains interact 
with Flash LSOs, and .. whatever-it-is that Silverlight and other multi-browser 
plugins do, and whether *that* data leaks between domains. :/

Thank you for any insight you guys may have on this matter, as it sounds like 
it speaks directly to Qubes primary mission goals of security by 
compartmentalization. :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/2c1d96d1-14f9-4522-b4e1-169da312e756%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users]

[Rob Ward]

-- 
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/CACStXkA5%2B9jYPGcTRQcCjzpGj1%2BwntAOz%2BEDSBMLAk4%2BRzF_iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Authenticating a repo?

[Stumpy]

Hi, I wanted to install icecat so I thought that it would be best to add 
the repo so that updates would be automc. I went thorough the steps 
which workd but it gave me the warning first that the repo was not 
authenticated and that it was a bad idea so I tried, and I dont know so 
much about authenticating, to download there pgp key, 
http://archive.trisquel.info/trisquel/trisquel-archive-signkey.gpg
and move the key over to my templatevm then add it, I am not so sure 
about how to add it, I tried

sudo apt-key add trisquel-archive-signkey.gpg
it said ok so I thougth all was good but when I tried to update the 
template It told me:


W: GPG error: http://mirror.fsf.org/trisquel toutatis-updates InRelease: 
The following signatures were invalid: 
E6C27099CA21965B734AEA31B4EFB9F38D8AEBF1
W: The repository 'http://mirror.fsf.org/trisquel toutatis-updates 
InRelease' is not signed.
N: Data from such a repository can't be authenticated and is therefore 
potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.


I looked over the man page but its a bit much for my brain. I am 
thinking that I did not add it the right way but can someone verify that 
and let me know the rite way?

Thx so much.

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

[qubes-users] Recording screen of appvm

[Stumpy]

Hi, I have been trying to record (vid/snd) a AppVm window with little 
luck. I recently tried recordmydesktop, installing it on the appvm I 
wanted to record, and it just about borked my system, like the entire 
screen turned white and I couldn't bring up a term win, or swtch to any 
other appvms, the menu, *or* dom0. ugh! (had to ctl+alt+F2 to a term and 
kill the process from there, and that took about 5 min of sweating until 
I remembers that key combo).
I am now a bit worried about trying things out willy nilly. I found a 
post about screen recording but the ultimate solution, 
https://groups.google.com/d/msg/qubes-users/BDkZXBWnuQc/McU7_e8BAwAJ, 
seemed a bit over my head and I dont think it recorded sound, and I 
think its meant 4 recording all windows from dom0? Which I dont need, 
just one appvm.

Is there a, ahem, 'simple' way to record the snd/vid of an appvm?
Thx!

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

Re: [qubes-users] Re: Setting up firewall for mail and seeing traffic for individual appvms?

[Stumpy]

On 18.09.2017 01:45, Unman wrote:

On Sun, Sep 17, 2017 at 11:46:53PM +0200, Stumpy wrote:



On 17.09.2017 23:41, Frosty wrote:
> Hi Stumpy,
>
> Are you using sys-whonix to enter the internet? If yes you probably
> have to open port 9000 on the firewall, because tor traffic goes
> trough port 9000
>
>
> Regards.
>
>
> On 09/17/2017 11:36 PM, Stumpy wrote:
> >
> >
> > On 17.09.2017 23:34, Stumpy wrote:
> > > One of the many things on my checklist is to setup some of my appvms
> > > with proper fw rules. I thought I'd start with gmail that I use
> > > with a
> > > mail client. I thought it would just be:
> > > smtp.gmail.com
> > > imap.gmail.com
> > > and set it for smtp and imap services using tcp protocol.
> > > Afaik those are the two servers that the client connects to, its what
> > > I have set in my client but it seems I haven't set something right
> > > because the client can't send/recive anything.
> > >
> > > So two questions:
> > > 1) Is there something I am missing with the above settings and
> > > 2) Is there a way I can see the incomming/outgoing traffic for this
> > > one appvm? (which I am guessing would help give me a better idea of
> > > what servers/addresses I need to add to my firewall).
> >
> > duh. I forgot to also mention that I do have the "deny network
> > access except" raido button chked
> >


Hi Frosty,

Thx 4 that.

in This case I am not using whonix but I did plan on setting up some 
of my

whnx appvms/firewalls later so that might come in handy.
Regarding ports, is there a GUI way to add ports, ie vm manager -> 
firewall

dialog box, or does that require editing ip tables?

Cheers


Hi Stumpy

One problem that you face is that those names map to a number of
different IP addresses.
When you use a name in the firewall editor it is resolved when you set
up the rule to 1 IP address. You should therefore make a note of the IP
addresses and use them in the editor.

The entries you make here are reflected in the FORWARD chain of the
proxy upstream. You can inspect these by opening a terminal in that 
qube

(e.g sys-firewall) and using 'iptables -L -nv' - look in the FORWARD
chain and you sill see entries for the mail qube. You should also be
able to see the counters incrementing when you try to make a 
connection.


unman


Hey Unman,
Thx for the detailed explaination/howto. I will def give those a try!
Cheers

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

Re: [qubes-users] Qubes 4.0-rc2 release

[Unman]

On Mon, Sep 18, 2017 at 05:24:13AM -0700, Mirosław Wojciechowski wrote:
> Dear Qubes Team,
> 
> I have one small question.
> 
> Today is it a day when you release the new version of Qubes OS (4.0-rc2)?
> I ask because I do not know whether to install or wait.
> 
> Regards,
> 
> MW 
> 

Marek has just posted to qubes-devel saying that it will be delayed for
2-3 weeks to complete testing of PCI pass-though to HVMs.
Everything else is in testing repository, so you could update from
there.

unman

-- 
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/20170918125944.m2dbsayhgwpjer5e%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0-rc2 release

[Mirosław Wojciechowski]

Dear Qubes Team,

I have one small question.

Today is it a day when you release the new version of Qubes OS (4.0-rc2)?
I ask because I do not know whether to install or wait.

Regards,

MW 

-- 
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/326ba1d1-2167-4ebe-8a49-4e399087bdde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Reboot a VM that is connected as net/proxy VM

[mittendorf]

Well, I experience this issue several times a week.

On 09/14/2017 10:29 PM, Adrian Rocha wrote:
> Hi,
>
> Yes, I agree
>
> It isn't a critical issue, but is too annoying to restore the VMs connections 
> after this type of situations
>

-- 
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/188bf5ba-d275-8538-4ccb-6b615d12c20a%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.