[qubes-users] Re: Printer recommendation / scanner implications?

[Jean-Philippe Ouellet]

On Thu, Oct 14, 2021 at 3:11 PM Jean-Philippe Ouellet  wrote:
> As for firmware security: I assume all printers are probably
> vulnerable (and/or backdoored?) beyond any hope of being reasonable,
> and would like to put a simple trusted device in front to force all
> incoming data to be printed to go through something like the Qubes
> trusted PDF converter, to sanitize whatever fun PDF / postscript /
> whatever exploits might otherwise reach the printer.

This, naturally, implies that I consider wireless connectivity to be
an anti-feature, in that it represents an opportunity to bypass any
trusted document-structure sanitizer / re-encoder / isolation box.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_A9pTRpY0YR9A2aF%2Bpbn%3Dk3TFc2-w2%2BQ20Gwxp1cGMCMw%40mail.gmail.com.

[qubes-users] Printer recommendation / scanner implications?

[Jean-Philippe Ouellet]

Hi,

I figure someone on this list might have done some research from a
perspective sharing similar goals.

Does anyone have a recommendation for a reasonable printer?

My rough objectives are as follows:
1. "Well-supported by linux." In practice I imagine this means
speaking standard protocols, or needing some FOSS CUPS plugin packaged
in the usual repos. Essentially, as long as it's not some
windows/mac-only proprietary nonsense, or GUI-requiring linux blob,
then it's probably good enough.
2. Does not persist printed pages in internal storage, intentionally
or otherwise. No "re-print last page(s)" anti-feature, or similar. I
think ultimately a deliberately "stateless" printer is really what I
desire, but I'd be surprised if those exist beyond perhaps some very
old simple ones with non-network (think parallel port) interfaces and
non-updatable firmware that is somehow trustworthily write-protected.
(Which sounds great, tbh, I'm just not aware of any like that nor
where to get them besides maybe getting lucky in an auction.)
3. Has economical and shelf-stable consumable parts (ink, toner,
etc.). Probably means laser printer?
4. Doesn't take forever to print things and jam every other page.
Probably means laser printer?
5. Color would be nice, but optional.
6. Lack of "printer dots" [1], or similar (font-mutation steganography
[2], if that's a thing now?) would be nice. Do any such machines even
exist these days? (Besides firmware reversing & removal of said
"feature" yourself, I suppose...)
7. Minimizing contribution to aggregate demand for production of
eventual waste. DRM'd ink cartridges and similar are dumb, and as much
as I'd welcome the challenge to defeat them, I don't want to spend my
time doing that right now. An abundance of the actual printers on
2nd-hand markets would be nice, or, if new, something expected to be
reliable and last a long time to amortize the cost of its production.
I'd be perfectly happy with some model already 10 years old as long as
they're available, reliable, and the consumables for it are still
available and/or self-refillable.

As for firmware security: I assume all printers are probably
vulnerable (and/or backdoored?) beyond any hope of being reasonable,
and would like to put a simple trusted device in front to force all
incoming data to be printed to go through something like the Qubes
trusted PDF converter, to sanitize whatever fun PDF / postscript /
whatever exploits might otherwise reach the printer.

A scanner would be nice too. I haven't thought through all the
implications of whether having a discrete scanner & printer vs.
combined unit has a meaningful impact on my threat model. There's the
obvious implication that a compromise of one may steal data from or
exfiltrate data via the other, but then, would such a mechanism need
to be targeted to avoid obvious accidental detection? How might a
likely targeting activation mechanism work? I'm sure it might be
interesting from an attacker's perspective to have a built-in
side-channel between them, but hopefully network (/usb) isolation and
sanitizing input documents would break any likely print-job command &
control vectors besides those which would rely on image processing
(which feels less likely)? Unclear. Thoughts on this welcome too.

Regards,
Jean-Philippe

[1]: https://en.wikipedia.org/wiki/Machine_Identification_Code
[2]: http://www.cs.columbia.edu/~cxz/publications/fontcode.pdf

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_AETmn3gqFZV2mNPnjevdtb2wY2HdW9ho7KKe7nH8KGAA%40mail.gmail.com.

[qubes-users] Excessive swapping & non-optimal qmemman heuristics

[Jean-Philippe Ouellet]

Hey all,

Am I the only one who seems to have noticed chrome reaching max mem &
swapping way more often than used to happen in the past? Some of my
workflows result in having a bunch of tabs (not even _that_ many,
maybe 20-30+) open in DispVMs. Unfortunately, this reaches the 4gb max
pretty quickly, and causes swapping, which results in the whole VM
becoming pretty unusable (can't even interact with it enough to close
tabs - often end up doing qrexec calls to pill the highest-mem chrome
renderer process - essentially me being a manual OOM killer).

I've also noticed some VMs getting more memory than it makes sense,
for example minimal VMs that just have a text editor, some notes, and
a few terminals open often end up with 1200mb+ pre-allocated when they
have no reason to need that much, which results in not having enough
unallocated mem to be able to start new domains unless you shutdown
VMs (that have accumulated large allocations while still having a
small user-meaningful working set).

Qubes has always been memory-hungry, and I've always considered it a
worthwhile tradeoff, but now I feel like I need to upgrade to a 32gb
machine just to run a couple browsers - this is getting ridiculous.

I'm going to look into this more systematically (first try tweaking
the qmemman algo, then maybe experiment with tmem), but I figured I'd
just rant here first in case anyone happens to have looked into this
already (beyond the usual "limit dom0 & sys-* maxmem" which seems to
always get parroted whenever this subject comes up).

Cheers,
Jean-Philippe

P.S.: Here's a script to tail qmemman's logs while translating from
xen domain IDs to VM names (because qmemman is purposefully simple for
reliability, avoiding taking a dependency on qubesd nor making extra
xc calls to get the name, so doesn't do this translation itself). Has
been helpful in seeing what's going on when things aren't behaving as
expected:
#!/bin/sh
journalctl -f -n 100 -u qubes-qmemman \
| sed -u -r 's/\.[0-9]+//g' \
| $(
qvm-ls --raw-data --fields xid,name \
| grep -v '^-' \
| sed -u \
-e 's/^/-e s\/([^0-9:])/' \
-e 's/|/([^0-9])\/1/' \
-e 's/$/2\/g/' \
| xargs echo sed -u -r
) \
| sed -u -r \
-e 's/([^[p])([0-9])[0-9]{3}([^0-9]|$)/\1\2k\3/g' \
-e 's/([0-9])[0-9]{3}k/\1m/g' \
-e 's/([0-9])([0-9])[0-9]{2}m/\1.\2g/g'

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_Dwpvxgghf4F2N7cLgbCgZGW9%3Dr2fM1jeDQxQRGhkwN0w%40mail.gmail.com.

Re: [qubes-users] Any virtualizer / emulator working in Qubes OS?

[Jean-Philippe Ouellet]

Currently: anything that doesn't require nested virt, meaning anything
that actually emulates instead of trying to use vmx (via kvm, etc.).

Examples include qemu using its tcg backend instead of kvm, and bochs.

On Thu, Sep 19, 2019 at 11:58 AM Patrick Schleizer
 wrote:
>
> Is there any virtualizer / emulator working inside Qubes OS 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/2d7d4f20-b255-ed3b-30ef-7b98bfd44e69%40whonix.org.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_DASxRUbSMJNJFPbWiN--OGXM_fhtONFKyvW5fOibVnTg%40mail.gmail.com.

[qubes-users] Portable external laptop monitors?

[Jean-Philippe Ouellet]

Hello,

I'm curious if anyone has tried using any portable eternal laptop
monitors in Qubes, like the DisplayLink-powered USB ones?

Some examples of the kind of monitors I'm talking about:
- ASUS MB169B+ -- https://www.asus.com/uk/Monitors/MB169BPlus/
- ASUS ZenScreen MB16AC -- https://www.asus.com/us/Monitors/MB16AC/
- AOC E1659FWU -- http://us.aoc.com/en/products/e1659fwu

They seem appealing to me because it seems they can get power and
signal from a single USB port, and be easily thrown in a laptop bag.
These all seem to be driven by DisplayLink [1], which seems to have at
least some WIP linux support.

Of course, having your *output* devices also attached via your
ideally-untrusted USB controller opens up a whole new world of
possibilities not previously reasoned about in my threat modeling,
especially on laptops where the input devices are rather unfortunately
internally attached via only the same single USB controller, but it
would definitely be an interesting possibility to explore regardless!

Has anyone tried such devices? Anything interesting to report with
respect to Qubes support, or even just Linux support generally?

There would of course be lots of details to figure out, but I would
ultimately be interested in passing through such a device to a
only-partially-trusted USB/GUI VM which could only view/render a
subset of my graphics, thus allowing me to benefit from the extra
screen real-estate for non-sensitive work while still trying to ensure
that I could not accidentally allow a malicious monitor to e.g.
screen-scrape my vault VMs, as well as isolate dom0 from exploits in
the USB/graphics stack. There is at least some communication from a
display back to a host [2][3] (and almost certainly more that I am
unaware of), and I bet there are some interesting and unexplored
potential attack vectors for a malicious display trying to compromise
an attached host.

Regards,
Jean-Philippe

[1]: https://en.wikipedia.org/wiki/DisplayLink
[2]: https://en.wikipedia.org/wiki/Extended_Display_Identification_Data
[3]: https://en.wikipedia.org/wiki/Display_Data_Channel

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

Re: [qubes-users] HCL - 20HRCTO1WW Lenovo Thinkpad X1 Carbon

[Jean-Philippe Ouellet]

On Wed, Jan 23, 2019 at 11:45 PM Berne Campbell
 wrote:
>
> Lenovo Thinkpad X1 Carbon 20HRCTO1WW
>
> I had to disable secure-boot to boot of USB stick for installation (Used 
> Rufus in Windows in DD mode, MBR partition scheme). Perhaps a signed shim 
> could be used to ease installation.
>
> Builtin LCD display is working
> Internal Keyboard is working
> TrackPoint (including scrolling) is working
> TrackPad is working
> Wireless networking is working
> Battery/AC power monitoring is working
> Bluetooth doesn't due to Qubes OS Security stance on BT
> Bluetooth mouse connected via USB cable is not working - not sure if it has a 
> wired-mode or if its just for charging.
> Hot Keys: -
>   - Volume Up, Down, Mute working
>   - Microphone Mute not working
>   - LCD Brightness Up/Down is working
>   - Display (external/mirror/etc) is working (brings up display dialog)
>   - Wireless/RF kill button is not working
>   - Settings button not working
>   - Bluetooth button removes/adds USB device (8087_0a2b)
>   - Keyboard button (F11) does nothing
>   - Star button (F12) does nothing
> Keyboard backlight works (Fn+Space)
> USB Mass Storage works
> Internal mass storage NVME works
>
> So far, looking good. Thanks for the hardwork ITL and the Qubes OS team.
>
> I'm happy to share further details.
>
> Cheers,
> Berne

Does it have stable suspend/resume? Roughly how many cycles have you
put it through?

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

[qubes-users] Lenovo BIOS update hashes (was: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB))

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 3:40 AM Jean-Philippe Ouellet  wrote:
> The latest BIOS hashes I observe are:
> $ sha256sum n1*17*
> 4b5488be128d9c022cd4924476d48e38dd55c38809db0f3a6c06f1a2d2ad0217  n1fuj17w.exe
> 918c836905db7709433b4dc03eddcbb04ccb8773f31f5b22b5b92388b56a3002  n1fuj17w.txt
> 5e5f9cfec0dcb299a033be0b4006af8697045876c4ef18a34716b894c48b917b  n1fur17w.iso
> 1dcdf1ffd2cd30be225db49e8210de2dabba32c5aaf3179a89e3d8f0cca61f3a  n1fur17w.txt
>
> Obtained from:
> https://download.lenovo.com/pccbbs/mobiles/n1fu{r{01..17}w.{iso,txt},j{01..17}w.{exe,txt}}
>
> Downloaded from multiple network positions over multiple days with
> matching hashes.

Bumping this...

If anyone sees differently, I would love to know.

I now observe the following hashes:

378a6305edb9397978e60b7908a85dd8c2546f2808cb845552d5e4a8ba9baab3  geteltorito.pl

c1097a887cff07ef1f67edb8b7dabff0e3005c2251116c0754e5eb0830f32430  n1fuj01w.exe
cf6b5ab8fa0d8a99ffb74b74d6c94c3fbe48708ffb29ef41e07a23e148b297ef  n1fuj01w.txt
cd9c4a2df77f6108474cc1e17e6f1170a0e03e7bc256d800f5258c3346c93e49  n1fuj02w.exe
eec6b405f6ceae42612d8b62ae25096cd30f43dc4689ebe840280d435947764c  n1fuj02w.txt
58c0b4bc74663a548713b9922b4db70151279407f9bdf3ef418002a09ef4a9d3  n1fuj03w.exe
622f9cb43bc4d4a19af52975be68dcc37d20ac691602f4ac1714986c3a537b02  n1fuj03w.txt
7c505961e2745ec31a4a993a1031e975a0827f773575a2405a883a08d8a4452e  n1fuj04w.exe
9eff5cdd020656a5665532a1f7cb37882793f6a5740b90d815fddf17dd394f9a  n1fuj04w.txt
510abd4ba7e3c185c13d19eab76b96d1340deee25a47f81a5c47fa1bf6f7f62c  n1fuj05w.exe
4bd87344f2f3bf8ac8f5ad52ed2362cd144631ead66cafa82027053a0d25f713  n1fuj05w.txt
8934bc9b00b3aab1d6044e0fc1f843cd7812ec90c8d4a8c594247d6f9c8cc5c2  n1fuj07w.exe
3762fe8ac73a687d9cfd41503b2b4b6f225761e5275892da9744ac5d84d6b96c  n1fuj07w.txt
9aca522cad73123054a351699108d3c2c492eaf0c8466a85aef3cd598910ed8a  n1fuj08w.exe
ef1c8620d7b8e89be88f8230a4707340213c8e44db38008a10bcee1e5ecffe2e  n1fuj08w.txt
5fdfc28923ea4fd0908bcd877cbe08971f65db954aa30d3fc0066c9ab98da508  n1fuj09w.exe
a969a9c5c2cb1887fc8552ba70dc5873bcaecda9601fdba47496b0e37591b02d  n1fuj09w.txt
294e47c8f3435cf2b0d43aef733347ab6fd8494dcda04df2eac2d3f1d4c9cbea  n1fuj10w.exe
7ed28a40f7944462e67a18ae87e7f2d5edb9ee95e94899f9e7f05fa5b63a4081  n1fuj10w.txt
0b255f1e411506564e17f6c958033e3ab65536580bd818a5992caecc7301dbf5  n1fuj11w.exe
a67d94483ce16318dc8e17611cf38565304dc96a790577669ea90070a9406fd9  n1fuj11w.txt
0e13111e41f0ae79c0941865ee9647a19b698368ae71d1fca81f35a837463b85  n1fuj12w.exe
c10ed88917a7f8779059a07e9f517b925a2ba714040518f019293728bbe4b0eb  n1fuj12w.txt
903196dbf8203c322698b47236ba0bae7ba90289f393388a2a309c50374380c6  n1fuj13w.exe
e13fdf934c2e876741ee1334319935ae068dd25074323fd62d13f036ad942e11  n1fuj13w.txt
06074abd89cc023f0e815ea6375bf96649cfebea358be29ddd0f91bf3afe47f2  n1fuj14w.exe
c940dc7bf33fca19d23d755d3148ef52669dbb32b9f7762de70e3b95993faff9  n1fuj14w.txt
ce7c38435511a332d6c3ea8fd3291f7fff5815d1b73be0b01eea5c38229609c5  n1fuj15w.exe
83b2a8a17be3e0e23465d419c130e389ea3134d3d4fbfd3b6d38962651e3  n1fuj15w.txt
e069a8cd0e4f01da260085eac3742123f0f05f33dc476bd4820cead9ce54b9d7  n1fuj16w.exe
49bbe527d17937dcb5cd5e0a5abd565a712b4b0d44eb6c78aaffcac2f558c4e7  n1fuj16w.txt
4b5488be128d9c022cd4924476d48e38dd55c38809db0f3a6c06f1a2d2ad0217  n1fuj17w.exe
918c836905db7709433b4dc03eddcbb04ccb8773f31f5b22b5b92388b56a3002  n1fuj17w.txt
cde452963d3a12a9375f1ccd5b8f9db113e285bd76cc099d89c037b46204a7dd  n1fuj18w.exe
4d8ac7a3200b73f19c724bcc9f06e5caf626121ee77dd157505eae0a14f8249d  n1fuj18w.txt
261375c8609331ee2f3adc2c5aaf968ddc501f2b5a6161156d2393e08a0366c7  n1fuj19w.exe
443a60ee8ff7cedcbd66d2fd1e2d69392e1eaaae3ae32507f680526c77fa04b5  n1fuj19w.txt
5b3079c922a4210c0a19bf3b7ea7a44310810109c8865d1ddfb202d26e1303d8  n1fuj20w.exe
65ad67bbdcb31ff87588b3a15705150c044ac1ff79dde726e39349c345e49eaa  n1fuj20w.txt
f77453a0d42fa4a4bcbec51085c7f7b9a72224f220fad8649cbc854e4e4ea10e  n1fuj21w.exe
7434c1debd14a1aee071a15a2ba082f47209766d77a0828b3e9b4801cc24afa1  n1fuj21w.txt
0e7e771e31002f27fd313c9d142fde491c8639092cf8a3d7c150010af3575722  n1fuj22w.exe
8d3f40bf296984d07c9cee53ea15b4f12c1129898bc5f83415e3ddf003c42a6c  n1fuj22w.txt
25494ccbf473437769eb71e9dc1639440460421c54318184cc2ad3ddf7a9b00a  n1fuj24w.exe
ef4ab767f78c42c549751b905d34b687328d71c5d86483d4cec24f6c61f97be8  n1fuj24w.txt
2ef53f0a56109da13b27996ce0fd56d01cc4ddfe8c45f3d304fd5ddd4172f9b2  n1fuj25w.exe
14c4e07bfd4fa0a50936c82135a3a9f06ada6b2213e86f54e9ec271c660f0b1a  n1fuj25w.txt
c7347f4ac6ad5c9fc460166907136b15d07ad50cae33cccdf2c36dac9efc78bc  n1fuj26w.exe
bce85d5fe3009305085b9fa0b91650a28f11871abcd00dca1e8a1a309e57b927  n1fuj26w.txt
104608e2de978e38d1813dc6427961b0f112fbb89f899423c46647eff4bfb294  n1fuj28w.exe
ae73d24a1fa7521f426dd778e3eb3f8603be158cf53ee70e30be724d32aeea54  n1fuj28w.txt
df3fb0d57cec4a979abcd7dd1a6ecb98f89089545127a9a4affefbe76756ccb6  n1fuj29w.exe
f4711a5f16157049b266f475a62cf52d96398090a7

Re: [qubes-users] How to use sudo/nm-applet in qubes 4.0 in fedora-2X-minimal

[Jean-Philippe Ouellet]

On Mon, May 28, 2018 at 7:04 AM  wrote:
>
> I installed qubes-template-fedora-26-minimal, upgraded it to release version 
> 28 (paid attention to the python2-xcffib bug) and cloned it to make a 
> network-"for-all-things-networking"-VM-only template.
>
> So far, as written in qubes documentation->fedora-minimal, I installed the 
> networking related packages to let the template act as a 
> minimal-networking-stuff-template. But nm-applet is not authorized to control.
> And here we stops, because it seems that qubes-core-agent-passwordless-root 
> and/or polkit is always necessary. (?)
> But because of a choice of design in Qubes 4.0, it is not installed as 
> default. Whereas qubes-core-agent-systemd and qubes-core-agent-qrexec are 
> installed by default as written in the documentation.
> What is the mind behind this choice? Just asking out of sheer curiosity.
>
> The package polkit depends on spidermonkey javascript stuff (mozjs52 
> package). 6.5MB of not relevant stuff for just an networking VM. Because it 
> works except the nm-applet authorization thingy.
>
> "nmcli general permissions" gave me a timeout as fedora-minimal AppVM user.
> Can I get around this by adding the user to a specific group to get the 
> rights to use nm-applet as an user? A search gave me answers to a nm-applet 
> bug in 2015: 
> https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00033.html
>
> There is a hint that NM uses polkit and/or systemd. But only polkit is not 
> installed (I guess). An advice someone wrote in the link:
> "Alternatively, if you don't care about user permissions and want to
> allow any user to control networking you can build NM with
> --with-session-tracking=none and --with-polkit=no to disable this
> functionality."
>
> I guess, this would be a workaround to get the minimal networking VM to fully 
> work, am I correct?
> This should be the same behavior as qubes' passwordless-root just for NM and 
> with less packages - or is this way intending that anyone (even nobody-user, 
> if existing) could handle NM but do not get any other root files like write 
> to /rw/ in the NetVM and is therefor less "secure" than 
> user-polkit-passwordless-root installation and interaction!?

Yep, looks like polkit is indeed required :(

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

Re: [qubes-users] Re: QSB #43: L1 Terminal Fault speculative side channel (XSA-273)

[Jean-Philippe Ouellet]

On Thu, Sep 6, 2018 at 8:28 AM, 'awokd' via qubes-users
 wrote:
> On Tue, September 4, 2018 2:05 am, pixel fairy wrote:
>> On Monday, September 3, 2018 at 1:21:27 AM UTC-7, Marek
>> Marczykowski-Górecki wrote:
>>
>>> On Mon, Sep 03, 2018 at 01:46:11AM -0500, Andrew David Wong wrote:
>>>
 On 2018-09-02 22:22, pixel fairy wrote:

> is it still necessary to disable hyper threading after upgrading in
> qubes 4?
>

 Hyper-threading should be disabled in Xen after you install the
 updates. It should not be necessary for you to take any further action
 to disable it there.

 If you're asking whether you should also disable it in your BIOS
 settings, then I'm not sure (CCing Marek).
>>>
>>> There is no need to additionally disable it in BIOS. Xen's smt=off
>>> option means it won't be used even if BIOS reports its availability.
>>
>> Is this something that can eventually be resolved, allowing safe
>> re-enabling of hyperthreading? or is that even known yet?
>
> You could try asking Intel to replace these defective CPUs. :)

Or not, and ask for docs instead: https://www.bunniestudios.com/blog/?p=5127

Good luck in either case though ;)

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

Re: [qubes-users] Re: Unable to reset PCI device 0000:02.00.0

[Jean-Philippe Ouellet]

On Tue, Sep 4, 2018 at 9:17 PM, Patrick  wrote:
> On Sunday, September 2, 2018 at 3:34:34 PM UTC-4, Jean-Philippe Ouellet wrote:
>> On Sun, Sep 2, 2018 at 10:12 AM, Patrick Bouldin
>>  wrote:
>> > On Sunday, September 2, 2018 at 10:10:55 AM UTC-4, Patrick Bouldin wrote:
>> >> Qubes 4.0 Error - "Start failed: Requested operation is not valid: PCI 
>> >> device :02:00.0 is in use by driver xenlight, domain sys-usb
>> >>
>> >> I don't know how to copy the log folder over and qubes doesn't have the 
>> >> wireless network, which I believe is related, but I've attached a picture 
>> >> of the log.
>> >>
>> >> This is a new Qubes install on a new Acer laptop Aspire A515-51-86AQ
>> >> Booting in legacy mode.
>> >>
>> >> I can get into the main desktop and get to Dom0 terminal, but can't 
>> >> launch any of the default domains.
>> >>
>> >> There is another thread on here with the same error. He ran:
>> >> $ qvm-pci attach --persistent --option permissive=true --option 
>> >> no-strict-reset=true sys-net dom0:00_XXX
>> >>
>> >> And it worked for him, but doesn't work for me, the response I get is 
>> >> "error : backend vm "dom0" doesn't expose device "00.XXX"
>>
>> The "XXX" in the PCI device should be filled in with your actual PCI device.
>>
>> >> So I wonder what "xenlight" is and it won't release what pci device?
>>
>> Just a library for interfacing with Xen. Unlikely to be the actual problem.
>>
>> >> Suggestions?
>> >>
>> >> Thanks,
>> >> Patrick
>> >
>> > Pics attached here.
>>
>> It would be the first time I've seen this, but it might perhaps be
>> conceivable that changing BIOS settings caused your device to show up
>> with a different BDF (essentially "PCI address") than when Qubes was
>> installed? Use `lspci` in dom0 to enumerate them.
>>
>> An easier way than doing this via the command line is to use the
>> Devices tab of the Qubes VM Settings GUI - remove all devices then add
>> the one which looks like your network device. You can also configure
>> no-strict-reset via the button at the bottom of the GUI, which is
>> sometimes necessary.
>
> Wow you really know this stuff. Thanks to your advice I was able to piece it 
> together. I confirmed as you said, then was able to start booting the VMs 
> based on using PVM and removing all the device elements. I'm sure I've got a 
> lot of experimenting to go but the basics are there with wireless.
>
> Thanks so much,
> Patrick

Glad it was helpful!

Also, in case you weren't already aware, VMs to which you wish to
assign PCI devices currently need to be in HVM mode (meaning: assisted
by a Qemu stub-domain for device-model emulation). This requirement
should be removed in the future, but there are Xen issues to work out
before we can fully ditch it and switch to PVH everywhere (meaning:
without Qemu and its associated attack surface and per-VM CPU/memory
overhead).

To check the virtualization mode:
[user@dom0 ~]$ qvm-prefs sys-net virt_mode
hvm

To reset the mode to default (which should automatically be HVM for
VMs with PCI devices and PVH otherwise):
[user@dom0 ~]$ qvm-prefs -D sys-net virt_mode

If you need to explicitly set the mode, you can do so (possibly
replacing "hvm" with "pvh" or the very-deprecated "pv"):
[user@dom0 ~]$ qvm-prefs sys-net virt_mode hvm

Cheers,
Jean-Philippe

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

Re: [qubes-users] Re: Unable to reset PCI device 0000:02.00.0

[Jean-Philippe Ouellet]

On Sun, Sep 2, 2018 at 10:12 AM, Patrick Bouldin
 wrote:
> On Sunday, September 2, 2018 at 10:10:55 AM UTC-4, Patrick Bouldin wrote:
>> Qubes 4.0 Error - "Start failed: Requested operation is not valid: PCI 
>> device :02:00.0 is in use by driver xenlight, domain sys-usb
>>
>> I don't know how to copy the log folder over and qubes doesn't have the 
>> wireless network, which I believe is related, but I've attached a picture of 
>> the log.
>>
>> This is a new Qubes install on a new Acer laptop Aspire A515-51-86AQ
>> Booting in legacy mode.
>>
>> I can get into the main desktop and get to Dom0 terminal, but can't launch 
>> any of the default domains.
>>
>> There is another thread on here with the same error. He ran:
>> $ qvm-pci attach --persistent --option permissive=true --option 
>> no-strict-reset=true sys-net dom0:00_XXX
>>
>> And it worked for him, but doesn't work for me, the response I get is "error 
>> : backend vm "dom0" doesn't expose device "00.XXX"

The "XXX" in the PCI device should be filled in with your actual PCI device.

>> So I wonder what "xenlight" is and it won't release what pci device?

Just a library for interfacing with Xen. Unlikely to be the actual problem.

>> Suggestions?
>>
>> Thanks,
>> Patrick
>
> Pics attached here.

It would be the first time I've seen this, but it might perhaps be
conceivable that changing BIOS settings caused your device to show up
with a different BDF (essentially "PCI address") than when Qubes was
installed? Use `lspci` in dom0 to enumerate them.

An easier way than doing this via the command line is to use the
Devices tab of the Qubes VM Settings GUI - remove all devices then add
the one which looks like your network device. You can also configure
no-strict-reset via the button at the bottom of the GUI, which is
sometimes necessary.

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

Re: [qubes-users] OpenSSD

[Jean-Philippe Ouellet]

On Sat, Aug 25, 2018 at 6:48 PM,   wrote:
> Anyone using OpenSSD in their laptops?

I'm not aware of any traditional 2.5" SSD form-factor hardware from
the OpenSSD project.

AFAIK all they've produced are large boards suitable for research in
the SSD space.

Interesting research project, but it appears to be just that, and not
a drop-in replacement for commodity hardware.

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

Re: [qubes-users] Qubes 4.0 SSD Encryption

[Jean-Philippe Ouellet]

On Sat, Aug 25, 2018 at 3:41 PM, taii...@gmx.com  wrote:
> On 08/24/2018 11:44 AM, brendan.h...@gmail.com wrote:
>>
>> And if your OPAL drive is backdoored by the manufacturer for a government, 
>> your drive is backdoored whether you're using OPAL or not and depending on 
>> what you wanted > to keep private, you're already screwed.
>
> Wrong - if you have an IOMMU and the drive is software encrypted then
> you are absolutely fine and it can't do anything but randomly delete
> your data.

Sorry but no, that's not true. Do not conflate encryption with
authentication. I suggest you read more about ciphertext malleability
attacks.

Also, currently disks are owned by dom0, and e.g. a malicious nvme
device could do arbitrary DMA to compromise dom0 and therefore win.
Just because your device has an IOMMU does not mean it is actually in
use to protect you from all DMA-related attacks, and in this specific
case it is not currently in use as such by Qubes.

To really reduce disk-originating attacks to DoS as you suggest (and
as I'm sure many would wish to be the case!) you need something like a
read-only FS protected by dm-verity with the block backend outside
dom0. This is something I have worked on for Qubes, but that work is
not complete yet.

> In that case you can boot from coreboot-grub to a 100% encrypted ssd or
> directly load the kernel from coreboot which then decrypts the drive.
>
> You can also buy an OpenSSD from the OpenSSD project if you want a drive
> with libre firmware - what is cool about them too is that you can
> upgrade the flash modules without changing the controller.
>
> If one installed an OpenSSD on a TALOS 2 then you could have a system
> that is entirely open source and documented.
>
>> No security mechanism exists in a vacuum. Layer them as necessary. I want to 
>> prevent both remote firmware tampering and out-of-sight boot tampering. So I 
>> utilize the > SED hardware security. I also enable software volume 
>> encryption, when available, as well.
>
> If someone has the ability to modify your device firmware they already
> have root or physical access and it is game over, additionally anyone
> with the capability to re-write drive firmware[1] probably has a bypass
> exploit too.
>
> [1] Such a thing is VERY difficult as there is no available
> documentation for them and you need documentation+spec sheets to write
> device firmware - interesting fact most drives these days have a multi
> core ARM processor.
>
> --
> 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/88a11ba1-8181-16d2-9ddd-245a58805839%40gmx.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [qubes-users] Shredding VM images

[Jean-Philippe Ouellet]

On Mon, Aug 20, 2018 at 6:06 PM, Steve Coleman  wrote:
> On 08/20/18 12:49, Chris Laprise wrote:
>>
>> On 08/20/2018 11:34 AM, tierl...@gmail.com wrote:
>>>
>>> What's the most convenient way to wipe these images? (I'm just talking
>>> about individual VM images)
>>
>>
>> To clarify on your first question: Since encryption is protecting the
>> storage pool that contains the disk images and its on an SSD, the only sure
>> way to 'wipe' them in general (not just in the other-VMs-can't see the data
>> sense) is to throw away the encryption passphrase. This makes the entire
>> pool unusable, but if this seems like a problem you can configure more than
>> one storage pool each with its own encryption key+passphrase and store VMs
>> inside them.
>
>
> With an Opal 2.0 SSD you could create a "locking range" for the volatile
> portion of the VM file system, using sedutil-cli then when destroying the VM
> you simply run it with the '--eraseLockingRange' command which essentially
> flips the key bits associated with that region of the SSD. The logic built
> into the drive will ensure the erase of the physical memory mapped into that
> SSD's defined locking range[n].
>
> sedutil-cli
>
>
> --setupLockingRange <0...n>
> --enableLockingRange <0...n>  
>
>
> --disableLockingRange <0...n>  
> --eraseLockingRange <0...n>  

...as implemented by a black box of untrustworthy firmware.

Don't be surprised when this is found to not work as hoped.

I wouldn't recommend relying on it for anything important.

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

Re: [qubes-users] X470 and IOMMU Groups...

[Jean-Philippe Ouellet]

On Wed, Aug 8, 2018 at 1:30 PM,  <3mp...@gmail.com> wrote:
> Hi everyone,
>
> actually I'm a happy Qubes 3.2 user on Intel platform for more than a year 
> now !
>
> I'm looking to upgrade my actual Skylake build with an AMD one with the new 
> Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same 
> occasion. The Asrock X470 Taichi seems a really nice motherboard for it.
>
> I've found the IOMMU Groups of this motherboard on reddit : 
> https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/
>
> and it seems there's a big group 13 with LAN, USB and SATA controllers. I 
> wonder if the netVM and USB VM will actually be able to passthrough these 
> controllers if they are in the same IOMMU Group ?
>
> Any Ryzen / Qubes users can confirm this works OK or this is a no go ?
>
> Thanks for your help !

Not sure if also applicable to the X470, but I tried and was
unsuccessful at installing R4 on an Asrock X399 Taichi. I don't
remember all the details, but I think the installer got stuck in a
boot loop, never getting to GUI. YMMV.

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

[qubes-users] gpg --recv currently broken in debian-9 templates (w/ workaround)

[Jean-Philippe Ouellet]

Magic strings for people searching the archives to be able to find this:
$ gpg --keyserver ... --recv 0x...
gpg: keyserver receive failed: Connection refused
or
$ gpg --keyserver ... --recv 0x...
gpg: keyserver receive failed: No keyserver available

The problem is with dirmngr (a new component of gnupg2 responsible for
interacting with keyservers) failing DNS lookups. More information at
[1].

A workaround is to put "standard-resolver" in ~/.gnupg/dirmngr.conf &
restart dirmngr:
$ cat > ~/.gnupg/dirmngr.conf 

Re: [qubes-users] Problem with Qubes4 rc4 -- "GLX is not supported."

[Jean-Philippe Ouellet]

On Thu, Feb 8, 2018 at 8:42 AM, donoban  wrote:
> On 02/06/2018 04:02 PM, billol...@gmail.com wrote:
>> I've installed Qubes 4 rc4 on an external hard drive.  It works
>> pretty well.  However, I tried to run a game "FreeOrion" and
>> received the following error using the "personal" vm:
>>
>>  Unable to create window.
>>
>> SDL reported: GLX is not supported **
>>
>
> If the game needs 3D acceleration it will not run on an AppVM or HVM.
> You can try with VGA passtrough but is not easy to achieve.

However... just because there's no hardware acceleration does *not*
mean that 3d in AppVMs is impossible.

Depending on the application, software-only 3d rendering may be
sufficient. Many games (especially older and/or indie ones) are indeed
still playable, and 3d cad stuff is also often usable.

There are several software implementations of the OpenGL, etc. APIs,
most notably llvmpipe, softpipe, and (open)swr. Search the qubes-users
archives for these, and look for posts from Vít Šesták. [1]

The software implementations tend to lag behind actual GPUs in terms
of the subset of the OpenGL API that they actually support. More info
at [2]

Which renderer is used is controlled by setting envirionment variables
interpreted by mesa/gallium drivers. For example, to make some games
run I've had to lie about the supported OpenGL version by setting
MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE, or switch the
renderer with LIBGL_ALWAYS_SOFTWARE and GALLIUM_DRIVER. I'm not going
to list any specific values here since they would quickly become out
of date. Instead, refer to the documentation about these env vars at
[3] and play with them yourself. You may find the glxinfo command from
the glx-utils package useful to make sure your env vars are having the
intended effect.

Regards,
Jean-Philippe

[1]: https://groups.google.com/forum/#!searchin/qubes-users/llvmpipe%7Csort:date
[2]: https://mesamatrix.net/
[3]: https://www.mesa3d.org/envvars.html

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

Re: [qubes-users] How to get to command line for dom0?

[Jean-Philippe Ouellet]

On Sat, Jan 20, 2018 at 3:46 PM, Kyle Breneman  wrote:
> I am trying to follow these steps to upgrade from Fedora 23 to Fedora 24
> (and then from 24 to 26), but I got stuck right away because I cannot figure
> out how to get to a command line window for dom0.  Can someone please tell
> me, or point to documentation which explains?  I've done several web
> searches without finding an answer.
>
> Kyle

Note that those directions are about upgrading *templates*, not dom0.
Dom0 should generally stay at the fedora release it started at,
otherwise you are asking for compatibility trouble.

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

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

[Jean-Philippe Ouellet]

On Sat, Jan 20, 2018 at 4:51 AM, Alex Dubois <bowa...@gmail.com> wrote:
> On Saturday, 20 January 2018 06:21:36 UTC, Jean-Philippe Ouellet  wrote:
>> On Fri, Jan 19, 2018 at 3:55 AM,  <wordswithn...@gmail.com> wrote:
>> > I've been working on a solution for this, but unfortunately there are too 
>> > many factors that I'm not familiar with.
>> >
>> > My goal is to to able to:
>> >
>> > 1) Take a screenshot using the dom0 hotkey
>> > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
>> > option
>> > 3) A text entry box that prompts me for the destination VM
>> > 4) The screenshot is sent to the indicated VM
>> >
>> > I think this can be accomplished with
>> >
>> > .desktop application file
>> > zenity
>> > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
>> >
>> > but I'm lost in the details.
>> >
>> > Current problems
>> >
>> > - I can't get dom0 to include my .desktop application files as "Open 
>> > with:" options in the "Screenshot" dialogue
>> > - I'm not sure what format the screenshot is in initially... will the 
>> > .desktop application receive a bunch of bits? Or the path to a temporary 
>> > file?
>> > - I can figure out how to pipe the screenshot if it's a file, but I don't 
>> > know how to handle a "bunch of bits" scenario
>> >
>> > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
>> > looks great, but the code is too complicated for me to review and I just 
>> > need basic functionality anyway. 
>> > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
>>
>> This problem has already been solved, but upstreaming it was stalled
>> for some policy reasons. See here:
>> https://github.com/QubesOS/qubes-issues/issues/953
>>
>> My implementation can be found here:
>> https://github.com/jpouellet/qubes-screenshot-helper
>>
>> Regards,
>> Jean-Philippe
>
> Ah great. I like this implementation. Reviewing the code it does not seem to 
> introduce any risk and provide all the functionality required.
>
> Could you explain briefly the steps to install (after the git pull).
>
> May I also ask you for some help/pointer on a yubikey package I've done. I 
> just need to do the packaging and it may save me some time if you were to 
> give me few pointers...
>
> Project is here... the doc state that it is packages, but it is not (yet)...
> https://github.com/adubois/qubes-app-linux-yubikey
>
> Please reply in that thread if you want:
> https://groups.google.com/forum/#!topic/qubes-users/BkdTuXZZnwE

Set up qubes-builder [1], clone the repo into qubes-src subdir of
qubes-builder repo, then add:
COMPONENTS += your-component-name
to builder.conf, and `make your-component-name` from top level
qubes-builder dir.

Documentation on how to package your own things such that they plug
into the Qubes builder framework (via Makefile.builder) can be found
under doc/ in a checked out qubes-builder.

If you have further specific questions, feel free to ask on qubes-devel.

Regards,
Jean-Philippe

[1]: https://www.qubes-os.org/doc/qubes-builder/

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

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Jean-Philippe Ouellet]

On Thu, Jan 18, 2018 at 3:49 PM, Vít Šesták

wrote:
> On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
>> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
>> >
>> > * If an application does not mitigate Spectre and attacker finds useful 
>> > entry point, attacker can read memory of the application (but nothing 
>> > more).
>> > * If VM kernel does not mitigate Spectre and attacker finds useful entry 
>> > point, attacker can probably read memory of whole VM (but other VMs are 
>> > not affected).
>> > * If Xen does not mitigate Spectre and attacker finds useful entry point, 
>> > attacker can probably read memory of whole system.
>>
>> Can you explain why you think that Spectre can't escape the container (VM)? 
>> It seems that is the main issue, Spectre escapes the container.
>
> It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are 
> about reading memory that should not be accessible. From your description 
> below, I believe you have confused those two.
>
> The reason why Spectre is much harder to actually exploit than Meltdown: For 
> Meltdown, you just use your own code to read the memory. With Spectre, you 
> have to use (and find!) a victim's code to perform innocently-looking 
> operations.
>
> Meltdown allows attacker to read any address in her address space. That's not 
> always whole physical address space, but in case of Xen PV x64 domains, it is 
> the case.
>
> Spectre allows to read the memory in a different way. Imagine the _victim_ 
> has code like this:
>
> if((i > 0) &&(i < a_length)) {
> return a[i];
> } else {
> return NULL; // or any other error code
> }
>
> This looks like a perfect code that prevents overreads and underreads. But an 
> attempt to overread/underread will affect cache. Fortunatelly, such simple 
> code is not much useful. The attacker rather needs something like this: 
> foo[bar[index]]. Even with all the proper bounds checks (that will cause the 
> code not to execute in traditional sense), attacker might try to perform 
> overflow/underflow by using index variable out of range. But CPU might try to 
> execute the branch speculatively (because the condition is usually 
> satisfied), which can cause a read of arbitrary out-of-bounds bar[index]. The 
> read of the value would be probably benign on its own, but then, it tries to 
> load data from foo array based on this value, which might cause cache fetch 
> depending on value of bar[index]. The attacker has not won yet, she has to 
> determine what part of memory was loaded into cache. This can be done using 
> timing attack.
>
> Another interesting part of Spectre is branch target injection. I remember 
> some double fetch vulnerability that can cause bad jump due to race condition 
> (TOCTOU issue). With Spectre, attacker can try to abuse this for bad 
> speculative jump even if there is no race condition possible.
>
> But my main point is that for Spectre attack, the fact that nobody has cared 
> about that when writing the software is not enough for successful 
> exploitation. Actually, one needs to find a suitable code that processes some 
> attacker's input in a suitable way. Moreover, the attacker needs some precise 
> measurement, so passing some malicious input to some queue in order to be 
> processed by code that can trigger speculative out-of-bounds read can be 
> impractical.
>
>> I read the whitepaper and what Spectre is doing is, it's accessing memory it 
>> should not have access to, and then uses a few simple tricks to extract the 
>> data it should not have access to. This happens on a processor level so any 
>> bounds checks that are outside the CPU core will not prevent that.
>
> That's true for both Spectre and Meltdown. But the fact that bounds checks 
> aren't enough does not mean that those attack cannot be mitigated in software 
> elsehow.
>
>> Given the nature of the attack, I do not think that hardware virtualization 
>> would stop this attack.
>
> If this is about Spectre, you are right, hardware virtualization does not 
> stop it on its own. For Meltdown, the situation is a bit different: Hardware 
> virtualization makes the VM not to have the address outside the VM mapped in 
> its address space. Trying to access the memory outside the VM is not 
> prevented by bounds check, it is prevented by the simple fact that they have 
> no address. Note that this AFAIU does not prevent attacking VM's kernel from 
> VM's process, it just prevents attacking hypervisor from VM.
>
>
>> I found various snippets of information hinting at this as well, but again, 
>> I'd be happy to be wrong! But, if I am right, then qubes isolation is 
>> compromised.
>
> Well, you are mostly right. But maybe we should divide it to base system 
> (e.g., Xen and dom0) and single VMs.
>
> The base system is unfortunately affected by Meltdown, because it mostly does 
> not use hardware 

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

[Jean-Philippe Ouellet]

On Fri, Jan 19, 2018 at 3:55 AM,   wrote:
> I've been working on a solution for this, but unfortunately there are too 
> many factors that I'm not familiar with.
>
> My goal is to to able to:
>
> 1) Take a screenshot using the dom0 hotkey
> 2) In the "Screenshot" dialogue, select a script from the "Open with:" option
> 3) A text entry box that prompts me for the destination VM
> 4) The screenshot is sent to the indicated VM
>
> I think this can be accomplished with
>
> .desktop application file
> zenity
> qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
>
> but I'm lost in the details.
>
> Current problems
>
> - I can't get dom0 to include my .desktop application files as "Open with:" 
> options in the "Screenshot" dialogue
> - I'm not sure what format the screenshot is in initially... will the 
> .desktop application receive a bunch of bits? Or the path to a temporary file?
> - I can figure out how to pipe the screenshot if it's a file, but I don't 
> know how to handle a "bunch of bits" scenario
>
> Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> looks great, but the code is too complicated for me to review and I just need 
> basic functionality anyway. 
> https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh

This problem has already been solved, but upstreaming it was stalled
for some policy reasons. See here:
https://github.com/QubesOS/qubes-issues/issues/953

My implementation can be found here:
https://github.com/jpouellet/qubes-screenshot-helper

Regards,
Jean-Philippe

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

Re: [qubes-users] Xfce launcher loses dom0 entries

[Jean-Philippe Ouellet]

On Thu, Nov 9, 2017 at 4:20 PM, Chris Laprise  wrote:
> On Qubes R4-rc2, after reinstalling a template I noticed that only my
> guest-vm entries remained in the Xfce launcher menu.
>
> How do I get the dom0 items back?

For archive searchers:

sudo qubes-dom0-update --action=reinstall $(rpm -qal | grep
/usr/share/applications | xargs rpm -qf | sort -u)

See also:
- https://github.com/QubesOS/qubes-issues/issues/2952#issuecomment-350898716
- https://github.com/QubesOS/qubes-issues/issues/3294

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

Re: [qubes-users] Boot QUBES with kexec

[Jean-Philippe Ouellet]

On Sun, Dec 10, 2017 at 12:19 PM, Robert Walz  wrote:
> On Sun, Dec 10, 2017 at 5:35 PM, Holger Levsen 
> wrote:
>>
>> On Sun, Dec 10, 2017 at 03:05:11PM +0100, Robert Walz wrote:
>> > Does anybody know how to kexec the xen hypervisor?
>>
>> http://osresearch.net/ uses kexec to boot Qubes.
>>
>>
>> --
>> cheers,
>> Holger
>
> Hello Holger,
>
> thanks, I already found this on https://github.com/osreserach/heads
>
> "Booting Qubes requires patching Xen's real mode startup code see
> patches/xen-4.6.3.patch and adding no-real-mode to start of the Xen command
> line.
> Booting or installing Qubes is a bit hacky and needs to be documented."

See: 
https://github.com/osresearch/heads/blob/22282da905d6deabd81aa753845ff4af381f343d/initrd/bin/qubes-boot

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

Re: [qubes-users] Where is ability to backup and restore backups on 4?

[Jean-Philippe Ouellet]

On Thu, Dec 7, 2017 at 12:22 PM, 'Tom Zander' via qubes-users
<qubes-users@googlegroups.com> wrote:
> On Thursday, 7 December 2017 17:38:15 CET Jean-Philippe Ouellet wrote:
>> Remember that the "R4" you're speaking of is still just a release
>> candidate - it is *not* finished!
>
> To most people the concept of a "release candidate" is that the software
> released is possible the final version, if there don't appear to be any
> show-stoppers.
>
> As such, the Qubes devs consider it feature complete. Otherwise it would
> have been marked as beta.
> So we have to conclude that missing features (like not having a UI for
> backups) is not planned for 4.0, maybe for 4.1.

That's fair. You're right.

I suppose expectations vary.

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

Re: [qubes-users] Where is ability to backup and restore backups on 4?

[Jean-Philippe Ouellet]

On Thu, Dec 7, 2017 at 11:59 AM, Bernhard  wrote:
> On 12/07/2017 03:37 PM, Zrubi wrote:
>> On 12/07/2017 03:04 PM, r...@tuta.io wrote:
>> > Dont tell me the geniuses behind this thought it was more
>> > streamlined to remove the feature and make it only command
>> > line
>>
>>
>> It was part of the Qubes Manager, so... it is gone with the wind ;)
>>
> I am not really in position to answer this question correctly, but I
> backup "by hand". How that? Well, put uour favourite backup system to
> your computer. A disc to sys-usb for example. Mount it in sys-usb &
> generate a sufficiently large file on it ("truncate -s 200G
> qubes.backup.luks" for example generates a 200G filke in < 1s. If you
> are paranoid you overwrite it with random data).
> (1)  losetup -f   #   to get a free llop devicename
> I call ip lloopXXX, then
> (2)  losetup /dev/loopXXX   qubes.backup.luks  # now your
> file il looped to /dev/loopXXX, so it "is" a device.
> (3)  cryptsetup  luksFormat   /dev/loopXXX  BACKUP# Now you create a
> luks volume on it. Check Luks doc for parameters.
> (4)  cryptsetup  luksOpen   /dev/loopXXX  BACKUP   # open it (need
> your pwd once more)
> (5)  mkfs.ext2 /dev/mapper/BACKUP # create
> filesystem on the new backup volume
> (6)  mount /dev/mapper/BACKUP/yourmountpoint.   # and mount it
>
> Now generate one folder in  /yourmountpoint for each qube ; the point is
> that the Q-menu allows to attach any qube's private image to sys-usb as
> well, so you may mount it there to some folder, say /source and then
> rsync your data in the right backup-subfolder. This sound complicated,
> but is really fast to do. At the very end you should
>
> (7) umount /yourmountpoint   # unmount backup
> (8) cryptsetup  luksClose   BACKUP # close luks container
> (9) losetup -d   qubes.backup.luks   # free the loop-device
>
> If I were better in bash-scripting I would do that automatedly, but I
> regret that ...Bernhard

That's way more complex than it needs to be, and also does not provide
integrity protection.

Is there a reason you do not just use qvm-backup?

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

Re: [qubes-users] Where is ability to backup and restore backups on 4?

[Jean-Philippe Ouellet]

On Thu, Dec 7, 2017 at 9:04 AM,   wrote:
> Dont tell me the geniuses behind this thought it was more streamlined to 
> remove the feature and make it only command line

On Thu, Dec 7, 2017 at 9:45 AM,   wrote:
> Lmao wow... usually developer's try to progress forward in their projects not 
> backwards...

Remember that the "R4" you're speaking of is still just a release
candidate - it is *not* finished!

It's not that "the developers have stupid priorities" or something,
it's that there are many lower-level less user-visible things which
need to happen first.

Many things in R4 were redone completely from scratch. You are arguing
about why the brand new house being built doesn't have the doorknobs
you loved from the last one, when the people actually building it are
still concerned with getting all the plumbing in place. We personally
don't see doorknobs as the highest priority right now, cause we still
enter the house through the giant un-finished hole in the wall.

Remember that you're running pre-release software, and try not to give
it a bad reputation simply for not being finished yet. The Qubes
development team has limited resources, and individual contributors
have limited free time. You're always welcome to contribute. Pull
requests welcome, as are checks, bitcoins, etc. ;)

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

Re: [qubes-users] Hibernate Lenovo X1

[Jean-Philippe Ouellet]

On Sun, Dec 3, 2017 at 5:36 PM, beso  wrote:
> "systemctl hibernate:
> Failed to execute operation. Sleep verb not supported."
>
> How to solve this issue?

Xen does not support hibernating, therefore Qubes does not either.

Use suspend instead of hibernate.

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

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

[Jean-Philippe Ouellet]

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

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

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

[qubes-users] Qubes workstation / gaming desktop thread (November 2017)

[Jean-Philippe Ouellet]

On Thu, Nov 23, 2017 at 12:01 AM, taii...@gmx.com  wrote:
> You can make a libre firmware workstation that can play the latest games in
> a VM for $500 total.

Bullshit! ;)

I really want you to be right, but I'm having trouble seeing how, so I
want you to prove it!

If you can precisely spec out a full system with the capabilities and
budget you claim is possible, then I'll buy one, maybe others on this
list will too, and if we ever meet I'll owe you a beer (or club-mate).

I'm talking about a complete list of parts and suitable suppliers
(which I'll probably ignore and look for elsewhere out of supply chain
concerns -- after all, for all I know you could *be* said supplier and
be trying to seed your implants among Qubes contributors! :P Nothing
personal.)

Cheers,
Jean-Philippe

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

Re: [qubes-users] Possible privacy concerns with Qubes 4 and the transition away from paravirtualization?

[Jean-Philippe Ouellet]

On Mon, Nov 20, 2017 at 6:04 PM, taii...@gmx.com <taii...@gmx.com> wrote:
> On 11/20/2017 04:36 AM, Jean-Philippe Ouellet wrote:
>
>> That statement is demonstrably false. For example, we don't filter
>> CPUID vendor IDs in either mode.
>
> How come?

See discussion at https://github.com/QubesOS/qubes-issues/issues/1142

> I didn't know you were a dev :0

Eh, I'm not really, I just spend some free time working on things that
are either interesting or that bother me :)

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

Re: [qubes-users] Possible privacy concerns with Qubes 4 and the transition away from paravirtualization?

[Jean-Philippe Ouellet]

On Mon, Nov 20, 2017 at 5:59 PM, taii...@gmx.com  wrote:
> On 11/19/2017 07:17 PM, riggedegg...@gmail.com wrote:
>
> Does this hold any water? Does the switch from paravirtualization to
> HVM/SLAT degrade privacy by allowing easier hardware fingerprinting?
>
> It holds no water.
>
> There is no such thing as "hardware fingerprinting"

Then what do you call checking e.g. clock drift, disk bandwidth, etc.?

> what is usually done
> for DRM or w/e is simply reading the model names and serial numbers of
> hardware installed - nothing truly "magic".
>
> You can easily change what is displayed in lscpu for example no matter if
> you are using HVM or software virt.
> In any virt system the graphics device name isn't displayed in the VM nor
> your total amount of RAM or serial numbers of drives.
>
> Self proclaimed experts on reddit who mention something provocative but
> provide no technical information almost always have no idea what they are
> talking about.

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

Re: [qubes-users] Possible privacy concerns with Qubes 4 and the transition away from paravirtualization?

[Jean-Philippe Ouellet]

On Sun, Nov 19, 2017 at 7:17 PM,   wrote:
> Here's one such comment, taken from an r/privacy Reddit thread.
>
> "[...]paravirtualization makes hardware profiling impossible unless an 
> exploit is found to defeat it."

That statement is demonstrably false. For example, we don't filter
CPUID vendor IDs in either mode.

https://xkcd.com/386/

Cheers,
Jean-Philippe

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

[qubes-users] Migrating data from R3 to R4 without making a backup

[Jean-Philippe Ouellet]

Hello,

I've written a script [1] to import VMs directly from a Qubes R3 hard
drive into a Qubes R4 machine without needing to make a backup first.

I would definitely recommend making a full backup on R3 and restore on
R4 instead of using this. I just figured I'd share in case anybody
else is unable to make a backup for whatever reason (e.g. [2]) but
really must migrate data anyway.

Unfortunately the script is a mess and probably difficult to audit. I
didn't have time to write something nice suitable for upstreaming, I
just had to get my data migrated. Of course, you should never run
giant messes of code in dom0 that you get from random people on the
mailing list (including me)! If it breaks you get to keep both pieces
;)

Cheers,
Jean-Philippe

[1]: https://github.com/jpouellet/qubes-r3-importer
[2]: https://github.com/QubesOS/qubes-issues/issues/1588

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

Re: [qubes-users] Re: Qubes Canary #13

[Jean-Philippe Ouellet]

On Fri, Nov 17, 2017 at 2:47 PM,   wrote:
> On Friday, September 29, 2017 at 6:31:15 PM UTC-7, Andrew David Wong wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Dear Qubes community,
>>
>> On 2017-09-12, we published Qubes Canary #13. The text of this canary is
>> reproduced below. This canary and its accompanying signatures will always be
>> available in the Qubes Security Pack (qubes-secpack).
>>
>> View Canary #13 in the qubes-secpack:
>>
>> 
>>
>> Learn about the qubes-secpack, including how to obtain, verify, and read it:
>>
>> 
>>
>> View all past canaries:
>>
>> 
>>
>> ```
>> ---===[ Qubes Canary #13 ]===---
>>
>>
>> Statements
>> - ---
>>
>> The Qubes core developers who have digitally signed this file [1]
>> state the following:
>>
>> 1. The date of issue of this canary is September 12, 2017.
>>
>> 2. There have been 33 Qubes Security Bulletins published so far.
>>
>> 3. The Qubes Master Signing Key fingerprint is:
>>
>> 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
>>
>> 4. No warrants have ever been served to us with regard to the Qubes OS
>> Project (e.g. to hand out the private signing keys or to introduce
>> backdoors).
>>
>> 5. We plan to publish the next of these canary statements in the first
>> two weeks of December 2017. Special note should be taken if no new canary
>> is published by that time or if the list of statements changes without
>> plausible explanation.
>>
>> Special announcements
>> - --
>>
>> None.
>>
>> Disclaimers and notes
>> - --
>>
>> We would like to remind you that Qubes OS has been designed under the
>> assumption that all relevant infrastructure is permanently
>> compromised.  This means that we assume NO trust in any of the servers
>> or services which host or provide any Qubes-related data, in
>> particular, software updates, source code repositories, and Qubes ISO
>> downloads.
>>
>> This canary scheme is not infallible. Although signing the declaration
>> makes it very difficult for a third party to produce arbitrary
>> declarations, it does not prevent them from using force or other
>> means, like blackmail or compromising the signers' laptops, to coerce
>> us to produce false declarations.
>>
>> The news feeds quoted below (Proof of freshness) serves to demonstrate
>> that this canary could not have been created prior to the date stated.
>> It shows that a series of canaries was not created in advance.
>>
>> This declaration is merely a best effort and is provided without any
>> guarantee or warranty. It is not legally binding in any way to
>> anybody. None of the signers should be ever held legally responsible
>> for any of the statements made here.
>>
>> Proof of freshness
>> - ---
>>
>> $ date -R -u
>> Mon, 11 Sep 2017 17:54:05 +
>>
>> $ feedstail -1 -n5 -f '{title}' -u 
>> https://www.spiegel.de/international/index.rss
>> A Shrinking Giant: EU Worries Grow over U.S. Economic Chaos
>> Iranian Vice President Salehi on Nuclear Deal: 'Our Partners Have More To 
>> Lose Than We Do'
>> Is Moscow Planning Something?: Germany Prepares for Possible Russian 
>> Election Meddling
>> Where Dreams Come to Die: Migrant Path in Europe Ends at Brenner Pass
>> Stemming the Flow: Why Europe's Migrant Strategy Is an Illusion
>>
>> $ feedstail -1 -n5 -f '{title}' -u 
>> http://rss.nytimes.com/services/xml/rss/nyt/World.xml
>> Desperation Mounts in Caribbean Islands: ‘All the Food Is Gone’
>> Mexico Mourns After Quake: ‘We Have No Idea How We Are Going to Rebuild’
>> Rohingya Crisis in Myanmar Is ‘Ethnic Cleansing,’ U.N. Rights Chief Says
>> Need to Catch Up on the German Election? Here’s a Guide
>> U.S. Weakens Resolution on North Korea to Gain Chinese and Russian Support
>>
>> $ feedstail -1 -n5 -f '{title}' -u http://feeds.bbci.co.uk/news/world/rss.xml
>> Hurricane Irma: Florida launches huge relief operation
>> Rohingya crisis: UN sees 'ethnic cleansing' in Myanmar
>> Catalan independence rally: Thousands gather in Barcelona
>> Trump on 9/11 anniversary: "Our nation will endure"
>> Venezuela accuses UN of lying over alleged rights abuses
>>
>> $ feedstail -1 -n5 -f '{title}' -u http://feeds.reuters.com/reuters/worldnews
>> U.N. Security Council to vote Monday on weakened North Korea sanctions: 
>> diplomats
>> Afghanistan will never again be militant sanctuary: U.S. ambassador
>> U.N. rights boss sees possible "crimes against humanity" in Venezuela
>> Russia, Jordan agree to speed de-escalation zone in south Syria
>> U.N. brands Myanmar violence a 'textbook' example of ethnic cleansing
>>
>> $ curl -s 'http://blockchain.info/blocks/?format=json'
>>
>> $ python3 -c 'import sys, json; 
>> print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
>> 

Re: [qubes-users] build usb-vm and net-vm using openbsd?

[Jean-Philippe Ouellet]

On Wed, Nov 8, 2017 at 3:37 PM, ludwig jaffe  wrote:
> Hi, I saw that the linux kernel has some flaws 
> (http://www.openwall.com/lists/oss-security/2017/11/06/8) in the usb stack, 
> so I am
> thinking about security against common errors, I would suggest to use
> OpenBSD as USB-VM. Maybe, as Net-VM one could use open-bsd.
> But how to integrate open-bsd with qubes and the virtual network inside qubes?
>
> Has anyone tried such?

Yes, I looked into this some time last year and plan to return to work
on it one day. I was an OpenBSD person before I came to Qubes.

Several things need to happen first before any meaningful Qubes
integration can be done though. First would be a vchan driver.

Don't expect anything soon... unless perhaps you're willing to fund such work?

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

Re: [qubes-users] Re: Question to Mirage OS firewall users

[Jean-Philippe Ouellet]

On Wed, Nov 8, 2017 at 3:09 PM,   wrote:
> On Thursday, April 13, 2017 at 1:33:53 PM UTC+1, Thomas Leonard wrote:
>> On Thursday, April 13, 2017 at 11:08:11 AM UTC+1, Foppe de Haan wrote:
>> > On Thursday, April 13, 2017 at 10:00:20 AM UTC+2, Thomas Leonard wrote:
>> > > On Wednesday, April 12, 2017 at 10:32:11 PM UTC+1, Foppe de Haan wrote:
>> > > > Any clue why Windows 7 won't boot when I have MirageOS selected as the 
>> > > > firewall?
>> > >
>> > > I've never tried it. Do the mirage-firewall logs show anything 
>> > > interesting when you try to boot Windows?
>> >
>> > No, but I do have this log (guest-windows-dm). First log doesn't boot 
>> > (MirageOS), 2nd does (sys-firewall). Is that of any use?
>>
>> Oh, that's more useful than I was expecting! Looks like the Windows boot 
>> process starts by running MiniOS! It's hanging at
>>
>> close network: backend at /local/domain/4/backend/vif/79/0
>>
>> I guess it asked the firewall to close the network, and never got a reply 
>> (because the firewall doesn't have any code to do that).
>
> OK, I finally got some time to look into this. I think this patch should fix 
> it (works for Linux HVM anyway):
>
> https://github.com/mirage/mirage-net-xen/pull/67
>
> I also made a patch that seems to let the firewall work with disposable VMs:
>
> https://github.com/mirage/mirage-net-xen/pull/68

Sweet :)

> Both are based on guesswork though - is the Xen netback protocol documented 
> somewhere?

In xen src:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=refs/heads/master

netfront / netback in linux:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netback

And a somewhat outdated but much more approachable introduction in
section 9.2 (starting p.169) of "The Definitive Guide to the Xen
Hypervisor" book in case you have access to it.

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

Re: [qubes-users] Re: [qubes-devel] Qubes R3.2 - Severe graphics issues/glitches ? (HCL Report included)

[Jean-Philippe Ouellet]

On Fri, Nov 3, 2017 at 1:18 PM, 'Marek Jenkins' via qubes-users
 wrote:
>
>> > Hi Jean-Philippe,
>> >
>> > thanks for your advice.
>> >
>> > I have read the docs over here regarding kernel updates:
>> > https://www.qubes-os.org/doc/software-update-dom0/
>> >
>> > So should I simply run the following terminal commands in dom0 ?
>> >
>> > sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
>> > kernel-qubes-vm
>> >
>> > Also, do I need to enable / specify a repo (e.g. unstable, current-testing,
>> > etc) or can I also use the command like this:
>> >
>> > sudo qubes-dom0-update kernel kernel-qubes-vm
>> >
>> > Thank you for your support !
>> >
>> > PS: I posted this also in qubes-devel, because I thought this issue is 
>> > quite
>> > difficult for normal users to solve.
>> > Sorry about that, I have also posted my HCL Report in qubes-users and will
>> > update there if I find a fix !
>> >
>> > Best regards,
>> > Marek
>>
>> just start with
>> $ sudo qubes-dom0-update
>> in dom0 and reboot
>>
>> only if that doesn't work then try -testing or -unstable repos.
>
> I just wanted to let you know that I upgraded the kernel and shortly after 
> the screen corruption happened again (green screen). This happened right 
> before I wanted to update the grub file. Now the system doesn't boot up 
> anymore but gets stuck.
>
> I think I need to reinstall everything.

You might consider trying Qubes R4(-rc2). the system feels a bit
different and isn't quite release-worthy yet IMO, but it has much
newer hardware support and your graphics issues might be fixed.

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

[qubes-users] Re: [qubes-devel] Qubes R3.2 - Severe graphics issues/glitches ? (HCL Report included)

[Jean-Philippe Ouellet]

Moving discussion from qubes-devel to qubes-users:

On Thu, Nov 2, 2017 at 3:47 PM, 'Marek Jenkins' via qubes-devel
<qubes-de...@googlegroups.com> wrote:
> On Thursday, November 2, 2017 at 7:03:12 PM UTC+1, Jean-Philippe Ouellet
> wrote:
>>
>> On Thu, Nov 2, 2017 at 1:13 PM, 'Marek Jenkins' via qubes-devel
>> <qubes...@googlegroups.com> wrote:
>> > Dear users and devs,
>> >
>> > I really like Qubes and hope I can make it work.
>> >
>> > I have severe graphics glitches that happen at random intervals.
>> > If they happen I must reboot the system to fix them temporarily
>> > (potential
>> > data loss).
>> > Unfortunately, those issues make Qubes 3.2 unusable for me because I
>> > need
>> > reliability.
>> >
>> > Glitch #1: https://imgur.com/a/fkAjW
>> > Looks like a green screen to me. Happens mostly when the system was idle
>> > /
>> > stand-by and I get back to it.
>> >
>> > Glitch #2: https://www.youtube.com/watch?v=sIaOWpFsdTM
>> > Weird screen glitch - also green but with some kind of flickering.
>> > Appears
>> > randomly.
>> >
>> > HCL REPORT:
>> >
>> > (Also attached the files !)
>> >
>> > ---
>> > layout:
>> >   'hcl'
>> > type:
>> >   'desktop'
>> > hvm:
>> >   'yes'
>> > iommu:
>> >   'no'
>> > slat:
>> >   'yes'
>> > tpm:
>> >   'unknown'
>> > brand: |
>> >   Gigabyte Technology Co., Ltd.
>> > model: |
>> >   Z97X-UD5H
>> > bios: |
>> >   F9
>> > cpu: |
>> >   Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
>> > cpu-short: |
>> >   FIXME
>> > chipset: |
>> >   Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00]
>> > (rev
>> > 06)
>> > chipset-short: |
>> >   FIXME
>> > gpu: |
>> >   Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated
>> > Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
>> > gpu-short: |
>> >   FIXME
>> > network: |
>> >   Intel Corporation Ethernet Connection I217-V
>> >   Qualcomm Atheros Killer E220x Gigabit Ethernet Controller (rev 10)
>> >   Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
>> > memory: |
>> >   32550
>> > scsi: |
>> >   Samsung SSD 840  Rev: BB6Q
>> >   DT HyperX 3.0Rev: PMAP
>> >
>> > versions:
>> >
>> > - works:
>> > 'FIXME:yes|no|partial'
>> >   qubes: |
>> > R3.2
>> >   xen: |
>> > 4.6.1
>> >   kernel: |
>> > 4.4.14-11
>> >   remark: |
>> > FIXME
>> >   credit: |
>> > FIXAUTHOR
>> >   link: |
>> > FIXLINK
>>
>> Try updating your kernel in dom0. 4.4.14 is very old and hardware
>> support improves over time.
>>
>> Also, posts like this should probably go on qubes-users instead of
>> qubes-devel.
>>
>> Regards,
>> Jean-Philippe
>
>
>
> Hi Jean-Philippe,
>
> thanks for your advice.
>
> I have read the docs over here regarding kernel updates:
> https://www.qubes-os.org/doc/software-update-dom0/
>
> So should I simply run the following terminal commands in dom0 ?
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
> kernel-qubes-vm
>
> Also, do I need to enable / specify a repo (e.g. unstable, current-testing,
> etc) or can I also use the command like this:
>
> sudo qubes-dom0-update kernel kernel-qubes-vm
>
> Thank you for your support !
>
> PS: I posted this also in qubes-devel, because I thought this issue is quite
> difficult for normal users to solve.
> Sorry about that, I have also posted my HCL Report in qubes-users and will
> update there if I find a fix !
>
> Best regards,
> Marek

just start with
$ sudo qubes-dom0-update
in dom0 and reboot

only if that doesn't work then try -testing or -unstable repos.

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

Re: [qubes-users] Question about qubes s hypervisor

[Jean-Philippe Ouellet]

On Thu, Oct 19, 2017 at 1:25 AM, blacklight  wrote:
> We all know well why xen was chosen as the hypervisor for qubes instead of 
> kvm, since this has been stated in multiple places by the devs. But i wonder 
> how feasable it would be to use bhyve as a hypervisor for qubes. Ive read 
> that it only uses roughly 30k lines of code, so its smaller then xen which is 
> good since less code means less attack surface right? and seems to support 
> vt-d and vt-x. Also its made by the freebsd theme, which are known for the 
> high coding standards. Would it be possible to run qubes with bhyve instead 
> of xen? If not, why?
>
> I would love some info on this :)
>
> Greetings, blacklight447

I've looked into this possibility in the past.

Last I checked, bhyve's device models were required to be in the host
and ran with significant privileges. This may have been addressed by
[1], but I'd need to do more research to be sure and see what privs
they still run with.

Other things that would need to be done before it's a viable candidate:
- some XenStore equivelant
- some vchan equivalent
- expose shared mem for zero-copy framebuffers
- de-systemd-ification of dom0 things
and undoubtedly other things that don't immediately come to mind.

Definitely not a trivial task in any case.

Cheers,
Jean-Philippe

[1]: https://reviews.freebsd.org/D8290

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

Re: [qubes-users] How to avoid hostname leaks when using MAC randomization in debian-9

[Jean-Philippe Ouellet]

On Wed, Aug 23, 2017 at 11:25 AM, 'Brotherfill' via qubes-users
 wrote:
> Hi,
> To avoid hostname leaks I add # at the beginning of line 'send
> host-name=gethostname' in /etc/dhcp/dhclient.conf
> Do you suggest to use this method or to set a static ip?

AFAIK the hostname should always be sys-net, and you are
fingerprintable as a qubes user anyway, so I don't think the hostname
is in any way interesting unless you have a uniquely named (read:
non-default) NetVM.

Regards,
Jean-Philippe

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

Re: [qubes-users] sys-usb and usb read-only

[Jean-Philippe Ouellet]

On Fri, Aug 11, 2017 at 4:41 AM, Nicolas Mojon  wrote:
> Hi,
>
> I would like to know if on the new 4.0 it is possible to lock down data in a 
> VM like that nothing can go out of the VM (like no internet or copypaste 
> through dom0). I would like to make that specially for usb sticks or other 
> stocking device, that people can work on things on the usb in the VM but 
> nothing must be able to go out.
>
> Additionally to that, I would like to know if it is possible to use the 
> sys-usb vm but with an usb keyboard, cause for the moment, when I try to 
> implement it, it finish in a dead lock cause I cannot use the keyboard when 
> restarting. And even with the ask policy, it happens after the login so it is 
> pretty problematic and allow it completely,will probably cause a security 
> issue for my system on of the question above.
>
> Thank you in advance...
>
> Best regards
>
> Nicolas

You can put explicit deny rules for all qrexec services involving that
VM. Copy/paste evaluates qubes-rpc policy too, but with an implicit
undefined or ask meaning yes.

*HOWEVER*: To truly and completely accomplish this is pretty much
impossible with modern computer architectures unless you limit to only
one VM running at a time. There will likely always be ways to
establish covert channels between cooperating VMs due to hardware
side-channels, regardless of whatever Qubes might try to do to stop
it.

See also: https://www.qubes-os.org/doc/data-leaks/

Regards,
Jean-Philippe

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

Re: [qubes-users] UEFI secureboot issue

[Jean-Philippe Ouellet]

On Tue, Aug 1, 2017 at 7:50 PM, cooloutac  wrote:
> Qubes doesn't support secure boot unfortunately.  I think its batshit crazy 
> to consider a pc even reasonably secure without it.

Secure boot in reality is quite far from the boot chain panacea its
name may suggest.

If you haven't already, I'd suggest reading Joanna's "Intel x86
considered harmful" paper [1] and checking out Trammell Hudson's Heads
project [2].

FWIW, the systems I currently believe have the most secure boot chains
do not involve UEFI at all.

Regards,
Jean-Philippe

[1]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[2]: http://osresearch.net/

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

Re: [qubes-users] Re: Qubes OS 4.0 first release candidate (rc1) has been released!

[Jean-Philippe Ouellet]

On Tue, Aug 1, 2017 at 7:46 PM, cooloutac  wrote:
> am I reading this right?  There is no qubes-manager in 4.0? Does that mean 
> everything must be done in a terminal?  Tell me I read that wrong lol.

tl;dr - https://github.com/QubesOS/qubes-issues/issues/2132

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

Re: [qubes-users] Qubes OS 4.0 first release candidate (rc1) has been released!

[Jean-Philippe Ouellet]

On Tue, Aug 1, 2017 at 7:02 AM, Rusty Bird  wrote:
> Zrubi:
>> So I would really appreciate some statement if Qubes will really drop
>> KDE support. I can accept that, but then I not waste my time trying to
>> make it work. Instead focusing to fix the XFCE issues I have ;)
>>
>> - the default login screen is just ugly. I know that this is not the
>> first priority, and not even a technical issue. But new users will see
>> that ugly thing first. So it's should be a Qubes skinned one. at least.
>
> Or, if the login screen isn't needed anymore (to switch between XFCE
> and KDE), why not get rid of it entirely:
>
> # mkdir /etc/lightdm/lightdm.conf.d
> # cat >>/etc/lightdm/lightdm.conf.d/99-autologin.conf < [SeatDefaults]
> autologin-user=USERNAME
> END

Consider a briefly-unattended laptop protected by only a lock screen.

Normally the attacker would need a way to kill the X screensaver
without killing the X session. Would the above make crashing the X
session (and thus being dropped back to the display manager which
auto-logs-in) sufficient to gain access?

If so, this sounds like a bad idea (or at least an argument for
something like physlock).

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

Re: [qubes-users] Bootloader not installed on USB

[Jean-Philippe Ouellet]

On Fri, Jul 28, 2017 at 6:48 AM, Nero  wrote:
> I'm installing Qubes on Macbook Air.
> I partitioned (EFI, Macos journalled) my SSD but Qubes installer do not see 
> any partitions on SSD but see my 32GB USB stick.
> 1. Why I can not install on SSD?
>
> Ok, trying to install on USB goes ok until message like "boot loader can not 
> be written" at the end of installation.
> Trying to boot with this installations get me to "grub>" only.
>
> Can I fix my USB somehow? Maybe I can write bootloader manually?

In case you haven't seen it already, have you read through the MacBook
troubleshooting page [1], particularly the sections "4. Fix GRUB
configuration", and "5. Fix bootloader"?

[1]: https://www.qubes-os.org/doc/macbook-troubleshooting/

Regards,
Jean-Philippe

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

Re: [qubes-users] Seeking moderators for unofficial Qubes IRC channels on Freenode and OFTC

[Jean-Philippe Ouellet]

On Thu, Jul 27, 2017 at 5:22 PM, Franz <169...@gmail.com> wrote:
>
>
> On Thu, Jul 27, 2017 at 4:13 PM, cooloutac  wrote:
>>
>> On Friday, July 21, 2017 at 12:26:35 PM UTC-4, PR wrote:
>> > Hello
>> >
>> >
>> >
>> > Am 21.07.2017 9:39 vorm. schrieb "Noor Christensen"
>> > :
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > The IRC channels are unofficial, and should probably continue to be so
>> >
>> > since we already have the mailing lists as our official means of
>> >
>> > communication.
>> >
>> >
>> >
>> > Agreed, Mailinglist and  Qubes Docu are perfect to look for answers.
>> > The only (maybe) missing part would be a quick start guide for
>> > beginners, adressing the most relevant tasks (referencing to the
>> > documentation).
>> >
>> >
>> >
>> >
>> > People will continue joining the #qubes channel (or another one) and ask
>> > for help, no matter if we are there or not. I think it's a great way to
>> >
>> > introduce new users to the project and point users with questions or
>> >
>> > answers to the offical docs and lists for further discussion.
>> >
>> >
>> >
>> > If there is an IRC channel, I think it should be clearly mentioned on
>> > the website as asking via IRC might be a lower barrier for newbies.
>> >
>> >
>> > - PhR
>>
>> Qubes should not associate themselves with freenode or irc.   That's just
>> my opinion. Nobody with self respect or integrity has taken freenode serious
>> for over 10 years.  It should stay unofficial.
>>
>>  I think google forums are a lot easier to use then installing some irc
>> client or connecting to a webchat, where the only people there are criminals
>> or spammers who want to exploit you or the network.  No moderator can help,
>> freenode can't even protect themselves.  The wolves bully that hen house.
>> Any IRC channel should stay unofficial imo.  Freenode and its communities
>> are the sole reason Linux is unpopular.  Its a ghost town full of idle bots
>> for a reason.
>>
>> Its one of the most dangerous  places to connect to, besides online games,
>> some porn sites, and darknet sites like silk road. I mean come on, it
>> was hilarious how it was portrayed on Mr. Robot,  but they were not that far
>> off.
>>
>> Even though they brought back tor support, which is a catch22 for them,
>> (although you would need a special tor setup, standard setups dont' work)
>> Recommending people go to freenode is like leading sheeps to slaughter.
>>
>
> Well it seems that all groups are using Slack now. It is easy to use and
> works well. Have a look.
> Best
> Fran

If you're going to use not-IRC, then there is already a matrix [1]
group for Qubes. Matrix is a decentralized "secure" (whatever that
really means) alternative to Slack, and it's already picked up some
momentum. The matrix group is also bridged with the #qubes_os channels
on freenode and OFTC.

Personally, I think IRC's status as the de-facto chat protocol for
similar communities warrants having a presence there (since people
*do* regularly come there with questions), so I'll continue to idle
there and am happy to volunteer as a chanop if the Qubes team wants.

Regards,
Jean-Philippe

[1]: https://matrix.org/

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

Re: [qubes-users] Printing and scanning with Qubes - a love story

[Jean-Philippe Ouellet]

On Thu, Jul 20, 2017 at 12:32 PM, js...@riseup.net <js...@riseup.net> wrote:
> Jean-Philippe Ouellet:
>> On Qubes, it's a completely different story. First, I pass my USB
>> printer or scanner through to a DispVM. To print, I just copy the file
>> to the DispVM, open it with anything, and print it, and the printer is
>> automatically found and "just works" (thanks Fedora). To scan: I pass
>> the printer to a DispVM, open simple-scan, click the scan button, and
>> it just works! When I'm happy with my scan, I copy it out of the
>> DispVM and then convert to trusted PDF! So far every printer or
>> scanner just works the first time, I haven't needed to look under the
>> hood for anything.
>>
>> With sys-usb, DispVMs, and convert-to-trusted-pdf I feel reasonably
>> confident that if the printers or scanners were malicious, the worst
>> they could do is mutate my documents or store them for later retrieval
>> by an adversary (which is an inherent problem with any commodity
>> printer and totally unrelated to the OS used to interface with). This
>> would be even more true with a stateless laptop without any persistent
>> mutable firmware for the USB controllers, and when sys-usb can act
>> like a DispVM itself without hacks (R4?).
>
> Hi,
>
> I've been having some problems with this myself. Specifically, I'm not
> sure how to pass my USB printer to an appVM. The only thing I can see to
> do is to attach my whole USB controller to a VM, but I'm pretty sure if
> I do that I'll lose my input devices (USB keyboard and mouse) and not be
> able to control the system.

See 
https://www.qubes-os.org/doc/usb/#attaching-a-single-usb-device-to-a-qube-usb-passthrough

> Do you have to have a usbvm (sys-usb) in order to get this to work?

Yes.

> My appVMs are based on a debian-8 template, if that matters.

I'm not aware of any debian-specific issues with USB passthrough,
although I have not tried it myself either.

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

[qubes-users] Printing and scanning with Qubes - a love story

[Jean-Philippe Ouellet]

Hello fellow Qubesers,

Qubes continues to make me feel all warm and fuzzy inside, and makes
me want to share it with the world.

I've been quite busy with real-world things recently and had to use
several different printers & scanners. Prior experience has
conditioned me to expect frustration, or at least annoyance.

On windows I have memories of disabling driver signature enforcement,
installing some big printer "drivers" from totally unauthenticatable
sources, which then actually come with bloated desktop applications
with features like "scan with your webcam". (Hello scanner company: if
that worked well, then nobody would buy your scanners or install their
drivers!) Oh, and the fancy ink level reporting dialogues saying
things like "You have -60012% cyan ink left! Click  to buy
more now!" - those are great.

On OS X I remember the days of force-killing the printer app as the UI
blocks indefinitely while waiting for a reply from the printer which
isn't coming. Or the network printer which somehow gets a different
DHCP lease every day resulting in a list of 20 saved printers
"helpfully" auto-discovered and persisted, all with the same name, all
indistinguishable in the UI, but only one of which actually works.

On various Linuxes & *BSDs, I remember wrestling for days on every
install to get lpd and cups working, and then dealing with differences
in postscript parsers causing messed up formatting, and stupid udev
rules running things of massive complexity as root so that your
scanner would have a really easy time if it wanted to compromise
you... *sigh*

On Qubes, it's a completely different story. First, I pass my USB
printer or scanner through to a DispVM. To print, I just copy the file
to the DispVM, open it with anything, and print it, and the printer is
automatically found and "just works" (thanks Fedora). To scan: I pass
the printer to a DispVM, open simple-scan, click the scan button, and
it just works! When I'm happy with my scan, I copy it out of the
DispVM and then convert to trusted PDF! So far every printer or
scanner just works the first time, I haven't needed to look under the
hood for anything.

With sys-usb, DispVMs, and convert-to-trusted-pdf I feel reasonably
confident that if the printers or scanners were malicious, the worst
they could do is mutate my documents or store them for later retrieval
by an adversary (which is an inherent problem with any commodity
printer and totally unrelated to the OS used to interface with). This
would be even more true with a stateless laptop without any persistent
mutable firmware for the USB controllers, and when sys-usb can act
like a DispVM itself without hacks (R4?).

Qubes may be far from my theoretically ideal OS, but it absolutely
hits a pragmatic sweet spot improving security *and* usability
simultaneously.

Might I dare re-purpose a colored slogan and say Qubes is truly
"making computers great again"? :P

Sincerely,
Jean-Philippe


 Now back to work...

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

Re: [qubes-users] Qubes Community Event in Cologne, Germany on July 15th

[Jean-Philippe Ouellet]

On Mon, Jun 26, 2017 at 9:10 AM, Robert Mittendorf
 wrote:
> Hello fellow Qubes users,
>
> the "Kölner Kreis", a group of regulars that are interested in IT-Security
> and IT-Forensics, will organize a "Qubes Community Event" in Cologne on July
> 15th 10.00 - 16.00.
>
> Major objective of this event is to "spread the word", say we want to
> introduce Qubes OS to new people and after this introduction there will be
> an install party. As this is not intend as a international community meet-up
> and for the sake of simplicity this event will be in German. The invitation
> with further details (in German) is attached to this email.
> If a community member that does not speak German but English happens to be
> in Cologne on that day (s)he is warmly welcome to join us and share user
> experiences, of course.
>
>
> for the Kölner Kreis,
> Robert Mittendorf

Awesome! Wish I could attend :)

One suggestion from my experience with Qubes at installfests: it saves
lots of time to have a flash drive with Qubes itself installed on it
(not the installer, but an installed system) to be able to check
hardware support before they touch their disk. Make that install
without sys-usb (and no rd.qubes.hide_all_usb boot arg). Also, you
should be aware of this outstanding bug [1], to avoid potential data
loss.

Another suggestion: when I presented about Qubes at a local conference
I set up a laptop with no personal data whatsoever which served to
showcase the abilities of Qubes and which I was happy to pass around
to whoever wanted to try it out themselves, without worrying at all
about what they might do to/with it. This first-hand experience alone
was enough to convince several hesitant people to make the jump, and
they are now running Qubes themselves. That laptop also had a windows
7 VM with the Qubes windows tools installed, and that had some "wow
factor" for several people.

Cheers,
Jean-Philippe

[1]: https://github.com/QubesOS/qubes-issues/issues/2835

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

Re: [qubes-users] Long-time Beta Users, do you wipe or upgrade?

[Jean-Philippe Ouellet]

On Thu, Jun 22, 2017 at 11:21 AM, Eric Duncan  wrote:
> Currently running Qubes 3.2 on one machine.  Have a need to install it on 
> another.
>
> To all of you long-term beta users of 3.x and now 4.x...
>
> 1a) Are upgrades simple to RTM versions of Qubes?
>
> Or 1b) Do you wipe and format each time a beta or RC comes out?
>
> I'm debating install Qubes 4.0 beta/rc, and going for the upgrade.
>
>
> Alternatively... Is there a way to use some type of "Testing" repo for Qubes? 
>  Something like rolling updates of Debian Testing does?
>
> I was perfectly happy with Debian Testing on a previous build, until I moved 
> to Arch which was a bit more stable with its rolling releases.
>
> I wouldn't mind installing a "rolling release" of Qubes under a Testing repo, 
> if there is one.
>
> Thanks!

Upgrading vs. reinstalling do not result in the same final system
state. I am nearly certain there are yet-unknown corner cases. This is
even true within the same Qubes release [1].

By upgrading R3.1 -> R3.2 I've ended up with a somehow messed up pam
config preventing any graphical logins, an application menu with stale
and broken entries, broken sound (residual xfce volumed not un-muting
the master channel bug), degraded trackpad drivers (leftover synaptics
drivers configured to take precedence over libinput) and undoubtedly
other things I didn't notice. I now reinstall and restore VMs every
time.

Upgrading is "supported" [2], but personally I think we should just
drop support for upgrading all together and force people to back up
their AppVMs and restore them onto the new install. People should be
doing backups anyway, re-importing with paranoid mode allows making a
clean break from potential old compromises, and upgrading isn't
actually as well tested as people may be lead to believe by the
existence of the upgrade docs.

Good luck,
Jean-Philippe

[1]: https://github.com/QubesOS/qubes-issues/issues/2742
[2]: https://www.qubes-os.org/doc/upgrade-to-r3.2/

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

Re: [qubes-users] Re: Best Laptop For Qubes

[Jean-Philippe Ouellet]

As for Purism, I have my gripes too, but at the end of the day I think
their existence provides a net-positive benefit to the community and
commodity hardware landscape.

Personally, I think Purism's marketing is perhaps a bit...
overoptimistic to a technical audience? And I do think they exaggerate
their openness compared to other options. That said, I do believe
their heart is in the right place, and that they do things like hiring
(?) Trammell Hudson to work on heads for their machines, and having
one of their staff work on revere engineering the non-removable ME
sections shows that. If their perhaps somewhat objectionable marketing
is necessary to sufficiently differentiate their products so they can
justify their higher price tag, and if that price tag is necessary to
stay alive and to fund the things they're working on that benefit the
community (specifically the low level stuff - I don't care about
PureOS), then so be it.

It initially seemed to me that Purism was just trying to capitalize on
less-technically-informed people's desire for privacy and security
without really delivering on that promise, but that seems not to be
the case after all, and I think they deserve more love than hate than
they're currently getting from the community.

Don't get me wrong, I'd love to ditch intel and foxconn and everybody
else and use a risc-v novena running genode or something to get my
work done, but unfortunately that day (decade?) isn't here yet, so in
the mean time let's be realistic and support those trying to
incrementally improve the things we can actually still get our work
done with.

As for the Raptor Talos and POWER in general, yes, I totally agree
it's leaps and bounds better than other commodity options, but I
couldn't afford one, it wouldn't fit in my backpack, and even if it
would I'm also not interested in carrying around a car battery just to
power my CPU for 5 minutes. I'd love to be proven wrong, but I don't
see it as a realistic option.

This is somewhat offtopic from Qubes, but oh well. That's where this
topic has drifted to, and the essay-rant is already written, so too
bad :P

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

Re: [qubes-users] Best Laptop For Qubes

[Jean-Philippe Ouellet]

On Mon, Jun 26, 2017 at 3:50 PM,   wrote:
> I know this question has been asked many times but there is still no 
> definitive answer. The Purism laptops do not have TPM support and in the HCL 
> list there is not a machine that ticks every box without issues. What 
> machines are the devs using? What laptop does Joanna use?

"best" is subject to one's perspective, so I don't think you'll get a
"definitive" answer. For example, which do you care most about: raw
performance, battery life, the openness of your boot sequence,
something else?

>From my personal experience and that other Qubes users I know IRL, any
used (to give hardware support a year or so to settle) X-series or
T-series thinkpads seem to hit a good balance between compute power,
hardware support, and price. The fact that they're popular among
hackers means they get more attention for hardware support (including
coreboot support for select models).

Personally, my day-to-day machine is a thinkpad x1 carbon with an i7
and 16gb ram. It took about a year, but hardware support is more or
less perfect now, with the exception of suspend/resume still failing a
couple times a month (not often enough for me to care, and I suspect
due to an embedded controller issue and not linux/xen). Battery life
is ~6 hours, but my workload is probably much heavier than the typical
user (usually 10-20 VMs running at a time, lots of DispVM starts, and
lots of compiling). The CPU is powerful enough to handle my workload
without issue.

I have friends happily running qubes on other thinkpads (X230, T430,
and various editions of the X1 carbon), and even one happily running
qubes on a macbook. One friend ran it on a dell and gave up due to bad
hw support (graphics & suspend/resume issues) and no patience for
messing with kernel versions, etc. YMMV.

Cheers,
Jean-Philippe

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

Re: [qubes-users] Where to bulk-download mailing list archives?

[Jean-Philippe Ouellet]

On Mon, Nov 14, 2016 at 3:48 PM, Marek Marczykowski-Górecki
<marma...@invisiblethingslab.com> wrote:
> On Mon, Nov 14, 2016 at 01:21:29AM -0500, Jean-Philippe Ouellet wrote:
>> Does anyone know of a convenient place to grab the complete archives
>> of this list? (and qubes-devel too?)
>>
>> With the (lets hope indeed temporary) death of gmane and its nntp
>> interface, I lost the only easy way I knew of to bulk-download the
>> entire history of arbitrary mailing lists for offline grepping.
>>
>> I'd rather not write yet another one-off web crawler if I don't need to...
>
> I don't know how to download it from google, but I know how to download
> it from my personal mailbox ;) This is what was uploaded to gmane.
>
> https://ftp.qubes-os.org/~marmarek/qubes-users.tar.gz
> https://ftp.qubes-os.org/~marmarek/qubes-devel.tar.gz
>
> Archives are from May. I can upload newer, but better find some service
> which would do that - some gmane alternative.

Gmane still appears mostly dead, with no indications of coming back soon.

Maybe MailMark? Not as nice as gmane was, but they have better search
and a friendlier interface than both google-groups and marc.info
(which currently archives qubes-users and qubes-devel).

They claim to accept requests for new lists:

from http://markmail.org/docs/faq.xqy#morelists:
> Absolutely. We're constantly loading new list archives. We prioritize
> which list archives to load based on feedback, so let us know if you'd
> like us to host the archives for your community.

from http://markmail.org/docs/feedback.xqy:
> Want us to host a new list? Let us know! It helps if you can give us the
> homepage for the list and/or the contact info to the administrator. Also,
> let us know if you know how we can find the historical archives.

Perhaps worthwhile?

Regards,
Jean-Philippe

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

Re: [qubes-users] ERROR: Cannot execute qrexec-daemon! after completely new installation of QUBES R3.2

[Jean-Philippe Ouellet]

On Thu, May 25, 2017 at 4:46 AM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> On Wed, May 24, 2017 at 6:45 AM, frigge <m...@sfricke.com> wrote:
>> Hi qubes-users,
>>
>> I installed a completely fresh installtion of QUBES R3.2 on a Lenovo v570 
>> notebook and if I try to start any VM, I receive the following error:
>>
>> $ qvm-star sys-net
>> --> Creating volatile image: 
>> /var/lib/qubes/servicevms/sys-net/volatile.img...
>> --> Loading the VM (type = NetVM)...
>> --> Starting Qubes DB...
>> --> Setting Qubes DB info for the VM...
>> --> Updating firewall rules...
>> --> Starting the VM...
>> --> Starting the qrexec daemon...
>> Waiting for VM's qrexec agent...failed
>> ERROR: Cannot execute qrexec-daemon!
>>
>> This behaviour is the same for every VM.
>> Any ideas what can I do/check?
>>
>> If you need further information, please let me know.
>>
>> Thanks for your support!
>>
>> Best regards
>> frigge
>
> Just a random hunch...
>
> Did you verify the installation medium (flash drive or so) before
> installing? (Wait for the percentage to go to 100% and say disk is
> okay?)

But as for things to check, I'd check the VMs logs (right click on one
in Qubes Manager -> Logs (at the bottom) ->
/var/log/xen/console/.log, and see if your VM is failing to
boot for some reason.

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

Re: [qubes-users] ERROR: Cannot execute qrexec-daemon! after completely new installation of QUBES R3.2

[Jean-Philippe Ouellet]

On Wed, May 24, 2017 at 6:45 AM, frigge  wrote:
> Hi qubes-users,
>
> I installed a completely fresh installtion of QUBES R3.2 on a Lenovo v570 
> notebook and if I try to start any VM, I receive the following error:
>
> $ qvm-star sys-net
> --> Creating volatile image: /var/lib/qubes/servicevms/sys-net/volatile.img...
> --> Loading the VM (type = NetVM)...
> --> Starting Qubes DB...
> --> Setting Qubes DB info for the VM...
> --> Updating firewall rules...
> --> Starting the VM...
> --> Starting the qrexec daemon...
> Waiting for VM's qrexec agent...failed
> ERROR: Cannot execute qrexec-daemon!
>
> This behaviour is the same for every VM.
> Any ideas what can I do/check?
>
> If you need further information, please let me know.
>
> Thanks for your support!
>
> Best regards
> frigge

Just a random hunch...

Did you verify the installation medium (flash drive or so) before
installing? (Wait for the percentage to go to 100% and say disk is
okay?)

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

Re: [qubes-users] Re: Can't rename appvm?

[Jean-Philippe Ouellet]

On Sun, May 21, 2017 at 4:41 PM, Gaiko  wrote:
> On Friday, May 19, 2017 at 9:35:26 PM UTC-4, cooloutac wrote:
>> On Friday, May 19, 2017 at 2:48:03 PM UTC-4, Gaiko wrote:
>> > I tried to rename my anon-whonix appvm through the qubes-manager, right 
>> > click, vm settings, name & label. This worked fine for other appvms but 
>> > this time it didn't seem to change the name. Strangely it did change the 
>> > private storage to 0mb and now when I try to change the mem to something 
>> > else I get:
>> >
>> >
>> >
>> > ERROR: Basic tab:
>> > [Errno 2] No such file or directory: 
>> > '/var/lib/qubes/appvms/anon-whonix/private.img'
>> >
>> >
>> >
>> >
>> > Or to change the vm name (which still shows up as "anon-whonix") I get:
>> >
>> >
>> >
>> > ERROR: Basic tab:
>> > [Errno 2] No such file or directory
>> >
>> >
>> > I looked in /var/lib/qubes/appvms/ and the anon-whonix-renamed dir is 
>> > there as I think it should be but the qubes manager doesn't seem to know 
>> > this. I tried restarting qubes (simple reboot) and that didn't work. So I 
>> > am now not quite sure where to go from here?
>> >
>> >
>> > Thoughts? Thx.
>> I was able to change mine.  Pretty strange.  Check smartctl in dom0.  do a 
>> memory check overnight?
>>
>> If I was your I would just backup any data delete the vm and create a new 
>> one or delete and restore from older.  cause its suspect.
>
> Thanks. I ended up deleting it and then making a new one, not ideal though. 
> In the future how would I have packed it up? Could I have just copied the 
> private.img to a new anon-whonix appvm and overwritten the old one?

Known issue [1], not yet fixed.

[1]: https://github.com/QubesOS/qubes-issues/issues/2054

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

Re: [qubes-users] HCL

[Jean-Philippe Ouellet]

FWIW, considering the trade-off between marginally improved
performance and hardware support, I've had better overall experiences
with hardware that's 1-2 years old.

- Just some random guy on the internet's personal opinion...

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

Re: [qubes-users] Re: start application on startup

[Jean-Philippe Ouellet]

On Sun, May 21, 2017 at 4:49 AM,   wrote:
> On Sunday, May 21, 2017 at 4:47:19 AM UTC+10, aforete wrote:
>> Am I doing something wrong here? is there any other way to start
>> applications once a vm starts?
>
> Yes, you can do the following in your AppVM:
>
> 1) make the directory /home/user/.config/autostart if it doesn't already exist
>
> 2) add a file inside that directory called (e.g) thunderbird.desktop that 
> contains the following lines
>
> [Desktop Entry]
> Name=thunderbird
> Exec=thunderbird
> Type=Application
>
> Reboot your AppVM and Thunderbird should start. Rinse and repeat for any 
> other app.
>
> The reason this works is that the autostart files are processed *after* the 
> user's X session has started up.

In this case (graphical applications) the desktop entry may be the
better solution due to enforced startup ordering, but note also that
/rw/config/rc.local was created for similar purposes and may be a
suitable place for other per-VM "at startup" actions. See [1] and [2]
for more info.

Cheers,
Jean-Philippe

[1]: https://www.qubes-os.org/doc/config-files/
[2]: 
https://github.com/QubesOS/qubes-core-agent-linux/blob/9f9c3c56fce8dbbeacacf7fd765850ccf9d252d3/init/setup-rw.sh#L22-L35

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

Re: [qubes-users] Split SSH

[Jean-Philippe Ouellet]

Cross referencing for better archives:
https://github.com/QubesOS/qubes-issues/issues/1962#issuecomment-296310537

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

Re: [qubes-users] CLI: How to read out the currently set base image for disposable VMs?

[Jean-Philippe Ouellet]

On Sat, May 20, 2017 at 4:10 PM, Unman  wrote:
> On Sat, May 20, 2017 at 09:28:48PM +0200, Johannes Graumann wrote:
>> See subject line ;)
>>
>> Joh
>
> ls -l /var/lib/qubes/dvmdata/*
>
> This will show you which dvmTemplate is being used to generate the
> disposableVMs

And in case you're trying to find this out from inside the vm:

$ qubesdb-read /qubes-base-template

works for non-DispVMs too.

Cheers,
Jean-Philippe

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

Re: [qubes-users] https://www.qubes-os.org/doc/vpn/

[Jean-Philippe Ouellet]

On Sat, May 20, 2017 at 1:36 PM, fooyreb  wrote:
> Helo,  So, I've setup a proxyVM for the VPN, via the "CLI version"
> https://www.qubes-os.org/doc/vpn/
>
> However, when I suspend Qubes, and wakeup Qubes, the networking is lost,
> I then have to shut down or alter the network choice for 2-3 AppVMs that
> use it and restart the ProxyVM, I'd rather not do this.
>
> Is there some argument or tweak to change this type behaviour, or is
> this by design, that this happens?   for my "security"  :)
>
> I'd include the log, if I knew where to find the right one .
>
> sorry if this isn't too qube-y of a question, maybe it is 

Maybe you want some kind of auto-reconnect or reconnect triggered on
suspend/resume [1]?

[1]: https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks

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

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

[Jean-Philippe Ouellet]

On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-05-14 03:51, Holger Levsen wrote:
>> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
 you really dont protect your gpg key with a passphrase??
>>> See: https://www.qubes-os.org/doc/split-gpg/
>>
>> oh wow :(
>>
>>> Why is that a problem? It's only visible in dom0. If an attacker is in
>>> dom0, it's already game over.
>>
>> no, the world is not black and white.
>>
>> If an attacker steals your computer while it's unlocked, all your gpg
>> encrypted stuff is wide open.
>>
>> If an attacker steals my computer while it's unlocked, my gpg encrypted
>> stuff is still locked. Surely the attacker can now install as many backdoors 
>> as
>> they want, but as long as I don't type my gpg passphrase into that computer
>> anymore, it should be pretty safe.
>>
>
> You're conflating two distinct problems:
>
> (1) Passphrases I've typed in dom0 are available in cleartext in
> dom0.
> (2) Data-at-rest is not encrypted while Qubes is booted and the screen
> is unlocked.
>
> We could solve (1) without solving (2). If we did that, it would solve
> the `ps` + qvm-backup problem (the first problem you mentioned), since
> my backup would be encrypted, and the thief wouldn't have access to the
> backup decryption passphrase.
>
> (2) is the second problem you mentioned. Solving (2) is distinct from
> solving (1), but in order for the solution to (2) to be satisfactory, we
> also have to solve (1) (or make sure no similar problem arises for
> per-VM encryption), since otherwise my data-at-rest passphrase could be
> obtained via (1).
>
> I think the right approach to (2) in Qubes is per-VM encryption [1]
> (probably with LUKS instead of GPG, and certainly not relying on public
> key crypto, though hopefully we're all already in agreement on the
> latter point). If I'm in an untrusted physical environment, I should be
> able to work with less sensitive VMs without decrypting sensitive VMs,
> and if someone steals my unlocked laptop, they shouldn't be able to gain
> access to the encrypted sensitive VMs. That's the goal, anyway.
>
>
> [1] https://github.com/QubesOS/qubes-issues/issues/1293

Solving 1 is not a simple matter of patching some things to pass
passwords on stdin instead of argv or env vars, it would still be a
mostly trivial matter for an attacker to just make a core dump and run
strings on it. Rather, I believe a proper solution to 1 would require
that dom0 to some degree distrust whoever is physically at the
keyboard. A "kiosking" of Qubes, if you will.

Also, I do not agree on your assessment about symmetric crypto being
obviously the way to go. I think there is value in being able to
initiate a backup from inside a hostile environment (think: someplace
with cameras everywhere watching any passphrase you would enter),
which would make sense to implement by encrypting to an asymmetric
keypair for which the private half is only in a separate physical
environment. (Sure, yes, use a symmetric algo for the bulk encryption
and just encrypt that with the asymetric algo... not my point.) You
would not be able to decrypt your own backups until you had regained
access to the private half, but you would be able to start backups
without needing to divulge your backup secret at the same time. In
this scheme you would also have another keypair with the secret part
on your laptop in order to sign the backup (authenticating it with an
asymmetric signature without requiring a passphrase at backup-creation
time). I've made this argument before, but perhaps never presented it
well enough. Expect a PoC in the hopefully not-too-distant future.

Regards,
Jean-Philippe

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

Re: [qubes-users] how to check integrity about DVD

[Jean-Philippe Ouellet]

On Tue, May 16, 2017 at 9:41 PM, Andrew David Wong  wrote:
> On 2017-05-16 16:42, h...@e.shapoo.ch wrote:
>> I verified signature about qubes ISO file by gpg.Then I burned it to DVD.
>> But I can't trust that DVD was burned without corruption.
>> So I want to verify integrity against the DVD too.
>>
>> Is someone know how to verify signature against DVD?
>>
>>
>> At moment, I want my privacy to be protected.
>> https://mytemp.email/
>>
>
> I'm not aware of a method to gpg --verify an ISO directly from a DVD
> after it has been burned, but you can re-create the ISO from the DVD,
> [1] then gpg --verify the re-created ISO. [2]
>
>
> [1] 
> https://www.thomas-krenn.com/en/wiki/Create_an_ISO_Image_from_a_source_CD_or_DVD_under_Linux
>
> [2] If you're worried that the re-created ISO might not truly represent
> what's on the DVD because you're worried that your software environment
> might be compromised and lying to you, then I'd point out that the same
> compromised software environment could also lie to you about the results
> of verifying the DVD directly.

IIRC it is legal and works as expected to pass a block device as the
file to be verified with gpg, e.g.
$ gpg --verify Qubes-R3.2-x86_64.iso.asc /dev/sr0

However, I know I have just done:
$ sudo cat /dev/sr0 | sha256sum -
and compared against a known-good hash.
or
$ sudo head -c $((1024*1024*4)) /dev/sr0 | sha256sum -
in the case of larger devices (like flash drives) which do not report
a certain size (like burned DVDs), and then verified that the rest of
the media is zeroes (dd skip=...) because I'm paranoid like that and
don't know what might read past the end of intentionally written data
and what parsers it might reach.

I'm happy to be corrected, but I do not see the need for re-creating
an ISO on your disk unless you find your DVD to be wrong and want to
do some forensics.

Non-write-once media, or media with embedded computing capability and
persistent and mutable state (like flash drives) have other concerns
however.\

Cheers,
Jean-Philippe

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

Re: [qubes-users] Games on Qubes + Whonix

[Jean-Philippe Ouellet]

On Mon, May 15, 2017 at 9:40 AM,   wrote:
> Hello! I'm a beginner and maybe ask a stupid question. I know that Qubes OS 
> itself does not support 3D graphics. But can I play games (Steam) if I 
> connect to Qubes Whonix as a virtual machine? It's a Linux distribution and 
> it itself supports Steam. Here it is about Qubes + Whonix: 
> https://www.whonix.org/wiki/Qubes.
> Thank you!

Steam itself works no problem (I've used it in a StandaloneVM). Games
are hit and miss.

Software rendering performance seemed high enough for most 2d games
and even some old / non-demanding 3d games (ancient Unreal games were
"playable"). Really can't say I've spent a lot of time playing them
though, it was more an afternoon project of "Hmm... I wonder if this
works..." than anything else. I'm not a gamer, and my tolerance for
poor gaming performance is quite likely higher than most.

Input grabbing is indeed an issue though as Vit points out.

I should mention this was all on linux, with Windows-only things run
in Wine. I never personally tried on windows HVMs, but they seem
somewhat sluggish even for basic non-game tasks so I'd imagine it
wouldn't be great unless you passed through a dedicated GPU and USB
controller with separate input devices or something.

Cheers,
Jean-Philippe

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

Re: [qubes-users] Windows 7 HVM Install

[Jean-Philippe Ouellet]

On Mon, May 15, 2017 at 5:24 PM, Sam Hentschel  wrote:
> Hey all!
>
> Decided to try out making a windows 7 install just in case I needed it
> for school.
>
> I downloaded a 64-bit windows 7 enterprise iso and proceeded with the
> installation doing:
>
> $ qvm-create win7 --hvm --label green  #as in the qubes-docs
> $ cp /var/lib/qubes/appvms/win7/win7.conf ~/ # to change xen to 
> cirrus for graphics
> $ qvm-start --cdrom:dispXX:/home/user/Downloads/win7_sp1_64.iso
> --custom-config=win7.conf
>
> The first install went fine, I got it to boot up the first time and
> tried to load the windows tools:
>
> $ sudo qubes-dom0-update qubes-windows-tools
> $ qvm-start --custom-config=win7.conf --install-windows-tools
>
> However, something messed up and it wouldn't get passed the start up
> screen after that (I don't think it actually installed the windows tools
> as I didn't see the disk show up).  I tried using all the combinations
> of commands I had for qvm-start before I gave up.  I deleted it using
> qvm-remove and retried to make the windows 7 hvm.
>
> I followed the same steps above; however, when I got to the first
> qvm-start I get the following:
>
> --> Loading the VM (type = HVM)...
> Traceback (most recent call last):
>   File "/usr/bin/qvm-start", line 136, in 
> main()
>   File "/usr/bin/qvm-start", line 120, in main
> xid = vm.start(verbose=options.verbose, 
> preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, 
> notify_function=tray_notify_generic if options.tray else None)
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 335, 
> in start
> return super(QubesHVm, self).start(*args, **kwargs)
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1952, 
> in start
> self._update_libvirt_domain()
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 764, 
> in _update_libvirt_domain
> raise e
> libvirt.libvirtError: operation failed: domain 'win7' already exists 
> with uuid 27a11689-a44e-4442-b11a-112b2728c511
>
> If I run the command without the --custom-config option it starts, and
> hangs at startup as usual; so I'm guessing its a problem with my config?

I've seen this happen when qubes-manager / libvirt / xen get out of
sync. "Simplest" fix is to reboot.

Otherwise, I'd do in dom0:
$ killall qubes-manager # or right-click the tray icon -> Exit
$ xl list # check for win7 vm
$ ls /var/lib/qubes/appvms # check for win7 dir
$ grep win7 /var/lib/qubes/qubes.xml # should produce no results
$ sudo systemctl restart libvirtd # this is what really matters
and re-launch qubes-manager from the Q menu

It's a bug, but I haven't found time to look into it. If you know how
to reproduce reliably, definitely open an issue.

Cheers,
Jean-Philippe

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

Re: [qubes-users] Help adding documentation to Qubes Repository

[Jean-Philippe Ouellet]

On Sat, May 13, 2017 at 4:22 PM, Andrew David Wong  wrote:
> On 2017-05-13 14:27, Zbigniew Łukasiak wrote:
>> This is something I am also struggling with - but shouldn't there
>> be a sign-off line in all the commit comments as described in
>> https://www.qubes-os.org/doc/license/ ?
>
> No, that only applies to Qubes OS code.

Except in practice it doesn't apply there either. See comments in #2517 [1].

[1]: https://github.com/QubesOS/qubes-issues/issues/2517#issuecomment-266658039

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

Re: [qubes-users] Why should I clone a template?

[Jean-Philippe Ouellet]

On Sat, May 20, 2017 at 8:43 PM, Todd Lasman  wrote:
> The dogma, as I understand it, is that it's safer to clone a template, make
> changes to the clone, then base your AppVM's off of that cloned template.
>
> - From the Qubes website:
> "It is highly recommended to clone the original template, and make any
> changes in the clone instead of the original template. The following command
> clones the template. Replace your-new-clone with your desired name..."
>
> My question is, why? It seems to me that if you ever needed the original
> template back, you could just download it again from the repository. Am I
> missing something?

Two reasons personally:

1) If you find yourself wanting to create an additional template in
the future not inheriting the changes of your existing templates, it
is convenient to have a minimal / default template around to clone in
order to guarantee a fresh start.

2) Testing if some observed behavior is also present in a "default" vm
before reporting issues upstream.

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

Re: [qubes-users] Lenovo X1 Carbon 1.gen

[Jean-Philippe Ouellet]

On Sun, May 21, 2017 at 10:00 AM, Finsh  wrote:
> i recently got interested in the Qubes and i'm thinking on installing it
> on a Lenovo X1 Carbon 1gen Type: 3460-1F4.
>
> I couldn't find this specific Model in the HCL, are there any known issues?

I also ran on a 1st gen X1 (lenovo type 3443, 16gb ram, some
2xxx-series i7, 256gb disk) for a few months on stock BIOS. I only
switched to a newer (4th gen) X1 because I had a hardware failure on
my old one. If I didn't need to resume being productive immediately I
would have preferred to fix the old one rather than replace it,
especially so in hindsight given that I just lived with broken
suspend/resume for a while on my 4th gen (fixed now).

All hardware was well-supported IIRC, and it was more than adequate
performance-wise, even for my usual workload of ~10 simultaneous VMs
and lots of compiling stuff.

The fact that it allegedly runs coreboot almost makes me wanna try to
fix it and go back to it! :) IIRC it even had external USB ports on
separate USB controllers whereas my 4th-gen X1 does not. Overall a
solid Qubes laptop, would recommend.

Cheers,
Jean-Philippe

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

Re: [qubes-users] Windows hanging at starting up screen (changing xen video -> cirrus not working?)

[Jean-Philippe Ouellet]

On Sat, Apr 29, 2017 at 10:34 AM, Gaiko Kyofusho
 wrote:
> I am trying to setup a win7 template. I started with the:
>
> qvm-create --hvm-template win7-x64-template -l green
>
> which seemed to work well enough, then tried to install windows (win7 pro
> x64). When I try using:
>
> qvm-start win7-x64-template --cdrom=/home/user/win7.iso
>
> It starts up and then hangs (I've tried leaving it overnight, no progress)
> at the glowing starting windows. I then searched around and found two posts
> and the github work around of
>
> cp /var/lib/qubes/appvms/win7/win7.conf /tmp
>
> then mod'ing the  line to cirrus then
> running
>
> qvm-start win7-x64-template --cdrom=/home/user/win7.iso
> --custom-config=/tmp/win7.conf
>
> now I get an error:
>
> --> Loading the VM (type = TemplateHVM)...
> Traceback (most recent call last):
>   File "/usr/bin/qvm-start", line 136, in 
> main()
>   File "/usr/bin/qvm-start", line 120, in main
> xid = vm.start(verbose=options.verbose,
> preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
> notify_function=tray_notify_generic if options.tray else None)
>   File
> "/usr/lib64/python2.7/site-packages/qubes/modules/02QubesTemplateHVm.py",
> line 94, in start
> return super(QubesTemplateHVm, self).start(*args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py",
> line 335, in start
> return super(QubesHVm, self).start(*args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py",
> line 1972, in start
> self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
> createWithFlags
> if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
> dom=self)
> libvirt.libvirtError: internal error: libxenlight failed to create new
> domain 'win7'
>
> thoughts?

That stack trace suggests xen/libvirt/qubes-manager state mismatch
I've seen happen on rare occasion.

Shot in the dark, try:
[user@dom0 ~]$ sudo systemctl restart libvirtd.service

or try re-creating with different VM name.

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

Re: [qubes-users] OpenWhisper Systems Signal not quite right in Qubes 3.2/Fedora23/Chromium

[Jean-Philippe Ouellet]

On Sun, May 7, 2017 at 10:05 PM, Neal Rauhauser  wrote:
> I installed Qubes 3.2 on a Dell Precision M4600 (slick) and I've been trying 
> to migrate a portion of my day to day work to it.
>
> I have many contacts who use Open Whisper Systems Signal App for 
> communication. I've used the Google Chrome extension on both OSX and Linux 
> without any troubles.
>
> Using a Fedora 23 VM I found Chrome installs to be clumsy, while yum install 
> chromium just works. The Signal Chrome App installs and runs, but the 
> directory function is broke. Existing conversations are fine, but they are 
> with phone numbers rather than names, and I can't look up any other contacts 
> to initiate conversations, I have to wait for them to come to me.
>
> Has anyone else already resolved this problem? This is a "beachhead issue" 
> for me - if I can get Signal going, I can switch a good sized chunk of what I 
> do to Qubes.

I use signal in Qubes daily and can confirm it works great.

It does appear that the contacts list syncing is a one-time event at
setup and not a continuous thing, but I believe this is a known Signal
issue, and in no way specific to Qubes. See:
- 
https://support.whispersystems.org/hc/en-us/articles/218514998-How-do-I-update-contacts-on-Signal-Desktop-
- https://github.com/WhisperSystems/Signal-Desktop/issues/1001
- https://github.com/WhisperSystems/Signal-Desktop/issues/443

For more information about Signal on Qubes in general, see:
- https://www.qubes-os.org/doc/signal/

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

Re: [qubes-users] How to get trusted iso?

[Jean-Philippe Ouellet]

On Sun, May 7, 2017 at 2:41 PM, cooloutac  wrote:
> On Monday, May 1, 2017 at 3:03:05 PM UTC-4, Chris Laprise wrote:
>> On 05/01/2017 02:33 PM, cooloutac wrote:
>> > I know I can't buy one, so how do I get an a fresh iso if my machine
>> > is compromised?  Obviously,  someone more prudent would of kept their
>> > original iso on dedicated usb stick. But I was too cheap.
>>
>> I'll go out on a limb and say that Qubes is more about defending against
>> oncoming threats.
>>
>> Pre-existing compromise creates a dilemma for the user, who can
>> pragmatically try to minimize further compromise by degrees. For
>> instance, burn a DVD and then verify it on multiple machines (incl.
>> different architectures). This is not unlike trying to validate the
>> authenticity of a PGP key using different network channels (not quite
>> "out of band" but possibly effective).
>>
>> >
>> > So what happens if that was not done,  or how can someone get a
>> > trusted iso for the first time in the first place?  Is just checking
>> > key signatures and using dd on a compromised machine enough? I
>> > imagine that would be dangerous.
>> >
>> > Thanks for any suggestions.
>>
>> Since you will probably want to start with Qubes on a non-compromised
>> machine, I suggest to download and verify using that.
>>
>> --
>>
>> Chris Laprise, tas...@openmailbox.org
>> https://twitter.com/ttaskett
>> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
>
> this post makes me think about healthcare debate lol.  last to universal 
> healthcare is also last to end slavery. not a coincidence.
>
> But ya i'll go out on a limb and say most of us are using Qubes cause we were 
> already compromised before,  and we are using it still believing we will be 
> compromised in the future.
>
> If there is no way to get a trusted iso there is no point in using Qubes.

I am not aware of any mechanism by which to have a 100% guarantee, but
then... do you really need one?

At some point, you just have to say "well... good enough". Even if you
were to buy install media, as you suggest, how are you sure your
physical mail wasn't intercepted?

I believe the "create read-only media and verify it on diverse
machines" approach should be sufficient. Breaking it should require
either some rather versatile exploit for something along the
(hopefully diverse) set of components involved in reading & verifying
the media from the multiple systems you use to check it, or for all of
those machines to be independently targeted, possibly with advance
knowledge of the DVD you're about to try to verify. IMO that's
sufficiently unlikely to be worth worrying about.

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

Re: [qubes-users] Re: GPU passthrough: 2000 USD bounty

[Jean-Philippe Ouellet]

I don't know anything about your specific hardware, but it is true
that secondary GPUs are often not connected to the display itself, but
rather the rendering takes place there and then the rendered frames
are passed back to the host and to the integrated gpu to be put on
your display. From a Qubes perspective I believe this is actually a
very good thing since it means we could keep the integrated GPU
statically assigned to dom0, and keep the qubes gui protocol largely
unchanged. The question would be one of getting the passed through GPU
to render its output to some buffer which we pass back to dom0.

There are still firmware-security issues associated with passing the
discrete GPU between VMs of different trust levels, because someone
who has full control of the GPU may be able to re-flash its firmware
with something that would later perform a DMA attack against the 2nd
VM it's attached to. However, if you only ever wish to pass it through
to a single "gaming" windows HVM or such, this is not a problem.

The reason integrated GPUs are interesting in this regard is that they
do not have firmware which is persistently stored on the device,
rather it is loaded externally on each power-on and subject to normal
boot-security measures. The thinking is that by rebooting between
assigning your integrated GPU to different VMs, you prevent one from
compromising another via the GPU by making GPU compromise ephemeral.

As for previous successes requiring upstream-QEMU in dom0, the problem
here is that Xen only supports a very old forked QEMU in stubdomains,
but this is something that will change. Progress in this area has
stalled because there was an effort to run QEMU in a very minimal
unikernel-style environment, but this effort has been abandoned and
work is now underway towards making it run on top of linux (still in a
separate stubdomain), which should take less work to bring to a usable
state than the previous minimal-stubdom effort.

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

Re: [qubes-users] Focus Stealing, how to stop it?

[Jean-Philippe Ouellet]

On Fri, Apr 21, 2017 at 10:00 PM, Andrew David Wong <a...@qubes-os.org> wrote:
> On 2017-04-20 21:56, Jean-Philippe Ouellet wrote:
>> On Thu, Apr 20, 2017 at 10:17 PM, taii...@gmx.com <taii...@gmx.com>
>> wrote:
>>> How do I stop focus stealing? I have accidentally entered ssh
>>> passwords in to other windows as they keep stealing focus for
>>> irrelevant things.
>>
>> AFAIK there is no consensus on how to best solve this problem.
>>
>> It has come up before in various forms:
>> https://github.com/pulls?utf8=%E2%9C%93=org%3AQubesOS+focus+stealing
>>
>>  Suggestions & proof-of-concept implementations would be most
>> appreciated!
>>
>
> Personally, I just set all the normal (i.e., GUI settings menu
> accessible) settings in Xfce4 to their maximally anti-focus-stealing
> values. Some users may find this too inconvenient, but I've gotten
> used to it. I never have problems with windows stealing focus.

What does this mean? What specifically do you change?

Just disable "Automatically give focus to newly created windows"?
Something else?

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

Re: [qubes-users] say it out (loud) - Qubes OS Stickers

[Jean-Philippe Ouellet]

On Fri, Apr 21, 2017 at 8:16 AM, Franz <169...@gmail.com> wrote:
> On Thu, Apr 20, 2017 at 7:57 PM, cooloutac  wrote:
>> On Thursday, April 20, 2017 at 6:07:45 PM UTC-4, Francesco wrote:
>> > On Thu, Apr 20, 2017 at 4:16 PM, J. Eppler 
>> > I really like the simple design from Brennan Novak.
>> >
>> > Writing on a sticker "a reasonable secure operating system" is very
>> > rational and balanced, but is too long to find its place close to the
>> > keyboard. Perhaps just a single word coupled with the logo, like "secure" 
>> > or
>> > "secured" or "security" or something similar.
>>
>> "somewhat secure"
>
> "Security Focus"

That invokes thoughts of something specific and different:
http://www.securityfocus.com/ & the mailing lists there like Bugtraq.
Not exactly 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/CABQWM_A1s72tnTjgSN%2BEYg1dh%2B%2B3LRJjQ0tCs%3D-8zKDkyu_6%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Bug with copy and paste to different window

[Jean-Philippe Ouellet]

On Fri, Apr 21, 2017 at 5:22 AM, evo  wrote:
> I have a problem with an appVM based on Fedora24.
> I open LibreOffice and Scribus, then i want to copy and paste from
> office. But if i copy it from office and go to the scribus-window the
> window is not activated... it just still acts with the office-window
> behind the scribus-window... just so, if the scribus-window does not exist.
>
> Is it a bug or something else??

https://github.com/QubesOS/qubes-issues/issues/1455 ?

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

Re: [qubes-users] Focus Stealing, how to stop it?

[Jean-Philippe Ouellet]

On Thu, Apr 20, 2017 at 10:17 PM, taii...@gmx.com  wrote:
> How do I stop focus stealing? I have accidentally entered ssh passwords in
> to other windows as they keep stealing focus for irrelevant things.

AFAIK there is no consensus on how to best solve this problem.

It has come up before in various forms:
https://github.com/pulls?utf8=%E2%9C%93=org%3AQubesOS+focus+stealing

Suggestions & proof-of-concept implementations would be most appreciated!

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

Re: [qubes-users] qubes manager add start terminal

[Jean-Philippe Ouellet]

On Mon, Apr 17, 2017 at 9:39 AM, Eva Star  wrote:
> On 04/17/2017 03:11 AM, Unman wrote:
>
>> I've done some manager hacking myself - some of it now incorporated in
>> release.
>> If you dont want to build a package then you can simply start hacking in
>> /usr/lib64/python2.7/site-packages/qubesmanager.
>> (Back this up first, of course.)
>>
>> Beside the ui elements in ui_mainwindow the slots are in main.py. If
>> you're going to hack these remember to remove the compiled files.
>> I'd recommend using xterm, as it's in all the templates afaik.
>>
>
> Unfortunately main.py contain only functions.
> UI elements located not at qubesmanager dir. They are compiled? How?
> Need to modify this file :
> https://github.com/QubesOS/qubes-manager/blob/master/mainwindow.ui

Yes, they get "compiled" during package build like this [1]. You can
either invoke pyuic4 yourself, or just use qubes-builder to build new
qubes-manager packages and install them in dom0. I personally find the
build pkg & reinstall method easier.

[1]: 
https://github.com/QubesOS/qubes-manager/blob/46b892edb15f5fbc86b6f492ed4ffe61e2b1f491/Makefile#L19-L33

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

Re: [qubes-users] Secure Handling of Encrypted Drives

[Jean-Philippe Ouellet]

On Sun, Apr 16, 2017 at 7:59 PM, Andrew David Wong <a...@qubes-os.org> wrote:
> On 2017-04-12 13:05, Sam Hentschel wrote:
>> On Wednesday, April 12, 2017 at 3:20:30 PM UTC-4, Chris Laprise
>> wrote:
>>> On 04/12/2017 02:37 PM, Jean-Philippe Ouellet wrote:
>>>> On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel
>>>> <hentsche...@gmail.com> wrote:
>>>>> On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman
>>>>> wrote:
>>>>>> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel
>>>>>> wrote:
>>>>>>> I am trying to figure out a way to securely handle my
>>>>>>> encrypted drives without two things: connecting the USB
>>>>>>> directly to the Vault (as this is obviously a bad idea
>>>>>>> for security), and decrypting the USB in sys-usb (also
>>>>>>> obviously a bad idea).
>>>>>>>
>>>>>>> As an example, I have some USB that I keep encrypted
>>>>>>> backups of my important documents that I keep with me in
>>>>>>> case an emergency happens (which now that I am using
>>>>>>> Qubes will probably also be in the Vault).  I have files
>>>>>>> on there that I need to move to Vault, and I need to be
>>>>>>> able to continue to put files onto it (whether from
>>>>>>> Vault or from a scan I have done.  >>>>>> writing some documentation hopefully on what I did giving
>>>>>>> DispVMs the sole ability to print and scan.>  Which I
>>>>>>> know is a whole different problem; so I want to focus on
>>>>>>> just the encrypted storage.
>>>>>>>
>>>>>>> Another example is my backup drives which are all
>>>>>>> encrypted, and that I would like to have access to for
>>>>>>> the standard reasons.  I have been pointed to [1] a
>>>>>>> couple days ago by JPO and I believe this is part of the
>>>>>>> soution, but not the whole thing.
>>>>>>>
>>>>>>> My two solutions that I have thought through are: doing
>>>>>>> PCI patthrough directly to the Vault (which is the least
>>>>>>> favorite of my ideas), and creating a separate VM for
>>>>>>> encryption that only houses software for encrypting and
>>>>>>> decrypting (dm-crypt or veracrypt).  This way the USB
>>>>>>> will be passed through to this VM and will never
>>>>>>> directly touch the Vault (except through
>>>>>>> qvm-move-to-vm).
>>>>>>>
>>>>>>> I had a third solution of adding this functionality to
>>>>>>> DispVMs, but I can't PCI pass the USB to the DispVMs
>>>>>>> when they are running.  So that one is out.
>>>>>>>
>>>>>>> Thanks in advance for the help; can't wait to see what I
>>>>>>> missed!
>>>>>>>
>>>>>>> [1] https://github.com/rustybird/qubes-split-dm-crypt
>>>>>>>
>>>>>>
>>>>>> Hi Sam,
>>>>>>
>>>>>> I'm obviously missing something here.
>>>>>>
>>>>>> One of your two solutions fits completely within the
>>>>>> current Qubes model and matches exactly the specification
>>>>>> you set; that is, qvm-block attach the encrypted drive to
>>>>>> a qube and decrypt it there. Can I ask what more you are
>>>>>> looking for?
>>>>>>
>>>>>> There's no need to do this in a separate decryptionVM -
>>>>>> you can use a disposableVM for the purpose.
>>>>>>
>>>>>> If you don't want to have the decryption software in a
>>>>>> standard template, then put it in a separate template,
>>>>>> build a distinct disposableVM from that template and use
>>>>>> my hack to fire up that disposableVM when you want to use
>>>>>> a decrypted drive.
>>>>>>
>>>>>> unman
>>>>>
>>>>> Unman,
>>>>>
>>>>> I was just making sure I wasn't missing something or there
>>>>> wasn't a better way.  Anyways, I can't set this up in a
>>>>> DispVM because you cannot PCI passt

Re: [qubes-users] HW RNG on dom0?

[Jean-Philippe Ouellet]

On Mon, Apr 10, 2017 at 8:23 AM, Johannes Graumann
 wrote:
> I am wondering whether
> 1) under QubesOS a (USB) HW RNG like http://www.bitbabbler.org/ is usable

Yes. You would need to do some work to make it feed entropy in a safe
way though.

> and if yes
> 2) where attaching it would make most sense? sys-net? dom0?

sys-usb, and have a qrexec service in dom0 to collect entropy from it
and mix in into the dom0 pool, which will eventually propagate to
other VMs.

> Can Xen VM's be set up to feed on entropy provided by the host?

Yes, in fact we already do so.

Discussion:
- https://github.com/QubesOS/qubes-issues/issues/673
- https://groups.google.com/d/topic/qubes-devel/5wI8ygbaohk/discussion

Implementation:
- 
https://github.com/QubesOS/qubes-core-agent-linux/blob/a69acdabbfb60d88971644cfad50165091a66b9f/init/functions#L95-L101
- 
https://github.com/QubesOS/qubes-core-admin/blob/19e68bacf22cd965e819dfa4913740ecc14d1c40/core-modules/000QubesVm.py#L1152-L1158

Cheers,
Jean-Philippe

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

Re: [qubes-users] HDMI-related threats in Qubes OS

[Jean-Philippe Ouellet]

On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták

wrote:
>
> * DDC (PIN 15+16) – needed for getting the resolution etc., present even in 
> current version of VGA. While there is some attack surface, it seems to be 
> rather small.

Note that this is not strictly necessary for things to work though.

Having the display device report its supported resolutions lets local
config managers display a list of resolutions to choose from, but the
VGA controller is free to just try to output whatever resolution it
wants. The driver does not inform the display device of what
resolution it is using via some out-of-band protocol, this information
is trivially inferred by the number of pixel clocks between the front
& back porches of the vsync & hsync signals. In 2017 you can't really
damage devices by providing invalid signals (or I would have most
definitely broken some things in the process of developing my own VGA
controller), in practice the device usually just reports "signal out
of range" or equivalent.

Back-reporting via i2c is nice and convenient, but by no means
required for things to work. You can just try best resolution you
want, and if it doesn't work then keep trying others until it works.

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

Re: [qubes-users] DispVM Configuration

[Jean-Philippe Ouellet]

On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel  wrote:
> Hey all!
>
> So far so good with QubesOS on my end.  Have almost everything up and
> running to have this as my daily carry.  It's amazing how little RAM all
> these VMs actually require; and the CPU!  None!
>
> Anyways, I am having some trouble configuring my DispVMs to allow me to
> use them for printing and scanning.  The protocols and software for
> printing and scanning are both, as I recall, highly insecure.  In
> addition, the devices that use them (i.e. printer, scanners) should be
> considered to be backdoored or owned already.
>
> I wanted to make it so that when I want to print something, I open up
> the file in a DispVM and print it from there.  I then thought that I
> could approximately do the same thing with scanning.  Open up a DispVM
> that is running simple-scan, scan the file into the DispVM and then copy
> it over to the VM that I want.
>
> By doing it this way I should be able to move out all the vulnerable
> printer and scanner code, and my AppVMs will never directly touch those
> devices or protocols.  Instead they will be hidden behind the realtive
> safety of the Qubes file copy mechanism.

An interesting goal. In practice I'm not sure what real benefit you'd
get from using a DispVM vs. just a regular stateful AppVM (assuming
you just use one printer/scanner). Presumably what you care about in
this context is confidentiality of your documents. Your
printer/scanner is by its very nature in a perfect position to steal
your documents, and likely also has a means to store or transmit them.
This seems true regardless of whether or not your printer/scanner can
compromise or persistently compromise a VM (which only deals with
printer drivers and documents the printer will know anyway).

If you use multiple printers, then I can see an argument for wanting
separate AppVMs per printer, and if you constantly use different
printers then sure I guess DispVMs make sense. Is this the case?

In other words, I'm curious what threat you're actually trying to
mitigate by doing this.

> I tried to follow the documentation page:
> - show internal VMs
> - run gnome-terminal in fedora-23-dvm
> - install and configure the necessary applications and hardware devices
> - touch the /home/user/.qubes-dispvm-customized
> - shutdown the VM
> - regenerate the DispVM template using: qvm-create-default-dvm
>   --default-template
>
> When I opened up a DispVM the software was nowhere to be found (opened
> up Firefox, right clicked on the DispVM in the VM Manager and ran
> gnome-terminal).  When I reopen fedora-23-dvm the software is nowhere to
> be found.  So I believe either I am doing something stupid, or the
> documentation has it wrong.  I did notice that the DispVMs start with a
> ttemplate of fedora-23.  So then do they not actually use the
> fedora-23-dvm template like it says?

If you want to make additional software available, then do so in the
template of the dispvm (in your case fedora-23 (but you should really
update to fedora-24!)).

You can think of the process of customizing a DispVM like creating a
new AppVM. Software that should be available on every run belongs in
its template. Local state (/home, etc.) happens in the AppVM.
Customizing the DispVM template is like customizing an AppVM that you
then take a snapshot of and duplicate each time you want a new DispVM.
In practice this is similar to how it's actually implemented.

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

Re: [qubes-users] realized why I always lose sound in the vms

[Jean-Philippe Ouellet]

On Wed, Apr 5, 2017 at 11:29 PM, cooloutac  wrote:
> The sound mixer app I installed xfe in mutes things when I lower the volume 
> all the way by accident.  Never realized till now lol.  I always have to go 
> into dom0 alsamixer.
>
> Is there a better plugin to use?  Does a new iso come with one by default now?

This same exact bug keeps coming up again and again. See:
- https://github.com/QubesOS/qubes-issues/issues/2550
- https://github.com/QubesOS/qubes-issues/issues/2117
- https://github.com/QubesOS/qubes-issues/issues/2291
- https://github.com/QubesOS/qubes-issues/issues/2321
- https://groups.google.com/forum/#!msg/qubes-users/53TYf5GYkqY/ZU8i5v6JAwAJ

This was fixed a while ago, but people don't get the fix because of
the limitations of updating dom0 by only updating the packages
installed there. When things get fixed in the installer, they don't
trickle down to existing systems, and we don't publish new release
ISOs except for on major releases. This means the default install is
often broken, and many people end up needing to independently solve
the same problems over and over. This is clearly not ideal, and IMO
the way in which we manage dom0 needs some rethinking.

For this specific case I think we'd need a meta-package tracking which
packages are installed by the installer, and have the installer just
list that one and have deps of it be pulled in automatically. That
would let us update *which* packages are installed by default and have
that change affect existing installs. Then, as for actually putting
the new mixer in the panel, we'd probably need a %post section in a
relevant package or something.

IMO updating needs a better solution overall. I tried to start a
discussion about this here:
- https://groups.google.com/forum/#!topic/qubes-users/dCctVsf15dE/discussion
but it didn't go anywhere.

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

Re: [qubes-users] Qubes 4.0 Alpha release date

[Jean-Philippe Ouellet]

On Wed, Apr 5, 2017 at 7:50 AM,   wrote:
> Hello everyone,
>
>
> First, thanks a lot for working on a reasonably secure operating system
> and publish it for free.
>
> With the recent critical security issue in Xen PV, it would be nice to
> consider to release an alpha version of Qubes 4.0 (with HVM support).
>
> Do you consider to release soon an alpha version of Qubes 4.0 ?
> If no, building Qubes 4.0 with Qubes-builer is a solution for daily use ?

Note that there is already HVM support in 3.2. The implementation
details are likely to change in the future (referring to
PVH/HVMlite/whatever), but it's still there.

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

Re: [qubes-users] How much important is TPM?

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 6:21 PM, taii...@gmx.com  wrote:
> On 04/04/2017 12:36 PM, Steve Coleman wrote:
>
>> On 04/04/2017 10:29 AM, taii...@gmx.com wrote:
>>
>>> Opal is proprietary garbage,
>>
>>
>> Actually its an open standard, not controlled by any government or
>> corporation. One link I provided was to the standard which gets down to the
>> data structure byte memory layout and data interchange requirements.
>
> Open standards are arbitrary and they mean nothing, the actual
> implementation is what matters.
> How many drive firmwares are open source? (zero)

Counterexample: http://www.openssd-project.org/wiki/The_OpenSSD_Project

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

[qubes-users] Re: [qubes-devel] Re: QSB #29: Critical Xen bug in PV memory virtualization code (XSA-212)

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 11:35 AM, Hack  wrote:
>> Dear Qubes community,
>>
>> We have just published Qubes Security Bulletin (QSB) #29:
>> Critical Xen bug in PV memory virtualization code (XSA-212).
>>
>> [...]
>>
>> Discussion
>> ===
>>
>> This is another bug resulting from the overly-complex memory
>> virtualization required for PV in Xen. As we announced last year [5],
>> the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
>> switching to HVM-based virtualization:
>>
>> | One of the most important security improvements that we plan to
>> | introduce with the release of Qubes 4 is to ditch paravirtualization
>> | (PV) technology and replace it with hardware-enforced memory
>> | virtualization, which recent processors have made possible thanks to
>> | so-called Second Level Address Translation (SLAT), also known as EPT
>> | in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
>> | virtualization, which originally was capable of only CPU
>> | virtualization but not memory virtualization and hence required a
>> | complex Shadow Page Tables approach (which  we believed back then  was
>> | actually less attractive than the PV approach). We hope that embracing
>> | SLAT-based memory virtualization will allow us to prevent disastrous
>> | security bugs, such as the infamous XSA 148, publicly disclosed in
>> | October of last year, which  unlike many other major Xen bugs
>> | regrettably did affect Qubes OS. Consequently, we will be requiring
>> | SLAT support of all certified hardware for Qubes OS 4 and later.
>
>
> Does anybody know about Ryzen SLAT support?

See https://groups.google.com/d/topic/qubes-devel/LRKd_rK2lXc/discussion

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

Re: [qubes-users] How do I...?

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 8:56 AM, Samuel Hentschel  wrote:
> Hey Qubes Community,
>
> I'm a "new" QubesOS user; as in this is my first time trying it to
> make it my daily carry.  I have a couple questions that you guys may
> be able to help me with.

Hey Sam, welcome to the community! :)

> I have terrible vision and I just got a Lenovo Thinkpad X1 Carbon Gen3
> specifically for Qubes.  Its got WQHD and everything is *tiny*.  I
> have played with the DPI and with font sizes and can't seem to get it
> right.  What is the best way to get the font sizes larger in AppVMs?

First, I'd recommend decreasing your overall screen resolution in
dom0. If you don't want tiny text anyway, it's friendlier on battery
life to have less pixels rendered in AppVMs anyway since AppVM
contents are all rendered by the CPU (no GPU access in domU for
security reasons). In my experience this will also improve your
performance when watching videos as well.

Then, try:
gsettings set org.gnome.desktop.interface scaling-factor 2
in your VMs (or their template). Change 2 to whatever you find best.
Note that this setting does not affect all gui toolkits and will
result in inconsistent scaling (another reason to want to decrease
dom0 resolution first), but it's enough for many default programs
(Firefox, gnome-terminal, etc.).

I'd also like to point you to these issues/threads [1][2][3] where
HiDPI support has been discussed before. You may find some further
insights there.

[1]: https://github.com/QubesOS/qubes-issues/issues/1951
[2]: https://groups.google.com/d/topic/qubes-users/V5vZv6EmP2o/discussion
[3]: https://groups.google.com/d/topic/qubes-users/jM4OZCWPJqw/discussion

You may also find this thread about visually-impaired accessibility in
Qubes interesting [4].

[4]: https://groups.google.com/d/topic/qubes-devel/vs5ZEgoNIb4/discussion

> Also, I tried to open up a DispVM and nothing came up.  Qubes says
> that its tarting one up, but nothing ever shows up.  What am I doing
> wrong?

No idea. There are many possible reasons and you haven't given much
information to help us guess.

This may or may not help, but in case you're still using the EOL
fedora-23 templates (which the latest 3.2 installer still gives you by
default), then I'd recommend installing the fedora-24 template [5] and
switching your DispVM to it [6]. If your issue still persists I'm
happy to help diagnose further.

[5]: https://www.qubes-os.org/news/2016/11/15/fedora-24-template-available/
[6]: https://www.qubes-os.org/doc/dispvm-customization/

> Finally, how should I go about sending in an HCL?  I was going to try
> and put all the features of Qubes in (including AEM) and was
> interested in helping the community grow.

See https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports

> Thanks in advance for helping me; my other questions are more for the
> developers, so when I get around to it I'll either put in an issue or
> fix it myself.
>
> V/R
> Sam Hentschel

Welcome to the Qubes community!

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

Re: [qubes-users] Re: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)

[Jean-Philippe Ouellet]

New HCL attached.

No remaining complaints about this laptop (well... aside from being
too new for coreboot). It is entirely usable as a Qubes machine.

I get about 6 hours battery life with a workload that involves
starting many VMs frequently (lots of DispVM starting seems to be the
largest drain).

Hopefully one day High-DPI support in linux in general will improve
and I can take advantage of my whole screen. For now I'm running in
globally-reduced resolution (in dom0) due to inconsistent scaling
across apps and VMs. This means less pixels to software-render in VMs
anyway, which is nice for performance, power consumption, and screen
tearing.

I still have iwlmvm & iwlwifi in my sys-net's
/rw/config/suspend-module-blacklist. Haven't tested if it's still
necessary since the drivers are reloaded faster than I can type my
screen-unlock password anyway, so in practice I don't care :)

On Tue, Feb 28, 2017 at 1:29 AM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> On Mon, Feb 27, 2017 at 3:42 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>> On 02/27/2017 03:11 PM, Holger Levsen wrote:
>>> On Sun, Feb 26, 2017 at 02:56:53PM -0500, Jean-Philippe Ouellet wrote:
>>>> I still have issues with suspend/resume. Sometimes it fails to resume,
>>>> and sometimes it fails to suspend (leading to a hot backpack and/or
>>>> quickly dead battery).
>>>
>>> what are your exact symptoms? mine are: suspend works nicely, but no
>>> resume
>>> (no reaction at all in fact) once I press the keys to wake up my machine,
>>> which is a X260, also skylake, also 4.8.12 + xen 4.6.4.
>>>
>>> -> this doesnt happen always, but around 20% of the time or so. Pretty
>>> often.
>
> It often seems to suspend correctly (backlight turns off, fans turn
> off, power consumption minimal (does not get hot over time), and power
> button & top-cover LEDs start pulsing) but does not wake on any input
> (keyboard, touchpad, or pushing the power button). In order to recover
> from this state I must press and hold the power button for several
> (~3-5?) seconds. Interestingly, pressing the power button again
> appears to start the normal power-on sequence (keyboard flashes, power
> button led turns solid-on, etc.) but does not actually boot (IIRC
> hangs at black screen after lenovo logo splash or something), and I
> need to hold it an additional time (IIRC turning off after ~1 second)
> and turn it on again. It always boots fine this 2nd time. This happens
> about once a day.
>
> Very occasionally (~ once a week) it will fail to suspend. I close the
> laptop, and the backlight turns off and stops responding to input, but
> the power status LED on the outside of the lid stays solid red (does
> not begin pulsating), the fans stay on, and will get hot if put in a
> backpack.

Suspend/resume was fixed at some point by a BIOS update. Not one of
the ones where they mentioned sleep/suspend/resume in the release
notes though...

The latest BIOS hashes I observe are:
$ sha256sum n1*17*
4b5488be128d9c022cd4924476d48e38dd55c38809db0f3a6c06f1a2d2ad0217  n1fuj17w.exe
918c836905db7709433b4dc03eddcbb04ccb8773f31f5b22b5b92388b56a3002  n1fuj17w.txt
5e5f9cfec0dcb299a033be0b4006af8697045876c4ef18a34716b894c48b917b  n1fur17w.iso
1dcdf1ffd2cd30be225db49e8210de2dabba32c5aaf3179a89e3d8f0cca61f3a  n1fur17w.txt

Obtained from:
https://download.lenovo.com/pccbbs/mobiles/n1fu{r{01..17}w.{iso,txt},j{01..17}w.{exe,txt}}

Downloaded from multiple network positions over multiple days with
matching hashes.

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


Qubes-HCL-LENOVO-20FBCTO1WW-20170404-001900.yml
Description: application/yaml

Re: [qubes-users] Re: Testers wanted

[Jean-Philippe Ouellet]

On Sun, Apr 2, 2017 at 4:49 PM, Eva Star  wrote:
> On 04/02/2017 09:23 PM, John Casey wrote:
>> Apologies as I am not totally familiar with mailing list etiquette, but
>> would it be better to include the mailing list so as to maintain a record
>> of volunteers?
>
> Or full list of tasks that need to do on some page and when done by someone
> and reported to Unman then remove the task from the page.

You can just filter them:
https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.1+updates%22

Issues that get closed will disappear from that list automatically.

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

[qubes-users] Re: Custom qrexec services

[Jean-Philippe Ouellet]

On Sat, Jan 28, 2017 at 9:04 PM, Marek Marczykowski-Górecki
 wrote:
> 1. write USB - _unidirectional_ service to write an fs image into USB
> stick (service into USB VM)

I like this idea (mostly got tired of ... | qvm-run -p sys-usb 'dd
of=/dev/sda') and wrote my own. [1]

Not unidirectional, mine passes back the hashes of reading back what
it just wrote (more to detect failing media than for security). Also
allows the device name to be controlled with argument-specific policy.

[1]: https://gist.github.com/jpouellet/abe5cf438267afffc851a1a11d8be8f0

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

Re: [qubes-users] Security and dispVM firefox customization

[Jean-Philippe Ouellet]

If you are concerned about the size of your anonymity set then you
ought to be using unmodified TBB in a whonix-ws-based template rather
than Firefox in a DispVM.

We don't currently make guarantees about the cross-machine uniformity
of DispVM browsers. There are ways to fingerprint the default DispVM
browser without changing any browser-related settings, such as
observing which additional fonts have become available in your DispVM
template as dependencies of other things installed there, and almost
certainly other things I'm not thinking of right now. So... is this a
problem we even want to try to solve? I'm not sure. IMO concerned
individuals should just be pointed towards whonix.

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 6:21 PM, Shane Optima  wrote:
> Maybe if you (or someone) could write a Firefox extension to modify all 
> browser page titles to be a concatenation of the page title and a short token 
> of characters generated from a salted hash of the URL (so that I don't have 
> to deal with any more hyperbole out of people like M. Ouelette), I could 
> write the Dom0 bash bit. Or vice versa. Couldn't promise delivery on a tight 
> deadline, though.

If you're going to write an extension then there's no reason to use
window titles since you could communicate over another channel which
is not under full attacker control by default, and wouldn't have
negative UX side-effects of abusing window titles as a communication
mechanism.

Furthermore, it's not hyperbole. Here's a super simple (but likely
quite effective!) exploit which took me a about two minutes to write:

(function() {
  var attack_target = 'Sign in to GitHub · GitHub';
  var saved_title = '';
  var pw = document.querySelector('#password');
  pw.addEventListener('focus', function() {
  saved_title = document.title;
  if (Math.random() < 0.2)
document.title = attack_target;
  });
  pw.addEventListener('blur', function() {
document.title = saved_title;
  });
})();

What you are proposing is simply too dangerous and easy to exploit.
For most threat models, passwords would honestly be safer if saved in
the browser. For the safety of yourself and others, please don't
implement this using window titles as proposed.

Don't get me wrong, your fundamental concept is a good idea, but only
if the password manager authenticates the requesting site in a secure
way. Window titles are absolutely not the way to do that, not even for
an initial version.

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:
> xdotool also lets you inject keystrokes into windows.
>
> With a shortcut-key assignment this can be easily scripted by the user (you
> said this was for power users).

Automatically injecting the keystrokes removes the "just watch the
window title and don't paste if it changed" mitigation which Shane
claimed as sufficient to make this attack preventable rather than just
detectable.

Overall I think this concept is simply too dangerous because you are
ignoring the actual origin of the browser and authenticating based
entirely on fully attacker-controlled information. Sure, you could be
super careful, but you're still pointing the gun at your foot.

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Thu, Mar 30, 2017 at 5:31 AM, Chris Laprise  wrote:
> You don't even need to rely on the window title for the security aspect: The
> _QUBES_VMNAME window property will tell you. For example:
>
> $ CUR_WINDOW=`xdotool getwindowfocus`
> $ VMNAME=`xprop _QUBES_VMNAME -id $CUR_WINDOW | cut -d \= -f2 | tr -d '"'`

The issue I raise is not pasting into the wrong VM, I think that's
easy enough to avoid already.

The concern is pasting the wrong password into an expected site in the
expected VM because that site spoofed its window title (which is under
full javascript control) while dom0 observed it to choose which
password to deliver.

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

Re: [qubes-users] How much important is TPM?

[Jean-Philippe Ouellet]

On Tue, Mar 28, 2017 at 2:40 AM, Vít Šesták

wrote:
> AFAIU, TPM is useful mostly for AEM. But AEM requires Intel TXT (which is 
> missing even on some high-end CPUs). But TXT has various vulnerabilities. How 
> much real protection can it offer? Is it worth the hassle (finding a laptop 
> with both TPM and TXT and installing and using AEM)?
>
> To be honest, I don't know much about TPM/AEM/TXT.

Without directly answering your question (others in this community are
much better qualified to do that), I can offer the following:

See Joanna's "Intel x86 considered harmful" [1], particularly chapter
2 ("The BIOS and boot security").

Since publication of that paper we've seen increased availability of
Intel Boot Guard (moving the CRTM into the CPU rather than on mutable
flash potentially being executed before measurement) although whether
or not this really matters in practice remains unclear given the
typical long and complex chains of trust after that inherent to static
chains of trust to begin with.

Heads [2] is the best attempt I'm aware of to do something about the
"long chains of complex unauditable crap in your TCB for boot security
with a static root of trust" problem, and also did not exist at time
of publication of Joanna's paper.

[1]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[2]: https://github.com/osresearch/heads

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

Re: [qubes-users] Maybe a silly question

[Jean-Philippe Ouellet]

On Fri, Mar 24, 2017 at 10:51 AM, Manuel Cornejo
 wrote:
> Doesn't Qubes need and antivirus? What happend if on Qubes we set a VM with 
> Windows 7 in it? Would you install antivirus on the virtual machine hoping 
> that is going to be (the same /more) effective than the traditional not 
> virtualized scenario? How do you protect your Qubes machine from virus? Just 
> by putting down the VM and what about with bios rootkits and other malware?

IMO you are much better off using templates to ensure you don't use
compromised windows VMs to deal with data you care about than you
would be trying to use antivirus (a.k.a. "throwing all the untrusted
input at all the complex parsers, often with extremely weak
sandboxing").

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

Re: [qubes-users] Why does Qubes not work with nested virtualization?

[Jean-Philippe Ouellet]

It actually does work for limited use cases. I sometimes run Qubes
inside Qubes for quickly testing things ;) The outer VM must be HVM,
and the inner-inner VMs must be PVM, or else you must enable some
less-tested and potentially dangerous code paths in Xen (nestedhvm=1)
which Qubes (on purpose) does not enable by default.

The main issue is networking does not work because Qubes relies on
being able to pci-passthrough a network card to sys-net, and this
(emulating pci passthrough) is afaik not implemented by qemu.

I suspect this is not actually what you meant though, and perhaps you
are asking about running Qubes inside e.g. virtualbox or vmware on
windows or osx? Well, in that case many of the security guarantees of
qubes (device isolation, boot sequence semi-protection, etc.) can not
be made since the outer system has full control and is fully exposed.
Then there is also the problem the outer hypervisors not correctly
emulating or exposing the hardware-assisted virtualization cpu
features to their guests. (IIRC virtualbox still doesn't? Don't quote
me on that though... I haven't tried it myself.)

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

- If we consider a compromised VM with:
  - passwords saved in the browser: an attacker can obtain all passwords
  - your proposed password manager: an attacker can still obtain all
passwords, just needs to wait for them to be used

- If we consider a non-compromised VM with:
  - passwords saved in a browser: an attacker can not obtain passwords
  - your proposed password manager: an attacker can obtain passwords
by changing window titles during authentication (which may or may not
be *detected* by a sharply observant user, but could still not be
*prevented* by one)

Therefore, your proposed solution is actually appears worse from a
security perspective (aiming to guarantee password confidentiality)
than just saving passwords in your browser!

Your argument appears to reduce to "This may be theoretically
exploitable, but the ease of implementation and additional convenience
is more important to me", which assumes your adversary is not
sufficiently {resourced, motivated, creative} to exploit that
theoretical weakness against you. For many users this assumption and
associated trade-off may be fine... however they are quite strongly
rejected in the arguments motivating the design of Qubes.

The key difference between this and the passwordless sudo argument you
bring up is that the qubes security model explicitly assumes that
user->root privilege escalation within a VM is possible, and designs
around that fact. Meaning, assuming the security assumptions of Qubes
[1] hold, passwordless sudo is *not* a theoretical weakness [2].

[1] which have nothing to do with assuming weak/unmotivated adversaries
[2] unless Xen vulns affecting Qubes are somehow more exploitable from
kernel vs. userspace within a VM *and* the adversary does not also
have a linux privesc exploit (which history has shown to be quite
unlikely)

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

Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?

[Jean-Philippe Ouellet]

On Fri, Mar 24, 2017 at 2:55 AM, Shane Optima  wrote:
> However, I justed noticed that R3.2 introduced a Dom0-to-hyperboard[1] copy 
> function, and since Dom0 knows the window title text... couldn't there be 
> another hypervisor keyboard shortcut that would use the window title to 
> search though a simple database, copy a string associated with that window 
> title and send it to that VM's clipboard?
>
> And because browser window titles are changed by websites, that means you 
> could in most cases store one password per website.  As always, it would be 
> the user's responsibility to not input the password into a spoofed website. 
> (This tool would thus be more of a convenience for power users, not the 
> robust and idiotproof edition.)

This is actually worse than not using a password manager at all,
because the window you are about to enter the password into has full
control over its title, and so this opens a race condition where the
site could change its title right before dom0 checks it (perhaps
triggered by "I am displaying a login form, and I just lost focus") to
turn the dom0 pw mgr into a confused deputy [1] which would be happy
to deliver the password for site A to the malicious site B which is
temporarily spoofing site A's expected title.

[1]: https://en.wikipedia.org/wiki/Confused_deputy_problem

> Obviously, the holy grail of password management should involve not storing 
> passwords (encrypted or otherwise) on any online VM until they instant they 
> are needed.

Not quite. The holy grail would be never having the VM see the
passwords *ever*, and this is in theory actually achievable.

You could do your browsing in VM A, which has a browser extension
which securely determines the origin of the login form currently being
displayed, forwards a very simple "i am trying to login to site A" to
a different VM B. VM B has the list of credentials, and if we have one
for the site in question, performs a login. Then, only the session
cookies are forwarded back to vm A and injected back into A's browser
via the browser extension.

In this manner, a VM can obtain a valid login session for a given
site, without the ability to ever determine that password for that
site. This is better than using a password manager, because with a
password manager the vm still sees the password, and a compromised VM
need only wait until you login and then observe your password.

Of course, a compromised VM could also send your login session
cookies, etc. to an attacker who would then have a valid way to have
access to your account, but many sites require that you re-enter your
password before changing it so at least the attacker could not steal
the account by changing its password. Additionally, when you are done
using the site, the login-token-generating VM could automate a logout
of the site, invalidating the session tokens held by the requesting
VM.

The problem with your method (confused deputy password manager) is
avoided by having a browser extension validate the origin of the site
actually being displayed and ensure the login session token is only
injected into the correct corresponding site's context, rather than
relying on entirely attacker-controlled information for authorization.

See also: https://github.com/rustybird/qubes-split-browser

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

Re: [qubes-devel] Re: [qubes-users] usability major bug?

[Jean-Philippe Ouellet]

On Wed, Mar 22, 2017 at 8:08 AM, Oleg Artemiev  wrote:
> On Wed, Mar 22, 2017 at 1:52 PM, Holger Levsen  wrote:
>> Hi Oleg,
>>
>> you missed on important bit of information:
>>
>> On Wed, Mar 22, 2017 at 12:12:58PM +0300, Oleg Artemiev wrote:
>>> I have to reboot Qubes R3.2 a few times a day. What do I do wrong?
>>
>> why do you have to reboot?
> Cost of reboot in __understanding__ what the hell is the reason is
> less than cost of restoring correct state after reboot.

No, we understand the cost of rebooting, but you have not stated why
you do reboot.

What specific symptom(s) do you observe before rebooting which causes
you to feel the need to reboot?

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

Re: [qubes-users] Tip: How to speed up QubesOS shutdown

[Jean-Philippe Ouellet]

On Tue, Mar 14, 2017 at 7:11 PM, haaber  wrote:
> I dont't have any e820 pci device as far as I know, but shutdown is
> definitely a problem. xfce shuts down, and then I have a black screen
> with a blinking cursor, and, afaik unless I brutally remove electricity.
> No clue if this is related to Grzesiek's problem ... Bernhard

e820 does not refer to a device, but rather a table containing memory
layout information provided by the bios [1].

[1]: 
http://wiki.osdev.org/Detecting_Memory_(x86)#BIOS_Function:_INT_0x15.2C_EAX_.3D_0xE820

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