[qubes-users] Qubes workstation / gaming desktop thread (November 2017)
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] USB Keyboard thoughts...
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.
Re: [qubes-users] Hibernate Lenovo X1
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] Where is ability to backup and restore backups on 4?
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] Where is ability to backup and restore backups on 4?
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?
On Thu, Dec 7, 2017 at 12:22 PM, 'Tom Zander' via qubes-users 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] Boot QUBES with kexec
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] Xfce launcher loses dom0 entries
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] Moving dom0 screenshots immediately to VMs
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] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
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 virtualization. (Qubes 4 is quite better there, but still
> not perfect.) It mi
Re: [qubes-users] Moving dom0 screenshots immediately to VMs
On Sat, Jan 20, 2018 at 4:51 AM, Alex Dubois wrote: > On Saturday, 20 January 2018 06:21:36 UTC, Jean-Philippe Ouellet wrote: >> 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 > > 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] How to get to command line for dom0?
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] Problem with Qubes4 rc4 -- "GLX is not supported."
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] Re: VM chaining visualisation tool
See this thread: https://groups.google.com/forum/#!topic/qubes-devel/64-WJIMY18A Implementation linked in last post: https://gist.github.com/Zrubi/6229d5400bde987b1aa8da516553b909 Render result w/ graphviz. -- 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_CviSygtoe9zG%2BQ%2BbXxetsuaTeBAjNW05bAN3SZsWZ6bQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes extraordinary flexibility
I absolutely agree! I routinely run various engineering tools which are typically "distributed" (to put it generously) as massive "untar this and run some script as root -- up to you to resolve dependency hell", and qubes makes this amazingly clean. I used to have such hesitation at installing such software and resort to horrible LXC hacks to try to keep some weak semblance of self-containedness and safety. Qubes is *so* much better, and since 3.2 with USB passthrough (and a couple local wrappers and patches I should really get around to upstreaming) even software which interfaces with external hardware tools are so very nice. Oh, you need to load some quite likely vulnerable kernel driver for this crappy oscilloscope? Sure! Go right ahead! Qubes is not only a security win, but IMHO genuinely a usability win too. -- 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_CP399KFmwa9DynvrLTN2C4GaE8XXWz%3D5nmd14p%3D0YmMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Custom qrexec services
>From https://github.com/QubesOS/qubes-issues/issues/910#issuecomment-275872140 (here to not pollute that issue) @marmarek wrote: > BTW I'm curious how many people have custom qrexec services ;) On one of my > machines I have 15 of them. I have at least the following (not all are finished or enabled): 1. requesting port forwarding (with separate policies for different arguments to denote different ports) 2. requesting USB device passthrough (arg to specify device) 3. requesting VM be created from particular template with particular RPM installed (to test in clean envs) 4. requesting ssh session from VM with no netvm (mitigates http://nastytrap.ru:25 issue described by @rootkovska in https://groups.google.com/d/topic/qubes-devel/niMbDhS_nWI/discussion) 5. render html (like qubes.PdfConvert, and allowed from any) 6. excel-to-csv 7. create hvm w/ particular iso, particular xen cfg, & point stdin/stdout at console device (from trusted dev vm, for WIP OpenBSD-in-qubes work) 8. WIP qubes.Filecopy equivalent which does not require the VM to be running (encrypts the file with a key only known to the dest VM & stores in staging area for dest VM to retrieve later). Goal is to safely allow transferring data to VMs with encrypted private.img while in a physical location where you do not want to type that VM's passphrase. 9. giving me a serial console without passing through the whole FTDI device at USB level (for safety, but also works around some issues when reattaching) 10. killing jtagd & reloading a driver, because dumbly broken tools are dumbly broken 11. queuing stuff to print 12. start ssh session via sshd -i (inetd mode) (used because i can multiplex multiple things (shells, scp, etc.) over a single ssh session, which is convenient in the case of '$dispvm' targets (because you don't know the name of the just-started VM to specify multiple RPC calls to it), so in some cases it's less hacky than trying to automate lots of things over a single qubes.VMShell to a dispvm) and several more -- 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_DoFOLqcL%2BbDg8N9%2B3PU5gBzWp0NKmBBFHpV9iinj%3Df_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HCL Suggestions?
I started an effort to automate HCL updating a few months ago and thought I'd pass on my notes in case anyone finds them useful. First, you'll probably want a complete and incrementally-updateable local mailing list archive. The most reliable way I've found to dump google groups is with [1] (amusingly implemented in bash). To decode the mails to extract the HCL files, I tried to use ripmime [2], but hit cases in our archives that crashed it [3]. I got sidetracked trying to produce a minimal case reproducing the crash and determine if it was exploitable, but other priorities took over. The crashing cases in our archives included the following (which are not HCLs): - https://groups.google.com/forum/#!msg/qubes-users/8n9i1GiIl7s/jvIkXCiV0awJ - https://groups.google.com/forum/#!msg/qubes-users/h_5wX9IN-MI/XRlekv-GcU4J - https://groups.google.com/forum/#!msg/qubes-users/jr8BWxhmQq4/KteMXP5nxd8J - https://groups.google.com/forum/#!msg/qubes-users/v739hab0FDo/Yru2TDVAEX8J Reported upstream, but maybe you want to use a different mime-decoder regardless. [1]: https://github.com/icy/google-group-crawler [2]: http://www.pldaniels.com/ripmime/ [3]: https://gist.githubusercontent.com/anonymous/239a136df2479d36f085e075ddc52287/raw/d6a2fb64ce9e64a8fa1de2962f8bc447e395d14e/ripmime-crash.txt -- 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_D7EC-NsYB3j7iV4cYGJp7ZKJ4ewWb%3DbJLbnrd4L%2BxS2A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] traveling - best practice
> 2) maybe it woud be nice to have an additional "single cube" > usr/password : when using this user name, one would get a single > disposable untrusted VM, no dom0 acces, no USB, and so forth. Is that > feasable / reasonable? I want something similar to this too, but there are several things which need to be implemented first in order for it to be able to be implemented securely, particularly splitting out the desktop environment / window manager / main gui out from dom0. https://github.com/QubesOS/qubes-issues/issues/833 Progress is being made, albeit rather slowly. More funding would accelerate this 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_DUoWfv-Bs%3DWthuX4ns8QncxAHA3eoJopb5DRhL%3DbB-6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Question to Mirage OS firewall users
On Sat, Jan 28, 2017 at 9:13 AM, Thomas Leonard wrote: > I'm not sure why my DispVM is Fedora 23 when my default template is Fedora > 24, but anyway... If fedora24 is indeed your default template, try: [user@dom0 ~]$ qvm-create-default-dvm --default-template If that does not work it may be a bug worth reporting. As a workaround, try: [user@dom0 ~]$ qvm-create-default-dvm See https://www.qubes-os.org/doc/dispvm-customization -- 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_CkYf2ROXbYza%2BMb8eRTCAGvtafw2xTyXKyXeCMfFsfLg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] What? Can I access a windows USB drive?
If you install fuse-exfat (from the rpmfusion-free repo) in the template used by sys-usb, then Nautilus (the default file manager) should be able to auto-mount them and they should Just Work(TM). At least... this worked for me. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_Dd58vnRwrRXvAcCKWLWc4SW2vfMO5y3%2BnrzU0d708EgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Convert live system to VM in Qube OS?
On Sat, Feb 4, 2017 at 7:31 AM, Alex wrote: > First, you may already have thought about it, but the simple > transposition of a work pc to a VM environment (be it qubes or not) does > not give you any additional security benefit. It only increases the > compatibility problems! On the other hand, it allows one to start using qubes without suddenly breaking your entire workflow, and allows one to gradually adopt the Qubes model while still being able to get your work done. The realistic alternative is likely not trying Qubes and continuing to use your old system indefinitely because the perceived migration burden is too great. > If you want to > benefit from fake persistence of system files, you will need to try to > move as much software as possible in either the template (installing > with dnf) or in /usr/local/bin (if manually-compiled or direct binary > package). /usr/local/bin is not "fake-persisted", it is persisted. All of /usr/local is a symlink to /rw/usrlocal, which is persisted. > For your actual question, there's no tool to assist in "converting" a > live system to a Qubes VM: since there would be so little benefit > there's no actual reason to make such a tool. I disagree. I think a migration tool could be quite helpful, and I am often asked if one exists while promoting Qubes to friends. Unfortunately there are (and will likely always be) higher priority things to implement. -- 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_DnNq33w%2BShrHc%2BeMmzx1pOW5MEj8cm4Q-Yw5O-8V4-FQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Updating packages with salt does not refresh the repositories
On Thu, Feb 9, 2017 at 6:46 PM, wrote: > I have an update.sls with the following content: > > updates: > pkg.uptodate: > - refres: True If that's literally a copy & paste... because you're missing the h in refresh? -- 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_CSgacYoF2EyZJcNvOEDdG5f7FLYn6N9%2B2voxvEK651bA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Amnesic QubesOS
On Tue, Feb 14, 2017 at 9:45 PM, wrote: > There is the option to use a disposable vm for everything if you want? Note that the current implementation of DispVMs does not resist local forensics: - https://www.qubes-os.org/doc/dispvm/#disposable-vms-and-local-forensics - https://github.com/QubesOS/qubes-issues/issues/904 - https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/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_BDZkVfjASbhqQiZy-TDEdc9FZBMek0vDrPZ5JLMXHJpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-run fails silently with chromium
Running execsnoop [1] in the AppVM while trying to start chromium may give you more insight into what is actually happening. Tracing observed behavior is often easier than digging through the source. [1]: https://raw.githubusercontent.com/brendangregg/perf-tools/master/execsnoop -- 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_BOi_S0wfWAXbRabyJcf-zPROgLCthTXQAAK00QH48qqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Global updates question
On Thu, Feb 16, 2017 at 10:51 PM, Fabrizio Romano Genovese wrote: > Well, I have considered it, yes, and it's true that launching many terminals > can be resource intensive. But it's also faster: Using & I can launch all > the terminals at the same time, while cycling as in the script you linked I > should wait for the previous update process to finish. Not if you just background the process, like: for dom in templateA templateB ...; do qvm-run -p -u root some-template 'dnf update' & done Anyway... the code you're looking for is here: https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.InstallUpdatesGUI -- 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_DeDSNuuqvNN4NgAmLM21SnpPgmSR%3DccB03z--8R%2Bs1jQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes manager not showing changes, etc.
Not sure if relevant, but I also experienced a case recently where a just-created VM did not show up. Was resolved by simply killing & restarting qubes-manager. Only happened once, so didn't debug. -- 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_Bmav6XAoXKRMjjymYgCnW4oRbacGeCVUT%3DwB%2B69UH%3DRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)
In the interest of maximizing list archive utility, I'm attaching a new HCL here (bumped kernel to 4.8.12-12 & xen to 4.6.4). 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). There is now another HCL of the same laptop here [1] which claims that kernel 4.8.12-12 fixes the suspend-resume issues, but this has not been the case for me. [1]: https://groups.google.com/forum/#!msg/qubes-users/kLlBahlTRK0/rInkUwa0FAAJ -- 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_B1GWHzfoO%3DN7_z1WRhnC-ph89TpyORBeaLjYYFVqg%3D3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-LENOVO-20FBCTO1WW-20170226-144830.yml Description: application/yaml
Re: [qubes-users] Re: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)
On Mon, Feb 27, 2017 at 3:42 PM, Chris Laprise 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. >> I think we should file an issue in the "real" tracker… (or is there one >> already? I think I tried searching for one, but didnt fine any…) Not sure where you mean. kernel.org? xenproject.org? qubes-issues? >> I'd also be glad to try a 4.9 or 4.10 based kernel… Yeah... I've been meaning to get around to building one, but... free time :( Same for investigating xen 4.8. > Do either of you use anti-evil-maid? That, with recent versions of Xen, > seems to be one of the triggers for this behavior. I boot this machine via EFI. I am not aware of ever having gotten legacy booting to work on this hardware (which is required for AEM [1]). [1]: https://github.com/QubesOS/qubes-antievilmaid/commit/4264f113b85085d20e4d8cacc5d2a0ae196af1ed -- 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_Au0YFc%3DR6OVpnAJiX_e9LTpGoPGWhSZYQ_P1FSathmRQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Upgrading from Qubes 3 to 4.
On Mon, Mar 6, 2017 at 1:02 AM, wrote: > Hello, > > I'm looking at getting a new laptop in the next few months. I will, of > course, run Qubes on this thing but since Qubes 4 is on the horizon I'm > wondering how easy/difficult it will be to upgrade once it's out. Has > anything been said about this? > > Since I don't really need my new computer until June, I'm considering holding > off and wait for Qubes 4 to come out. Has anything been said about the > release date? Googling doesn't reveal much in the way of recent information. > > Regards, > Elias https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/ Note that those are bare minimum requirements, and that you will probably want more. If you need to run windows HVMs, I'd say at least double those recommendations. I'm probably something of a power user, but used to run out of memory regularly with 8gb and am about to run out of disk with 500gb. I think perhaps we should consider adding a "recommended requirements" section instead of just "minimum requirements". -- 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_CiPp%3DeO8n%3DZNTR0PKCP%2BYU3VRoLeXee%3D9QB-UyopD_uA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: SystemD sucks - qubes shouldn't use it
On Fri, Mar 10, 2017 at 1:14 AM, Drew White wrote: > I wrote my own applications for qubes because the developers wouldn't fix > things and didn't change things to use less RAM. > I wrote my own manager that uses only 200 MB VRAM, instead of the current one > that uses over 1 GB VRAM. (Approximations) Feel free to share ;) -- 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_BaG47E%3DW_pMucBiPux--f-rACY8C-FSX3-N6O-XhsELg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Dealing with ssh
I have a dedicated minimal template used only for SSHing into remote machines. Basically fedora-24-minimal template clone with only openssh-client installed, and separate AppVMs based on that for different groups of servers I log into from there with respective SSH keys in each. This way if one machine compromised my template via e.g. arcane terminal escapes or something, it shouldn't gain lateral access to other machines belonging to different organizations that I also have access to. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_CM4q%3DoUG74HbLedNGPo4L5rFUxe4sp35FZ7WSbbW2wTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP Global alteration.
On Sun, Mar 12, 2017 at 9:19 PM, Drew White wrote: > Hi folks, Hi, > I want to set the NTP protocol to target the parent VM and on the NetVM or > Sys-Firewall have that as the NTP server that feeds everything under it. No, you don't want that. > Thus only one VM calls the external source at a lesser interval to do the > requests. That is already how it works. > How, in this system, do I perform this to get that to work please? Well, one would start by reading and understanding the relevant source: https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock > The "ClockVM" does not seem to be operating the way I would have thought a > "ClockVM" would. Only the ClockVM to uses NTP at all, and it sends the time back to dom0. The rest of the VMs get their time set by dom0 via qubes.SetDateTime service. There are many reasons for this, including eliminating redundant network traffic, and the fact that it is desirable for time to be correct in all VMs (including those intentionally without any network access). > Is there a bug in it? Lets see... https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm doesn't look like it! > Sincerely, > Drew. Sincerely, 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_Cv3QtRY9fXTp6nLZi5WdX7rc4BdvzmOaip-TmZyO6yTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Non UEFI
On Sun, Mar 12, 2017 at 9:03 PM, Drew White wrote:
> ... [snip] ...
> well, if you look at the Fedora Template, it has EFI on it.
> I want to know if there are templates out there that don't have EFI or uEFI
> on it. Because it's not needed or anything.
If you read the documentation about how VMs boot, you would realize
that no, they don't use UEFI. Things are booted via either pvgrub or
qemu's bios emulation. No (U)EFI involved anywhere at all.
If perhaps you looked in your template's /boot and saw /boot/efi and
were alarmed, well... don't be. They are only pulled in by these
packages:
[root@fedora-24 ~]# find /boot/efi -type f -exec rpm -qf {} ';' | sort -u
fwupdate-efi-8-2.fc24.x86_64
shim-0.8-9.x86_64
And to answer your original question of if there are any templates
without those packages: yes, fedora-24-minimal does not have them.
However, this *really* does not matter.
On Thu, Mar 9, 2017 at 11:47 PM, cooloutac wrote:
> what?
+1
--
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%3DpELKV4rtZDQt28P3re%2BppwUwoTHP6zg-f8Rm0TjOHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] very frequent crashes (about every other hour)
No guarantees about this fixing your specific problem, but you might want to try a newer kernel. https://www.qubes-os.org/doc/software-update-dom0/#how-is-software-updated-securely-in-dom0 See section "Testing repositories" -- 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_AW6bXLSArv_HRW%2BdRmmUaWQorjobXrOWpS5nwXXdUp6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USG - AFirewall For USB's
On Sun, Mar 12, 2017 at 3:06 AM, wrote: > This guy claims to have created a firewall for untrusted USB's > https://github.com/robertfisk/USG/wiki . > Anyone tested this? Previously discussed here: https://groups.google.com/d/msg/qubes-users/MEzOZ_naupo/lMjdMDwFAwAJ https://groups.google.com/d/topic/qubes-users/UHiDauas4rM/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_AdapMfWV97TNsn70mwfBeKHHYDaCgdzD-X5atwaxm74A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 3.2 on Macbook Pro Retina 11,5 [SOLVED]. Maybe useful for other Macbook models
On Sun, Mar 12, 2017 at 7:25 PM, wrote: > On Thursday, March 2, 2017 at 8:59:00 PM UTC, Marco Pozzato wrote: >> Hi >> >> I am using Qubes 3.2 since a couple of months on a daily basis on Intel NUC >> NUC6i5SYK and it is amazing. >> >> I would like to use it also on one of my MacBooks: >> * MacBook Pro 15" early-2011 8,2: my first attempt and I was not even able >> to start the installer. At that time I did not have enough knowledge and >> abandoned. Maybe, in the forthcoming weeks, I will retry >> * MacBook Pro 15" mid-2015 11,5: I have been able to install Qubes booting >> with rEFInd, despite a lot of issues. >> >> The two main issues I faced are: >> * no boot, due to empty xen.cfg file >> * system freeze, due to Broadcom BCM43602 wifi adapter. >> >> I spent many hours and nights googling, experimenting, reading git tickets >> and messages in the ML. None provided the final guide, but many little >> pieces that I am assembling in the Macbook troubleshooting document. >> >> I came up with a running system, that still need more work. For the time >> being I have a working setup and I hope to be helpful to other macbook users. >> >> Dear Qubes developers: please, review my guide and maybe let's open some >> specific mail/ticket to discuss and troubleshoot specific issues. I am more >> than willing to help. >> >> Thanks >> Marco > > Hi Marco, > > I've been trying to get Qubes R3.2 running on my MacBookPro11,1 without any > luck (I posted here for help a few weeks ago). I was wondering whether I > could read your guide? > > Take care, > Chris It has been merged into the main documentation available on qubes-os.org You can view the specific changes he's referring to here: https://github.com/QubesOS/qubes-doc/pull/295/files -- 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_Cd%3DFUa8e8VNuPUQwagYb%2BdauSntrOYMz6Afx2iBpvqyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Qubes Canary #11
On Wed, Mar 8, 2017 at 4:10 PM, Andrew David Wong wrote: > ---===[ Qubes Canary #11 ]===--- > > Special announcements > - -- > > None. Previously the "Special announcements" section contained: > * 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. Granted, "Special announcements" contents have come and gone in previous canaries, but this particular statement (or equivalent with slightly different wording) has been present in every one since canary 002. Should we be interested in why this section has been removed? I will interpret the a lack of a properly-signed quickly-delivered official answer as "Yes, we should be interested" and attempt to investigate further. -- 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_CTMineqDdpScBkcbrfnWVq7aPrAO1Ax3QtvqaUkXOTsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP Global alteration.
On Sun, Mar 12, 2017 at 10:24 PM, Drew White wrote: > On Monday, 13 March 2017 12:36:55 UTC+11, Jean-Philippe Ouellet wrote: >> On Sun, Mar 12, 2017 at 9:19 PM, Drew White wrote: >> > I want to set the NTP protocol to target the parent VM and on the NetVM or >> > Sys-Firewall have that as the NTP server that feeds everything under it. >> >> No, you don't want that. > > Why don't I want what I want? For the reasons I already stated, and that you appear to already understand. Only the ClockVM is intended to generate any NTP traffic which leaves your machine. The rest of the VMs are synchronized not via NTP, but via a qrexec service. This works even when the VMs are not networked, whereas NTP to a proxy NTP server in sys-net (or somewhere) would not. >> > Thus only one VM calls the external source at a lesser interval to do the >> > requests. >> >> That is already how it works. > > Then why does EVERY GUEST call pool.ntp.org? (unless I change it in the > template for every VM) That is not the behavior I observe on my system, confirmed by lack of output from: [user@sys-firewall ~]$ sudo tcpdump -ni eth0 'udp port ntp' Have you changed every guest on your system to do that or something? >> > How, in this system, do I perform this to get that to work please? >> >> Well, one would start by reading and understanding the relevant source: >> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock > > I read all that, that's why I found out how to change it in the first place, > but every time I do something like add a NewGuest and install, with it's > defaults to pool.ntp.org, it goes off and gets the NTP from an outside > source. (not very secure), so I have to keep changing it to be the local > server. I want to capture it all so only the NetVM performs that action. I get the impression that maybe you are just changing config files of services which are not running? >> > The "ClockVM" does not seem to be operating the way I would have thought a >> > "ClockVM" would. >> >> Only the ClockVM to uses NTP at all, and it sends the time back to >> dom0. The rest of the VMs get their time set by dom0 via >> qubes.SetDateTime service. > > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a good > addition to allow it to update each Guest. No. That would be a bad design for several reasons. Dom0 already does this periodically. This is better than what I assume you suggest (ClockVM directly invoking qubes.setDateTime in each guest) because the service invocations are implicitly rate-limited and contents filtered by dom0. It is also not desired for the ClockVM VM to even know which other VMs exist, let alone know which ones are running and need their clock set. >> There are many reasons for this, including eliminating redundant >> network traffic, and the fact that it is desirable for time to be >> correct in all VMs (including those intentionally without any network >> access). > > redundant network traffic... so every 10 minute PER GUEST, it contacts > pool.ntp.org and gets the time. That isn't redundant network traffic. Again. I do not observe this. Have you verified with an unmodified template? >> > Is there a bug in it? >> >> Lets see... >> >> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp >> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm >> >> doesn't look like it! > > Well, none that have been reported by anyone other than myself when asking > questions in the first place about it. But none opened a bug about it because > it's "not a bug" even though it is, (in my personal opinion) a very big bug > to have EVERY GUEST contact pool.ntp.org every 10 minutes. wether it's a > guest that's behind a proxy, or the proxy itself, or the net vm. Things do not work as you claim they do. > This is a security concern, and a big one at that. Nope. > for all unix types, the clock VM should contact the NTP server once every 6 > hours (or on boot and then every 6 hours), and every guest should be updated > by that guest for time, unless set to otherwise update from elsewhere. Where do you get this 6 hours figure from? Neither the RFC [1] or the pool recommendations [2] suggest this. [1]: https://tools.ietf.org/html/rfc1305 [2]: http://www.pool.ntp.org/tos.html > I have my own NTP server, and yet I i
Re: [qubes-users] Re: Non UEFI
On Sun, Mar 12, 2017 at 10:14 PM, Drew White wrote: > If only the minimal template doesn't have it, then that's not very good, > because the minimal template won't even update for me, I don't know if it's > something I've done or not, but it can't perform any dnf or yum actions for > some reason. Can confirm that it does work. Double check its firewall settings or try reinstalling it: https://www.qubes-os.org/doc/reinstall-template/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_Ar%2BWsmti78f4mNXznRtfd5xfRa9NAt%2BMHbnqSK8_d0bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP Global alteration.
On Sun, Mar 12, 2017 at 10:59 PM, Drew White wrote: > Question: Why does it not work properly then? Answer: Must be because of something you changed on your system. It *does* appear to work properly by default, confirmed by not seeing the NTP traffic you describe on two Qubes machines, one of which is literally a perfectly unmodified default install of 3.2 I have just for testing things. > Thus, it kept running /usr/sbin/ntpdate pool.ntp.org > > Until I changed that, it was futile. Feel free to send patches to allow users to easily specify an ntp server(s). >> >> > The "ClockVM" does not seem to be operating the way I would have >> >> > thought a "ClockVM" would. >> >> >> >> Only the ClockVM to uses NTP at all, and it sends the time back to >> >> dom0. The rest of the VMs get their time set by dom0 via >> >> qubes.SetDateTime service. >> > >> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a >> > good addition to allow it to update each Guest. >> >> No. That would be a bad design for several reasons. Dom0 already does >> this periodically. This is better than what I assume you suggest >> (ClockVM directly invoking qubes.setDateTime in each guest) because >> the service invocations are implicitly rate-limited and contents >> filtered by dom0. It is also not desired for the ClockVM VM to even >> know which other VMs exist, let alone know which ones are running and >> need their clock set. > > I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the time, > then Dom0 updates everything, it would all be via Dom0, but the CVM gets the > time initially, and if it has a difference in the NTP compared to the time > set in the CVM it then proceeds to update each guests time without calling an > external NTP server, and keeps it all inside the Guest regime. Exactly. >From my quick reading of the source and observations of my systems, that appears to be exactly how it is implemented right now. Note also that this is not what you initially described in your first email. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_Ar6OEp2_Ar0fxW265mjVBEYmdM5_hC%2B5u7hH%2Bt3bXRww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] disp-vms were great - if they worked.
On Sun, Mar 12, 2017 at 6:47 PM, haaber wrote: > [me@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell ... > libvirt.libvirtError: operation failed: domain 'debian-8-dvm' already exists > with uuid 603478e2-2d9f-4b27-c052-2910eaf6819b8 See if you already have a `debian-8-dvm` vm running (just with no windows visible). You can enable "View->Show/Hide Internal VMs" (internal, not just inactive) in qubes-manager to see it if so. (or use qvm-ls & qvm-shutdown) -- 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_C1i%2BgZe70MPG7BQO-Ew2NbzxMDZ9ZUmr9i%2Bk1Q8S2OZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP Global alteration.
On Mon, Mar 13, 2017 at 12:54 AM, Drew White wrote: > On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet wrote: >> From my quick reading of the source and observations of my systems, >> that appears to be exactly how it is implemented right now. > > In other words, the way it is right now is in a form in which it is yet to be > complete because they have not instantiated the way that it's meant to work? No, in other words nothing needs to be done (except perhaps reverting your system to how it was before) because a default system already behaves in the correct manner. >> Note also that this is not what you initially described in your first email. > > It is not what I initially described because I was making an enquiry not > providing details on what I had to do to change it per guest and not on a > global level in such a way to reduce the impact on the system and the NTP > server and DNS server. > > I posted on the forums, not sent an email, but I understand that you may > think so because it's a forum that has a mailing list on it available. /me stops feeding the troll now -- 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-4%3DL2sEPmA0-Z2C7OBYfsCDKUEtTcp6FS6oZeM5DyeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best practice maintenance of untrusted netvm
On Mon, Mar 13, 2017 at 2:29 AM, InfusingPrivacy wrote: > Hi, > > I've decided to gives Qubes a try. Apologies if I sound confused; there are > many options and settings in Qubes and as a first-time user, I want to make > sure I set Qubes up correctly. I have the following concern about the default > netvm. > > If the netvm is untrusted by default, I am making the assumption that the vm > is, "out-of-the-box" easier to compromise than the other vms. So I was > wondering what is the best practice for long term maintenance of the default > netvm, immediately after a fresh install of Qubes? > > 1. Attempt to harden netvm before connecting to the internet (disable remote > access, setup iptable rules, etc), then make a backup? There is no remote-access stuff enabled by default (no ssh, etc.), and the default iptables INPUT and FORWARD chains end in DROP (no incoming traffic is allowed by default). > 2. Do not harden; only backup netvm before connecting to internet. If I > suspect that netvm is compromised in the future, simply stop netvm & restore > from backup. You may. You can also delete the VM and re-create it (set NetVM of sys-firewall to none, delete sys-net, re-create based on whatever template, assign network pci devs to it, restore netvm of sys-firewall, and might need to restore ClockVM to new sys-net in global prefs too (not sure)). > 3. Some other best practice I did not think of. Yes, just don't worry too much about it ;) It is considered untrusted precisely because you do not need to trust it very much as long as you follow good practice with the VMs behind it (generally assuming your traffic may be actively man-in-the-middled regardless of where you are - by your ISP, the kid in the coffee shop, or the attacker in sys-net). > (If choice #1 or 2 is best, I have a followup question) > > Q1. Based on a post on 'theinvisiblethings' blog, netVMs are not the same as > AppVMs. Since the backup/restore instructions on the qubes site > (qvm-backup/qvm-backup-restore) is for AppVMs, how can I backup netvms for > the purpose of restoring if/when they are compromised? A legitimate confusion. Perhaps our docs could be more clear. Backups work the same for any type of VM (AppVM, ProxyVM, NetVM, etc.). The differences are mostly in what settings they are allowed to have, what services are run by default, and what directory they are stored in on disk. > (If choice #1 is best) > > 1. Is there a guide on how we can harden the netvm? How can I view what > default services, files, ports/remote access are enabled on the default netvm > and how make my hardening customizations to the netvm permanent? I mainly > want to make sure the netvm has no remote filesystem access from the internet > (i.e. ssh, ftp, etc); the only 'access' should be from dom0. You should do your firewalling, etc. in sys-firewall rather than sys-net. This is because sys-net has a higher chance of being compromised via vulnerable wireless card drivers or malicious wireless card firmware, and you would not want that compromised sys-net to be able to turn off your firewall! ;) This is the reason sys-firewall exists as a separate domain behind it. > Apologies if some of the questions are based on incomplete/incorrect > information; I've tried reading all the Qubes documentation that could be > related to my question such as: > > https://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html > https://www.qubes-os.org/doc/firewall/ > https://www.qubes-os.org/doc/backup-restore/ > https://www.qubes-os.org/getting-started/ > > Thanks, > New Qubes OS user Glad to have you with us! -- 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_B7NSTo8xnHA-1aPDE3c_erFJksvutUnKds%3DRD04hS13A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best practice maintenance of untrusted netvm
On Mon, Mar 13, 2017 at 5:04 AM, Jean-Philippe Ouellet wrote: > On Mon, Mar 13, 2017 at 2:29 AM, InfusingPrivacy > wrote: >> 1. Is there a guide on how we can harden the netvm? How can I view what >> default services, files, ports/remote access are enabled on the default >> netvm and how make my hardening customizations to the netvm permanent? I >> mainly want to make sure the netvm has no remote filesystem access from the >> internet (i.e. ssh, ftp, etc); the only 'access' should be from dom0. > > You should do your firewalling, etc. in sys-firewall rather than > sys-net. This is because sys-net has a higher chance of being > compromised via vulnerable wireless card drivers or malicious wireless > card firmware, and you would not want that compromised sys-net to be > able to turn off your firewall! ;) This is the reason sys-firewall > exists as a separate domain behind it. Likewise, when you are running "high-risk" (complex) protocol parsers (like tcpdump, wireshark, etc.), it is preferable to do so in sys-net (or a cloned sys-net based on a template with such tools installed) rather than sys-firewall, because it is desirable to protect sys-firewall from such attack vectors. -- 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_CkqkAjmj7gpiKHyH3tJUsC1_0%3DQta7OOqsf%2BOnHC5k%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Pasting pw from vault into dom0 for backups?
If your vault actually is very trustworthy and secure, then see https://www.qubes-os.org/doc/copy-from-dom0/#copying-to-dom0 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_BSaS2zDcqWhTKrZ%3DoeMHJn3cOpz4dxbhE4HSk8ijUwWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] feature idea: creat trusted office document
On Tue, Mar 14, 2017 at 7:44 PM, cubit wrote: > - open dom0 terminal > - get dom0 to open a disp terminal in the same dispVM as the disposable doc Ouch. I'd forgotten how annoying that could be. I have a script [1] bound to a keyboard shortcut to open a terminal in the same VM as the front-most window. Perhaps you might find it useful? [1]: https://gist.github.com/jpouellet/0f74459699433cabc26c389caf36b455 -- 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_CSbH2BdG2wq6wGgEn9wegHV4BmDcLe_cYmjr0LXjrMXw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USG - AFirewall For USB's
On Wed, Mar 15, 2017 at 5:00 PM, thinkpad user wrote: > as far as i understand general method(control everything in data stream), > adding support for new type of device is difficult, IF such HW firewall is > connected to HW USB. i recall some device which transfers USB data over LAN, > so user can connect any USB HW over LAN. by this way it is possible to have > special VM with fresh state for every USB dev connection. after device is > used, every possible not wanted effects are gone with the reset of VM. such > VM could start automatically upon each USB plugin event. there is no real > reason also to store such mini temp VM in SSD. it can be located in RAM. If I understand you correctly, I believe all the infrastructure for what you describe already exists in Qubes, and could be accomplished by using qvm-usb to attach each USB device to a new DispVM. Implementing this to happen automatically when a new USB device is connected is left as an exercise for the reader. > i believe Gbit LAN has potential. right now am considering some perverted > "immortal SSD" idea based on following: > SODIMM CHEAP (used) RAM modules (1,2,4 GB) in few motherboards. RAM disc is > created in such motherboard upon boot and then shared over Gbit LAN. i > believe it is possible to make very compact version for notebook(thats what > am planning to do after i figure out how to connect about 16 RAMs. without > having lots of notebook motherboards). motherboards are backed up by battery. > how to use: before actual task, the contents of SSD copied to LAN disk. > before shutdown, HW SSD (or even HDD actually) gets only updated data from > this shared over LAN RAM disk. on RAM disk user can have VMs. WHY? there are > plenty of cheap 1 2 4 GB used RAM modules. as far as i can remember RAM > module have long lifespan. so user actually gets cheap SSD which capacity > only gets bigger over time. i believe there can be one trusted HW machine and > lots of untrusted HW devices shared over LAN or SPI. LAN or SPI opensource HW. > LAN speed is just fine unless you want USB display or Kinect. > again: main idea is to transport original HW USB data stream to the emulated > (Virtual) USB connected to VM, _without firewalling it at all_. using LAN or > other means. Holy frankenstein hardware, batman! Good luck with that... ;) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_Ba0NwY6CNSojfNyZJmYoQuWQjL-EiwiH3Njom5ov1M4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP Global alteration.
Qubes only runs an NTP client in the ClockVM (sys-net) and syncs all other domains via qrexec services, so your claim about NTP traffic coming from multiple VMs on a default system is false. As for changing the NTP server used, feel free to submit patches. -- 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_Bsn6hgvfsBABE20uXfUcUPWoG7%2Bdo%3DDEZWdsSKVcLgeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it really hard to autogenerate apropos data for all qubes utils ?
Unman is correct. Additionally, mandb index generation may be of lesser quality because our man pages are not actual man pages, but rather lifted from reStructuredText via pandoc, which generate raw *roff formatting macros rather than semantic mdoc (or even man(7)) ones. This is because reStructuredText inherently lacks such semantics, and pandoc does not attempt to heuristically assign any. Example: NAME qvm-block - list/set VM PCI devices. Turns into: .TH "qvm\-block" "" "" "" "" .SH NAME .PP qvm\-block \- list/set VM PCI devices. Instead of: .Sh NAME .Nm qvm-block .Nd list/set VM PCI devices -- 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_DEZ56Pdsfnp-gav_AJuzmGPtrz3D80cQKMdE0%3DqiXAGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Tip: How to speed up QubesOS shutdown
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.
Re: [qubes-users] New Qubes installer image?
On Mon, Mar 20, 2017 at 10:19 PM, Marek Marczykowski-Górecki wrote: >> We almost never publish new ISOs for Qubes OS versions that have >> already been released. It's likely that the next time a new ISO will >> be published with updated drivers will be when Qubes 4.0 is released. > > Actually, for Qubes Os 3.2, which will be supported for a while, we do plan > release new ISO image, lets name it Qubes OS 3.2.1. It will have updated > templates, especially newer default Fedora template, and also updated > kernel. We haven't decided for specific versions yet, but I'd like to > have Fedora 25 and kernel 4.9.x there. Both need some testing first and > need to hit stable repository before building new ISO image (kernel > 4.9.x isn't even in testing repository yet). Also quite notably with a debian template past the apt InRelease vuln. I wonder how many people make new installs and update debian via package updates in the existing template without knowing they should first replace it via qubes-dom0-update. IMHO revisiting the ISO publication frequency may not be a bad idea, especially with all the recent build automation improvements making this somehow less work. (Or at least it appears to be less work from my outside perspective... I do not pretend to know everything involved.) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_As_OG5b7X8FrKGKc5QqYMZ4%2BX85B7yZzEc5huz%3DNijvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-users] usability major bug?
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] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
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-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
- 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] Why does Qubes not work with nested virtualization?
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] Maybe a silly question
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] How much important is TPM?
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] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
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] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
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?
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] Security and dispVM firefox customization
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.
[qubes-users] Re: Custom qrexec services
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] Is it possible to download Qubes 3.2 from Github?
On Sat, Apr 1, 2017 at 2:23 PM, wrote: > On my network many websites are blocked (to be precise only a handful are > allowed). However one can get access to github.com. > > Is it possible to download Qubes 3.2 from Github? Here you go: https://github.com/jpouellet/qubes-releases-mirror/releases -- 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_BhWQ0bXHo2EsrswLjGPEyhznFw1b5PMnuAmbfNHNM4og%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Testers wanted
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.
Re: [qubes-users] Re: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)
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 wrote:
> On Mon, Feb 27, 2017 at 3:42 PM, Chris Laprise 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] How do I...?
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.
[qubes-users] Re: [qubes-devel] Re: QSB #29: Critical Xen bug in PV memory virtualization code (XSA-212)
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 much important is TPM?
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.
Re: [qubes-users] Qubes 4.0 Alpha release date
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] realized why I always lose sound in the vms
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] DispVM Configuration
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] HDMI-related threats in Qubes OS
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] HW RNG on dom0?
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] Secure Handling of Encrypted Drives
On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel 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. > > 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
> passthrough to a VM while it is running(?)
Your understanding is incorrect on the following details:
1) you *can* do pci passthrough to a vm while it's running. Depending
on if the device supports function-level-reset or not, you may need to
set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml
2) qvm-block is distinct from and not implemented with pci
passthrough, it uses xen blk{front,back}. This is an entirely
different and believed to be less dangerous interface to expose than
PCI to your actual devices.
That said, you might prefer to use a normal unencrypted filesystem,
only interface with the filesystem in sys-usb, and use encrypted files
instead.
You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
into your other vm, {decrypt, manipulate, re-encrypt} them there, send
back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
them back on the flash drive from there.
This isolates your document processing from potential vulns in your
filesystem manipulation code (such as fuse-exfat which appears to be
the de-facto standard flash drive filesystem these days for maximum
interoperability).
This approach likely has a higher chance of protecting your
document-processing VM from being exploited by filesystem
vulnerabilities, which may be even easier to exploit if you consider a
malicious flash drive with compromised firmware (manipulating metadata
behind your back while the drive is mounted to potentially otherwise
"unreachable" code paths in the fs drivers) to be part of your threat
model.
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_ChXGeH8fp%3DnM%3DuuLLGQGL-paK19mYJfrvCdQ3f_v%2BDDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Secure Handling of Encrypted Drives
On Sun, Apr 16, 2017 at 7:59 PM, Andrew David Wong 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 >>>> 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 passthrough to a VM while it
Re: [qubes-users] qubes manager add start terminal
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] Focus Stealing, how to stop it?
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&q=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] Bug with copy and paste to different window
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] say it out (loud) - Qubes OS Stickers
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] Focus Stealing, how to stop it?
On Fri, Apr 21, 2017 at 10:00 PM, Andrew David Wong wrote: > On 2017-04-20 21:56, Jean-Philippe Ouellet wrote: >> 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&q=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] Re: GPU passthrough: 2000 USD bounty
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.
[qubes-users] Intel ME exploitable
*Sigh*... Yep. We were right to be concerned (of course). And now we have something other than our tin foil hats to point at too: https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ I want my RISC-V laptop already! -- 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_AtFXSAE3r03x5nDugT5JYTaX9kh2MXGE11bZan95Aa2g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to get trusted iso?
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] OpenWhisper Systems Signal not quite right in Qubes 3.2/Fedora23/Chromium
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] Windows hanging at starting up screen (changing xen video -> cirrus not working?)
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] Qubes as primary OS? Multimedia Experience: Spotofy / Netflix / Amazon Prime / how to make it work?
On Mon, May 8, 2017 at 1:30 PM, 'PR' via qubes-users wrote: > Hello, > > I tried to find out what is best practise to use spotify/netflix/amazon > prime/... etc. with Qubes, but it seems that this is not a common usecase. > > The problem is, that I can't those apps ins a "multimedia-windows-app-VM" as > there is no sound-support for windows within Qubes. > > And unfortunately Netflix & Co don't work out of the box with Linux. > > Question: How do you use Qubes with those or similar multimedia-services? > > - P. Netflix works in Chrome, and Spotify has a native Linux client. See the following Spotify installation scripts: - https://gist.github.com/jpouellet/65bd51a35faf139cf1eacd3d6564364f - https://gist.github.com/marmarek/a82cee4efb4eb28e805ea08e74458e7c I'm running it in a Debian-based StandaloneVM. -- 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_DY1TeEEiaqFv2CoP46_46%2B%2BenVVJ4A3TSo3NSEuaOj_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes as primary OS? Multimedia Experience: Spotofy / Netflix / Amazon Prime / how to make it work?
On Mon, May 8, 2017 at 2:15 PM, Ted Brenner wrote: > I've struggled with multimedia as well. I've just been trying to play a DVD > but not be able to get it to work. Though I think this is not a Qubes issue > so much as a Linux issue. I have an old Mac that use for this so I haven't > been highly motivated to make it work. But I'm definitely interested in what > others find as I'd like to have one computer that can solve all my needs. > > On Mon, May 8, 2017 at 12:45 PM, Grzesiek Chodzicki > wrote: >> >> W dniu poniedziałek, 8 maja 2017 19:30:16 UTC+2 użytkownik Piit napisał: >> > Hello, >> > >> > I tried to find out what is best practise to use spotify/netflix/amazon >> > prime/... etc. with Qubes, but it seems that this is not a common >> > usecase. >> > >> > The problem is, that I can't those apps ins a >> > "multimedia-windows-app-VM" as there is no sound-support for windows >> > within Qubes. >> > >> > And unfortunately Netflix & Co don't work out of the box with Linux. >> > >> > Question: How do you use Qubes with those or similar >> > multimedia-services? >> > >> > - P. >> >> Tidal works in Chrome which does have a Linux client so I installed chrome >> and use it to listen to music. DVDs should be exposed as regular block devices that you can attach to a media-playing VM (with VLC installed or whatever) via qvm-block [1]. [1]: https://www.qubes-os.org/doc/dom0-tools/qvm-block/ -- 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_Bb%3DU8VgHEHcbMwv_6Xj99_PqFDBctgEW92EZoi--ummA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Lenovo X1 Carbon 1.gen
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] Why should I clone a template?
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] Help adding documentation to Qubes Repository
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] Re: Dual screen
On Mon, May 15, 2017 at 2:13 PM, Mathew Evans wrote: > change settings with xrandr or gdk-screensettings. gdk-screensettings is not installed in dom0 by default, xfce4-display-settings is, and is the program launched from the Q menu as described by erikmunkandersen. -- 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_AhG%3DuxjursTgizv3_%2Ba_Y-p%3D%3DX5dK0F1KUr3V%2B_tpycQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Windows 7 HVM Install
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] Games on Qubes + Whonix
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] how to check integrity about DVD
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] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
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] https://www.qubes-os.org/doc/vpn/
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] CLI: How to read out the currently set base image for disposable VMs?
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] Split SSH
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] Re: start application on startup
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] HCL
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.
