Re: [qubes-users] Keyboard and mouse issue (R 4.0.1)
On 1/15/19 3:36 AM, jrg.desk...@gmail.com wrote: > KEYBOARD > > How do I set the "compose" key on the keyboard? I have run several Linux > distributions (base on Debian/Ubuntu) for several years and have had no > problems setting a compose key so that I could enter diacriticals and symbols > like the em-dash and the Spanish upside down exclamation and question marks. IIRC there's no gui setting in XFCE for setting a compose key. I don't use such key myself but I guess you can edit dom0's /etc/X11/xorg.conf.d/00-keyboard.conf and add XkbOptions there (eg. Option "XkbOptions" "compose:menu"). Run `grep "compose:" /usr/share/X11/xkb/rules/base.lst` to find what keys you can use. Alternatively, set up an autostart command - you now know how to do that:) - and run setxkbmap like so: setxkbmap -option compose:menu Note: keyboard settings are propagated from dom0 to VMs so you simply need to set them in dom0 to have them working in all the VMs. However I found that this was unreliable when switching languages - in case that's something you have to configure see [1] for a workaround. > The other issue with the keyboard involves disabling the Caps Lock key (I am > a fumble-fingered 73-year old and the caps lock key is the bane of my typing > existence). XkbOptions: caps:none or, setxkbmap -option "caps:none" Combined with the above: setxkbmap -option "caps:none compose:menu" > MOUSE > > Before using the "Salt" method of setting up a sys-usb VM, I had my mouse set > as left-handed. Then I got sys-usb set up. The mouse reverted to > right-handed, but when I checked the System Tools --> Mouse and Touchpad, it > indicated the mouse was left-handed. > > But it is not :-( Changing the setting to right-handed and then back had no > effect. I have searched the menus to no avail. Adding "Settings" to the > sys-usb VM menu and then trying to invoke it failed. Sorry, can't really help here; hopefully other users will chime in. Dumb question though: are you sure you selected the right (no pun intended) mouse in System Tools --> Mouse and Touchpad ? On my system I have 3 mice - the laptop's trackpoint, touchpad and an external usb mouse ; I just tried to set the right/left handed setting for each of them (the setting works individually for each mouse) and it worked. [1] https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md#alternative-setups -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/77d87836-c7f6-cd24-460a-1a1f5626553c%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to autostart a program in an appVM?
On 1/15/19 2:46 AM, jrg.desk...@gmail.com wrote: > I am sure almost everyone has one or more appVMs in which they autostart > programs. That is, how do I set things up so that when a particular appVM is > automatically launched at boot time (or I manually start it), one or more > programs get started automatically? For example, in my "personal" Qube, I > want Thunderbird, Slack (the collaboration tool) and Dropbox to start > automatically. I did exactly that, with the fedora template, setting the programs to auto-start with gnome-tweaks (in previous fedora versions it was named gnome-tweak-tool). There's a section that conveniently allows you to manage the .desktop file links to have programs auto-start at boot. This was the tool I used to fix font appearance (antialiasing mode, hinting) with older fedora versions that had problems (23-24-25). -- Alex -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/23e6171e-0f18-1449-d0d0-78ed2c49d8dc%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to autostart a program in an appVM?
On 1/15/19 3:46 AM, jrg.desk...@gmail.com wrote: > I am sure almost everyone has one or more appVMs in which they autostart > programs. That is, how do I set things up so that when a particular appVM is > automatically launched at boot time (or I manually start it), one or more > programs get started automatically? For example, in my "personal" Qube, I > want Thunderbird, Slack (the collaboration tool) and Dropbox to start > automatically. > > This is another thing I did under "straight" Linux, that I cannot see how to > do under Qubes. I did the RTFM and attempted to find something relevant in > the qubes-users forum -- no luck (or I missed seeing anything). You'll have to use .desktop files (as per the freedesktop "standard" [1]) For a given VM create (or copy/symlink) the .desktop file of the application you want to autostart in $HOME/.config/autostart/ Eg. to start thunderbird: mkdir -p $HOME/.config/autostart/ # in case it doesn't exist yet ln -s /usr/share/applications/mozilla-thunderbird.desktop \ $HOME/.config/autostart/ You can of course create custom .desktop files to (auto)run arbitrary stuff. As a side note the system-wide folder (that you'd customize in your templateVMs) is /etc/xdg/autostart. [1] https://specifications.freedesktop.org/desktop-entry-spec/latest/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/988786a0-3eab-7d0e-5d47-65b64ca6874c%40maa.bz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to autostart a program in an appVM?
I am sure almost everyone has one or more appVMs in which they autostart programs. That is, how do I set things up so that when a particular appVM is automatically launched at boot time (or I manually start it), one or more programs get started automatically? For example, in my "personal" Qube, I want Thunderbird, Slack (the collaboration tool) and Dropbox to start automatically. This is another thing I did under "straight" Linux, that I cannot see how to do under Qubes. I did the RTFM and attempted to find something relevant in the qubes-users forum -- no luck (or I missed seeing anything). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/45200626-1c33-4ea4-b22c-c7ae77951d5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Keyboard and mouse issue (R 4.0.1)
KEYBOARD How do I set the "compose" key on the keyboard? I have run several Linux distributions (base on Debian/Ubuntu) for several years and have had no problems setting a compose key so that I could enter diacriticals and symbols like the em-dash and the Spanish upside down exclamation and question marks. The other issue with the keyboard involves disabling the Caps Lock key (I am a fumble-fingered 73-year old and the caps lock key is the bane of my typing existence). MOUSE Before using the "Salt" method of setting up a sys-usb VM, I had my mouse set as left-handed. Then I got sys-usb set up. The mouse reverted to right-handed, but when I checked the System Tools --> Mouse and Touchpad, it indicated the mouse was left-handed. But it is not :-( Changing the setting to right-handed and then back had no effect. I have searched the menus to no avail. Adding "Settings" to the sys-usb VM menu and then trying to invoke it failed. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d053e38d-0707-4eb0-89d1-3c8a8d6d93e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
On Sunday, January 13, 2019 at 7:52:29 PM UTC-6, js...@bitmessage.ch wrote: > John Goold: > > Just discovered that there is only one USB controller (but 4 USB connector > > sockets). So when I tried to attach the USB controller to the appVM (had to > > set it to HVM), I lost the mouse and keyboard :-( > > > > I have got the impression from reading the documentation and posts to this > > forum that if I have disk encryption enabled, that I cannot create a > > sys-usb VM without losing the mouse+keyboard (and possibly not being able > > to enter the pass-phrase when powering up. > > Yea with only one usb controller you can't attach the whole controller > to a VM without losing your usb keyboard/mouse. I'm in the same situation. > > It sounds like you've already looked at the docs but here's the link: > > https://www.qubes-os.org/doc/usb/ > > You have to have sys-usb to attach a usb device like a scanner to an > appvm (unless you can just attach the whole usb controller, which you > can't). > > I haven't done this myself but my understanding from reading the docs is > it's still possible to have sys-usb, you just have to be careful not to > lock yourself out (not able to control the system with usb > mouse/keyboard, or not able to enter encryption passphrase at boot). > > According to the docs, if you're using 4.0, you can just use salt to set > up a usb qube with the ability to use a usb keyboard with the command > > sudo qubesctl state.sls qvm.usb-keyboard > > The doc says that this will create the usb qube if it's not present, and > that it will expose dom0 to usb devices on boot so you can enter the > passphrase. After you do this though you still may want to check your > grub/efi config file to make sure it doesn't have the > "rd.qubes.hide_all_usb" line in it, just in case. > > Or you can follow the steps in the docs to do it manually, just make > sure to add the required lines to the qubes.InputKeyboard and > qubes.InputMouse files first, and don't add the "rd.qubes.hide_all_usb > line to grub/efi config file. > > Also this has security implications since if your sys-usb is compromised > an attacker could scoop up your keystrokes, but this should still be > safer than attaching insecure usb devices to dom0. > > But it should work, unless i'm reading something wrong. > > -- > Jackie I re-read the document you pointed me at (and then re-read it again!). Although I have put several days of work into my transition to using Qubes (I am using Qubes 4.0.1), I would be left with very unappealing options if I could not use the scanner under Qubes. So, with a great deal of trepidation, I tried the Salt approach. It worked flawlessly -- my very first test was to shut down my computer and then reboot. I, though I hate to admit it, had my fingers crossed at the point that the Luks request for a pass phrase showed up. But the keyboard worked and the rest of the boot-up ran fine. I realize there may be some security vulnerabilities because of this set up; however, I am a non-entity as far as some one choosing to invest considerable effort to hack. I doubt any of the USB devices I use pose a threat (to me). There is one strange thing, but I will start a separate thread for it (I do not seem to be able to configure my mouse as left-handed). Thank you very much for taking the time to respond. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/64900629-bf76-4fbd-9ee8-d2d1bc6b8a3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dom0 downloads, but does not update packages
On 1/14/19 6:07 PM, Ivan Mitev wrote: > > > On 1/14/19 5:14 PM, meindatenschrott-re5jqeeqqe8avxtiumw...@public.gmane.org > wrote: >> Had the same issue, just do "sudo dnf reinstall anaconda-core anaconda-gui >> ..." in dom0 and you're good to go. At least, that's what worked for me :-) > > It worked for me, thanks ! > > Still wondering what caused that problem in the first place... > mine magically disappeared ; not sure if this had anything to do with my fedora-29 sys-net clock issue .. lol -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2f871a42-afb6-340c-6b94-57402eff38ed%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dom0 clock keeps resetting to wrong time again
On 1/14/19 10:10 AM, John S.Recdep wrote: > Hello, > > I believe my Bios time is UTC > > qubes-prefs shows my clockvm as sys-net > > I have been trying to use sudo date --set <"localtime TZ"> to get my > dom0 correct. Which it does but within 30-60 it is changing to another > TZ I don't recognize > > I have also tried qvm-sync-clock , and tried a qubes group search as > I remember fighting this out many times with whonix issues , however > > I am at a loss what to do further to problem-solve fix this , > appreciate your help > > > maybe I can switch the template for sys-net back to fedora-28 instead of > -29 . ? > 1-14-19 changing the clockvm to fed-28 and rerunning qvm-sync-clock did nothing BUT* changing sys-net to debian-9 and qvm-sync-clock fixed it sigh case anyone else gets this issue again ; prolly will fix whonixcheck complaints if any as well 'solved' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/78758e3e-d21c-83c0-a1c4-29ee767f1d5d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 - ACPI Errors during boot
Does anyone have any idea how to get rid of these messages without installing the system from scratch again? January 13, 2019 8:05 PM, maur...@disroot.org (mailto:maur...@disroot.org) wrote: Anyone was able to solve this warning messages on boot without having to install a fresh Qubes? These messages show up on every boot. Thank you! April 29, 2018 5:48 PM, maur...@disroot.org (mailto:maur...@disroot.org) wrote: Hi Everyone! During the boot and before unlock the LuKS volume I'm getting a lot of ACPI errors regarding Namespace lookup failure: [ 1.726445] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.726525] ACPI Error: Method parse/execution failed _PR.CPU1._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.726609] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.726739] ACPI Error: Method parse/execution failed _PR.CPU2._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.726932] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.727136] ACPI Error: Method parse/execution failed _PR.CPU3._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.727332] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.727517] ACPI Error: Method parse/execution failed _PR.CPU4._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.727709] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.727896] ACPI Error: Method parse/execution failed _PR.CPU5._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.728105] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.728290] ACPI Error: Method parse/execution failed _PR.CPU6._CST, AE_NOT_FOUND (20170728/psparse-550) [ 1.728483] ACPI Error: [_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20170728/psargs-364) [ 1.728667] ACPI Error: Method parse/execution failed _PR.CPU7._CST, AE_NOT_FOUND (20170728/psparse-550) How can I solve this? Thank you -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/72e50f3bc83621e17ce32c57e51c459b%40disroot.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Lenovo T480 freezes after resume on suspend
I have updated my BIOS to the latest version just in case. I have no Thunderbolt in the BIOS. I'm using a thinkpad T450s laptop from lenovo (no Thunderbolt support). The problem still persists, after resume the sys-usb is dead have to kill it and start it again to resume my USB devices (keyboard and mouse) Any ideas? January 14, 2019 6:49 AM, "Zrubi" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 1/13/19 8:04 PM, maur...@disroot.org wrote: >> Unfortunately this doesn't work for me. Detaching the USB >> controller doesn't work. My sys-usb always hangs on resume. No >> matter which update I make this problem continues to persist. > > You have 2 options to solve this issue: > a, > - - Make sure, you have the latest BIOS firmware. > - - enable Thunderbolt Assist in BIOS > > b, > - - disable Thunderbolt in BIOS > (Hence, you will loose the USB-C connector) > > - -- > Zrubi > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlw8Iq8ACgkQVjGlenYH > FQ1CMA//Vd7JgQFrXGxr3QKhjjWm39NCw8dOTBAOil864t1kMwOol1lZUmoY42tY > znTXdmIT64UXf7/zgRKUsknWaKg1kQnx8uUZIMS+8FA9CiZGhe23psoJosXAhdVM > sGfAd1ZmzrdynTGhxC7xYAwm8M2GOEaa2yuUFkOIMivmWHvptIUlP+inXaQKTq6i > haFtCD5y53rhStcgamb9ePiBe2rrHHyfeN1Y7bfKkxJ6aNKASejLOF/o1X6edF8f > g1fT90ncQm8X7UY9MFuLBEMvoBq4l4TZxWs5E1x5kEOrzwksv1CSIbdak+THe8Lk > /DlnNh8qVWoo8mTj56+gbydUmqQtvlugBxFi2zANWFoP7EsLZqR9KAJubLhI8im8 > TTJ3PgIiM5MULviT6MZr8DH6kga8489T+GAkIAA7tPkQ6XECZp4bLE1FyWjpWFss > Sgo/p0KYcB5TM+jQ+T2cjf1jHCcToxZWcUPyCtrZi99d86Z0fVKDxIBnAqlGIUrl > CcuZdDLwSMHDmdh2s5osmuzjtVvWr+VM/yuPTK8lvQA48b+1dIm2RUcAThbRKf9w > Pu/WlIbr0XDSTzZtnZcqCePN7lQPoIdslRZSsFwt48x4g+Olm0I7cvJEhFTEmmkr > RblAAauus2zvYVS9pxMcBvadrjn/yFHiZq0D//0/beea8fiEf6I= > =JuWi > -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bc11bb14e02709fb797c3c28590c3c66%40disroot.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Can't open xterm from default fedora-29-minimal template
Hello TonyT, Am Mo., 14. Jan. 2019, 01:36 hat Tonyt geschrieben: > [...] > This sounds like this: > https://github.com/QubesOS/qubes-issues/issues/4671 > > Which I solved with this: > The problem: missing e2fsprogs, so /rw cannot be prepared. > quick workaround: qvm-run -u root --no-gui -p fedora-29-minimal 'dnf > install -y e2fsprogs' > Amazing, this did the trick, I was able to get the fedora-29-minimal based sys-vms running. Thanks. - O -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vUQ5VwYdHDiacM6FfwkAwZiBxhgHTvju1aRwpS8cUxtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Install errors on Thinkpad P1 (aka X1 Extreme) with R4.0 and R4.0.1-rc2
On 20190114 at 17:21 + 'awokd' via qubes-users wrote: > Eric Duncan wrote on 1/13/19 9:08 PM: > > > I then spent several days trying to get Nvidia drivers loaded to no avail. > > Also, trying to get just the Intel card working (hybrid graphics) but I've > > hit a brick wall there - Xen just freezes on the initial splash screen of > > the 4 lines showing what kernel is loading. The system hard locks up > > there, with no logs. I highly prefer the Intel drivers for battery life. Arguing about the battery life was making me grin seriously; we're talking about a desktop replacement machine (with the P1 being the smallest of the current generation but even that one will suck the battery dry before you finished watching a movie) and intending to use it without a power supply is a rather limited experience. > A nouveau.modeset=0 might help there. Actually the only way to do it; unlike previous models the current generation P systems offer you "dGPU and iGPU active" or "dGPU only" (unlike the Px0 and Px1 where it was "iGPU" or "dGPU and iGPU"). But it's not a problem in itself; the dGPU is using less energy than the iGPU running on "intel" or "modesetting" (and in my case it's a P3200). And with kernel-latest installed you get all your cores working vs. 1 core on a P52. > That is too bad; I thought those Thinkpads usually worked well with Qubes. It's more of a Linux (and Xen) problem as far as I can judge it; I'm constantly comparing what Qubes can do with an Arch on a second (identical) machine I have around. The worst complaint I might want to make is that nouveau does not have control of screen brightness (unlike intel/modesetting) and acpi_backlight=vendor thinkpad- acpi.brightness_enable=1 is not working as thinkpad-acpi doesn't know the hardware yet. Both network interfaces (and Bluetooth) are working on the P52 so they will be working on the P1 if correctly set up. If there are any Qubes-related problems I'm very sure they will be found and fixed sooner or later. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/743b80eee6a22341709eded9590abafdc8fa482f.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] dom0 clock keeps resetting to wrong time again
Hello, I believe my Bios time is UTC qubes-prefs shows my clockvm as sys-net I have been trying to use sudo date --set <"localtime TZ"> to get my dom0 correct. Which it does but within 30-60 it is changing to another TZ I don't recognize I have also tried qvm-sync-clock , and tried a qubes group search as I remember fighting this out many times with whonix issues , however I am at a loss what to do further to problem-solve fix this , appreciate your help maybe I can switch the template for sys-net back to fedora-28 instead of -29 . ? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d55807e7-39de-1845-810c-9fe9102c226b%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[SOLVED] Re: [qubes-users] Problem installing 4.0.1 on an HP laptop model 15t-da000
The problem has been solved. It turned out that Qubes is tolerant of KDE Neon, but KDE Neon is not tolerant of Qubes. My solution was to delete both installations, install Qubes first, and KDE Neon second. Now both boot fine. So, I did it again in the reverse order, and I replicated my first problem So... the answer was to install KDE neon on top of Qubes rather than Qubes on top of KDE neon. I have no idea why this makes a difference. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/207e5605-efd1-414c-9a9a-8f2e5447adc5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Problem installing 4.0.1 on an HP laptop model 15t-da000
On Monday, January 14, 2019 at 1:40:12 PM UTC-5, bill...@gmail.com wrote: > > Boot Qubes from rescue mode on the USB. Rebuild Qubes' grub and > > initramfs. It will be something like "sudo grub2-mkconfig -o > > /mnt/sysimage/boot/grub2/grub.cfg". Then reboot and try the Qubes option > > again from the grub menu. > > Thanks for the reply! I tried that, and got different behavior. This time, > when I choose "Qubes" from the grub menu, I get *another* grub menu that only > has Qubes as an option. > > When I choose that, I get the error: > > error: no such device: 6f291114-1d52-4d2d-8a6e-6970ceo2ca33 > erro: disk 'lvmid/M16FyN-' not found > error: you need to load the kernel first. > > I noticed a couple of other things as well. I'm beginning to believe that > KDE neon uses grub, not grub2, since there is no grub2 directory in its /boot > directory. I don't know if that would make a difference -- and I could be > wrong. It's based on Ubuntu 18.04, and I'm not sure what that is. The > forums I looked at all referred to grub instead of grub2, but that may just > be short hand. > > Do you think it would make a difference if I installed Qubes first and *then* > KDE neon? I may do that, just to see if Qubes will install by itself... > > > billo By the way, neither of those numbers match the UUID of the Qubes partition when I look at it using blkid in KDE neon... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3c2ab7d2-bccb-45cf-9a7f-f4a64ebe08f9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Problem installing 4.0.1 on an HP laptop model 15t-da000
> Boot Qubes from rescue mode on the USB. Rebuild Qubes' grub and > initramfs. It will be something like "sudo grub2-mkconfig -o > /mnt/sysimage/boot/grub2/grub.cfg". Then reboot and try the Qubes option > again from the grub menu. Thanks for the reply! I tried that, and got different behavior. This time, when I choose "Qubes" from the grub menu, I get *another* grub menu that only has Qubes as an option. When I choose that, I get the error: error: no such device: 6f291114-1d52-4d2d-8a6e-6970ceo2ca33 erro: disk 'lvmid/M16FyN-' not found error: you need to load the kernel first. I noticed a couple of other things as well. I'm beginning to believe that KDE neon uses grub, not grub2, since there is no grub2 directory in its /boot directory. I don't know if that would make a difference -- and I could be wrong. It's based on Ubuntu 18.04, and I'm not sure what that is. The forums I looked at all referred to grub instead of grub2, but that may just be short hand. Do you think it would make a difference if I installed Qubes first and *then* KDE neon? I may do that, just to see if Qubes will install by itself... billo -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4bfc30a5-1810-4189-87f1-6b9fb487a6f7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] More information needed about Qubes security
Hello Alexandre, Am Mo., 14. Jan. 2019, 12:17 hat Alexandre Belgrand < alexandre.belgr...@mailbox.org> geschrieben: > I am still brooding over before installing Qubes. > I suggest installing Qubes on a second harddrve and give it a try, before "brooding over" it ;-) I think the main question should be against which threats you're trying to protect yourself. Then based on how likely each individual threat is you need to combine different solutions to a package, thinking that Qubes alone will help you is wrong. My first thinking is that since Intel ME backdoors provide full access > to authorities, If this is true this is something which will affect every (!) Operating System. Therefore it is not a Qubes topic, but a preboot/BIOS topic. As you have a X230 you can use Coreboot and overwrite the largest part of the ME which will reduce the risk that the remaining parts will offer a big attack window. Look at this howto how you can coreboot the x230: https://github.com/Qubes-Community/Contents/blob/master/docs/coreboot/x230.md There is no way we can stop government agencies. > This is true as the government can change the law at any given time. What you can do is to make it as hard as possible to spy on you. But if you are a high profile target there is not much chance that you can protect yourself (IMHO) > research (read 1) shows that Intel ME has access to all parts of a > computer, even switched-off > You can use ME Cleaner to reduce this risk. but I read that on my laptop, a Lenovo Thinkpad X230, it was > impossible to completely remove Intel ME. Intel ME is constantly > monitoring hardware and if it is removed, the computer will reboot > after 30 minutes Not true, if it is done right. So a reasonable approach to me is to rely on a firewall and monitor > incoming and outgoing packets. This can be an additional line of defense. When I discovered Qubes, it caught my eye but ... > (a) It does not protect from Intel ME backdoors. > As stated above this is not something Qubes must address as Qubes is an Operating System. > (b) Has a Linux firewall running on a normal Fedora kernel, not even > compiled statically with a limited number of modules. This firewall can > be replaced with OpenBSD as discussed on the mailing list. > Not sure what this is about as I am not a firewall expert (c) Using Coreboot might be an alternative, but I don't know how secure > is Coreboot against other attacks. > This is something which the folks at the coreboot mailing list can answer (they have been very helpful when I started to get coreboot running). So my first opinion would be that Qubes can only protect against a > simple software attack, not a complex hardware attack. > I don't see why hardware attacks are complex and software attacks are simple? For me the compartilization which Qubes is offering and the Disposable VMs feature together with other actions like running Coreboot, using TOR and a VPN offers the best protection which I can get today (with my limited technical skillset), your mileage may vary. Give it a try. - O -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2sS%2BFvz35KwA3C8MtpfzHeW8POVZ-efD%2BdASXRYBhAQtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] dom0 downloads, but does not update packages
On 1/14/19 5:14 PM, meindatenschr...@gmail.com wrote: > Had the same issue, just do "sudo dnf reinstall anaconda-core anaconda-gui > ..." in dom0 and you're good to go. At least, that's what worked for me :-) It worked for me, thanks ! Still wondering what caused that problem in the first place... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/57a2dd69-1853-3dd0-f583-7ac8b1cc7516%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] sys-whonix-14 updates issues
Le lundi 14 janvier 2019 13:34:06 UTC+1, Patrick Schleizer a écrit : > Mathew: > What's your /etc/qubes-rpc/policy/qubes.UpdatesProxy settings? > Hi, $ cat /etc/qubes-rpc/policy/qubes.UpdatesProxy whonix-gw-14 $default allow,target=sys-whonix whonix-ws-14 $default allow,target=sys-whonix $tag:whonix-updatevm $default allow,targer=sys-whonix $tag:whonix-updatevm $any deny $type:TemplateVM $default allow,target=sys-net $anyvm $anyvm deny -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d40eac60-ad85-4b07-a238-f4035f954536%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Install errors on Thinkpad P1 (aka X1 Extreme) with R4.0 and R4.0.1-rc2
Eric Duncan wrote on 1/13/19 9:08 PM: I then spent several days trying to get Nvidia drivers loaded to no avail. Also, trying to get just the Intel card working (hybrid graphics) but I've hit a brick wall there - Xen just freezes on the initial splash screen of the 4 lines showing what kernel is loading. The system hard locks up there, with no logs. I highly prefer the Intel drivers for battery life. A nouveau.modeset=0 might help there. At this point, I'm just throwing Arch Linux on it and will come back and revisit it when I have time. It's too bad... I purposely bought this laptop specifically for Qubes. That is too bad; I thought those Thinkpads usually worked well with 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/8d71114e-55db-74ed-05b2-5b9c9a2cb87d%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] More information needed about Qubes security
Le lundi 14 janvier 2019 à 07:16 -0500, Chris Laprise a écrit : > Check out Joanna's blog at Invisible Things Lab. Lots of Qubes' DNA > is > there. Got it, thanks: Intel x86 considered harmful https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/24905b36b567cf92ddb59a785739bc9ced0cbe56.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Lenovo T480 freezes after resume on suspend
On 20190114 at 06:48 +0100 Zrubi wrote: > Error verifying signature: Output from /usr/bin/qubes-gpg- > client-wrapper: > open sig: No such file or directory Did I do something wrong here? - - disable Thunderbolt in BIOS > (Hence, you will loose the USB-C connector) At least on a P52 you are losing more than that; it confuses the hell out of the GPUs if you turn off Thunderbolt and connect a monitor to the USB-C port. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fa9230ea4795c393389a5b8b9eea0c56e7e45d5c.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] dom0 downloads, but does not update packages
Had the same issue, just do "sudo dnf reinstall anaconda-core anaconda-gui ..." in dom0 and you're good to go. At least, that's what 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/92da5474-4a43-4eab-a171-f62be3a218f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] More information needed about Qubes security
On 20190114 at 07:16 -0500 Chris Laprise wrote: > The only hardware alternative that has emerged is OpenPOWER CPUs because > they're an open source design and have no ME-like infrastructure. > Unfortunately, no Qubes-like OS currently runs on it. That's not quite true; you can do something very Qubes-alike on it but it would cost you an arm and a leg because you would have to license an IBM hypervisor to do so. LPAR would definitely give you an adequate environment to implement a similar setup. And yes, I've seen it done already. Although If I really had to start from scratch I would probably reinvent OS/400 with a focus on security. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/357e9f114462344faee178445dab07a919a57f97.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: More information needed about Qubes security
On 20190114 at 03:26 -0800 Foppe de Haan wrote: > can the IME really talk to any NIC? Or just the ones that it has drivers for > (e.g., other intel products)? If the latter, wouldn't an add-in card (or USB > dongle) solve that issue? First: You do not need to quote the entire message if you just want to add two lines of questions. Quote what you refer to and cut the rest out. To answer your question: It depends. The Management Engine has a connection to every bus in your system but after initial tests and the first part of the boot process should be pulling up something euphemistically called "firewall" to prevent all unnecessary access. That leaves you with what Intel calls "vPro" which is part of nearly every current piece of business hardware (I tried getting my hands on a vPro-free Lenovo P52 and was told that mere mortals are not permitted to order them). In that case you have a second PHY on your network connector and the wireless interface is offering a similar mechanism. So getting a machine without THAT will put you at least in the driver's seat regarding control of network connections. You could/should of course remove all wireless interfaces and put a physical packet filter in front of your computer (I'm currently using GL-Inet's GL-USB150 as "USB WLAN interface"). It is of course more work and needs more maintenance. And yes, I consider damning VNC per se a very hipsteresque attitude to security. Especially because the designers didn't even attempt to put anything security-related into the protocol and force you to make your own decisions on how to implement it. At that point I stopped reading the message you quoted and nearly stopped reading yours, too. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6d93dbafba3a8ad9b49e070466e8eaba19736dcc.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] sys-whonix-14 updates issues
Mathew: > Hello, > > Just to know if there is a solution for whonix-gw/whonix-ws updates ? > Noted that I can update/upgrade sys-whonix-14 without any problems ! I have > to do it again after rebooting though. > > $ sudo apt-get-update-plus dist-upgrade > WARNING: Execution of /usr/bin/apt-get prevented by /etc/uwt.d/40_qubes.conf > because no torified Qubes updates proxy found. > > Please make sure Whonix-Gateway (commonly called sys-whonix) is running. > > - If you are using Qubes R3.2: The NetVM of this TemplateVM should be set to > Whonix-Gateway (commonly called sys-whonix). > > - If you are using Qubes R4 or higher: Check your _dom0_ > /etc/qubes-rpc/policy/qubes.UpdatesProxy settings. > > _At the very top_ of that file. > > Should have the following syntax: > Name-Of-Whonix-TemplateVM $default > allow,target=Whonix-Gateway-TemplateBased-ProxyVM > > Example entry for Whonix-Gateway TemplateVM: > whonix-gw-14 $default allow,target=sys-whonix > > Example entry for Whonix-Workstation TemplateVM: > whonix-ws-14 $default allow,target=sys-whonix > > Try running in Whonix-Gateway (commonly called sys-whonix): > sudo systemctl restart qubes-whonix-torified-updates-proxy-check > > If this warning message is transient, it can be safely ignored. > > Thanks ! > > Regards, > Mathew > What's your /etc/qubes-rpc/policy/qubes.UpdatesProxy settings? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9df3628f-7e56-19b0-8754-0f2806f1372d%40whonix.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] More information needed about Qubes security
On 01/14/2019 06:17 AM, Alexandre Belgrand wrote: Hello, I am still brooding over before installing Qubes. My first thinking is that since Intel ME backdoors provide full access to authorities, there is no way we can stop government agencies. Recent research (read 1) shows that Intel ME has access to all parts of a computer, even switched-off. This is not an NSA problem. If the NSA can do it, then any government agency including the Chinese, the Russians, the Germans, the French, India, etc .. can break into anyone's computer. Intel ME even includes a VNC server (VNC is crap), which should be able to display dom0. Intel ME has direct access to network cards and connections are routed to the Intel ME before they reach the network stack. Therefore, network connections from intruders should be invisible to dom0 and other cubes. There is also the alternative to switch to Coreboot and try to disable Intel ME. But I read that on my laptop, a Lenovo Thinkpad X230, it was impossible to completely remove Intel ME. Intel ME is constantly monitoring hardware and if it is removed, the computer will reboot after 30 minutes. In the X230 legacy bios, I disabled Intel ME completely, but a test in Gnu/linux shows it is still active. Also, when installing Coreboot, I loose Lenovo's frequent BIOS updates, and I am not very sure to be protected against Intel meltdown and Spectre. So a reasonable approach to me is to rely on a firewall and monitor incoming and outgoing packets. Network surveillance is IMHO the only way to discover an attack. I am using PC Engines APU with coreboot and open hardware, which is the best I can find in my price range. Network surveillance is how I discovered last time that my computer had been hacked, when I saw packets flowing to China. A lot of Qubes users have come to similar breaking points about computer security. We recognize the severity of the situation but refuse to be debilitated by it. Since then, now I keep no personal document on a computer. When I discovered Qubes, it caught my eye but ... (a) It does not protect from Intel ME backdoors. Since Qubes offers some protection against hardware, many discussions were had in Qubes' earlier days about the scope of that protection. IIRC the consensus was that nothing could be done in the near future about Intel/AMD's position and it was best to reduce the number of trusted components/vendors to as few as possible. That means the CPU is the hardware focus of trust for Qubes, with the goal of reducing it to the CPU only. More realistically, the keyboard and graphics must be trusted as well. That is still a small set of trusted components. The only hardware alternative that has emerged is OpenPOWER CPUs because they're an open source design and have no ME-like infrastructure. Unfortunately, no Qubes-like OS currently runs on it. (b) Has a Linux firewall running on a normal Fedora kernel, not even compiled statically with a limited number of modules. This firewall can > be replaced with OpenBSD as discussed on the mailing list. Fedora is an issue because its vulnerable to manipulation by recently patched bugs. However, Debian is available and is more secure. There is also a unikernel firewall available for a bare minimum system footprint. OTOH, firewall is the one application I don't worry about too much because by nature its fairly low-risk. (c) Using Coreboot might be an alternative, but I don't know how secure is Coreboot against other attacks. You may want to ask their mailing list about that. I think their main threat model is avoiding mishaps in the system firmware that otherwise could be fixed or prevented in an open source setting. So my first opinion would be that Qubes can only protect against a simple software attack, not a complex hardware attack. I would think that most complex software attacks would also fail on Qubes. But there is not much reporting on this topic except that researchers occasionally mention Qubes in a positive light when they announce new vulnerabilities affecting popular operating systems. What's interesting in Qubes is that : (d) It has reasonable defense in depth, at the scale of today's hardware. I'm not sure that term even applies here. Qubes isolates anything that carries substantial risk using a small 1MB hypervisor called Xen... everything hinges on it. Linux or Windows or whatever can do their thing within VMs to provide features, but as far as security goes they have been demoted. (e) It has good privacy protection. For example, it can protect me and my family when surfing on Internet and keep my data private. If you can tell me anything more about Qubes security, I am really interested. I am still waiting for more information before stepping on. Check out Joanna's blog at Invisible Things Lab. Lots of Qubes' DNA is there. (1) What we have learned about Intel ME
Re: [qubes-users] Re: More information needed about Qubes security
Le lundi 14 janvier 2019 à 03:26 -0800, Foppe de Haan a écrit : > can the IME really talk to any NIC? Or just the ones that it has > drivers for (e.g., other intel products)? If the latter, wouldn't an > add-in card (or USB dongle) solve that issue? It seems that the IME is a complete computer with direct access to northbridge and southbridge and can intercept any signal on the host and replace any firmware. So sniffing USB to reassemble network traffic should not be impossible. Read Blackhat presentations : Slides: https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf PDF: https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11dd0a11860b16f6af79272bbaa63754792ff125.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Salt orchestration
On 1/11/19 7:41 PM, Marek Marczykowski-Górecki wrote: > On Mon, Jan 07, 2019 at 12:20:31PM -0500, Brian C. Duggan wrote: >> On 1/4/19 3:08 PM, Brian C. Duggan wrote: >>> 2. Salt should ensure that service VMs are running before Salt applies >>> states to their client VMs. For example, I have a service VM that >>> exports gpg-agent's SSH socket through Qrexec. This VM needs to be >>> running so that the client VM can clone git repos using keys on the >>> serivce VM. >>> > >> I did some more testing. Of course, Qubes starts halted VMs when another >> VM makes a Qrexec RPC call to it. The calling process on the client VM >> will block until the service VM starts and the RPC call returns. So this >> isn't really a valid use case for orchestration. > >> At first, I thought the SSH authentication attempts failed because the >> service VM wasn't started yet. After more testing, I can see that the >> systemd socket service just doesn't work at the stage during initial >> boot that Salt runs. The socket file exists at this stage, though. SSH >> authentication succeeds during subsequent Salt runs after the VM is booted. > >> But I've also noticed that sometimes a new app VM's grain ID is still >> the template's ID when Salt processes templates. > > That shouldn't happen in theory... Can you give more details, especially > which templates, and qubes* packages version? > Sure, I was able to reproduce it and I created an issue for it with the templates and qubes* packages versions: https://github.com/QubesOS/qubes-issues/issues/4709 Briefly, app VMs get their templates' grains['id'] for about five minutes after applying a state to the template and shutting down the template. > Additionally, even if grain['id'] doesn't match, target VM will get > access to other's VM pillar data - it's enforced when copying pillar > data out of dom0. > Hm, my target VMs only get access to pillar data that is applied to them through the top file or through templating. They don't see other VM's pillar data. Did I understand you right? > >> This can be a problem >> when both dom0 and app VMs need the same pillar data: > >> pillar/app/client-vm-1.sls: >> app: >> client-vm-1: >> server-name: server-vm-1 > >> pillar/app/client-vm-2.sls: >> app: >> client-vm-2: >> server-name: server-vm-1 > >> pillar/top.sls: >> base: >> dom0,client-vm-1: >> - match: list >> - app.client-vm-1 >> dom0,client-vm-2: >> - match: list >> - app.client-vm-2 > >> dom0 needs the combined app data to set RPC policies between the clients >> and their servers. The clients need their own data to configure which >> service VM to send their RPC to. It's convenient for clients to find it >> through pillar['app'][grains['id']]. Maybe there's a better way of >> constructing this pillar data? > > The fact that you'll see only the right pillar data, regardless of > grains['id'] may help you. You can iterate over 'app' dict and use > whatever you find there, regardless of the first key name level. > It will complicate your configuration, but until proper solution is > found, it should work. > That's what I ended up doing, I think. In my formula I select the first key in the app dict in the Jinja template. Since there's only one key available to each client VM, it doesn't matter that the grains['id'] doesn't match the key name. >> Is there a way to delay Salt execution on VMs until they are fully booted? > > By default it's delayed until qrexec-agent is started, which should be > after essential services. If you want, you may: > > 1. Add a state waiting for user session and order other things after it. > This won't help with grains and such things, as salt load them before > considering states, but may help with some states, if are dependent on > running X server for example. For this, add this: > > /etc/qubes-rpc/qubes.WaitForSession: > cmd.run: > - runas: user > > 2. Configure qubes.VMRootShell qrexec service in a VM (used by salt) to > wait for user session. This will affect the whole salt call for that VM. > But also means it will wait indefinitely if no user session is started > at all (for example you're logged out of dom0). > For this create /etc/qubes/rpc-config/qubes.VMRootShell in the template > with "wait-for-session=1" inside. > These are great ideas! I'll try them out. >> For the curious, I'm using a Salt formula to set up access to gpg-agent >> on a service VM from client VMs through Qrexec: > >> https://gitlab.com/bcduggan/qrexec-gpg-agent-formula > > One MAJOR problem with giving unfiltered access to gpg-agent is that, > client can request gpg-agent to export secret keys. Which defeat the > whole purpose of keeping secret keys in separate qube - that client have > no access to its secret part. This is correct for the default gpg-agent 2.1.x socket, S.gpg-agent. I don't export that one to client VMs. Starting in GnuPG 2.1.1, gpg-agent presents a socket with restricted
[qubes-users] Re: More information needed about Qubes security
On Monday, January 14, 2019 at 12:17:21 PM UTC+1, Alexandre Belgrand wrote: > Hello, > > I am still brooding over before installing Qubes. > > My first thinking is that since Intel ME backdoors provide full access > to authorities, there is no way we can stop government agencies. Recent > research (read 1) shows that Intel ME has access to all parts of a > computer, even switched-off. > > This is not an NSA problem. If the NSA can do it, then any government > agency including the Chinese, the Russians, the Germans, the French, > India, etc .. can break into anyone's computer. > > Intel ME even includes a VNC server (VNC is crap), which should be able > to display dom0. Intel ME has direct access to network cards and > connections are routed to the Intel ME before they reach the network > stack. Therefore, network connections from intruders should be > invisible to dom0 and other cubes. > > There is also the alternative to switch to Coreboot and try to disable > Intel ME. But I read that on my laptop, a Lenovo Thinkpad X230, it was > impossible to completely remove Intel ME. Intel ME is constantly > monitoring hardware and if it is removed, the computer will reboot > after 30 minutes. In the X230 legacy bios, I disabled Intel ME > completely, but a test in Gnu/linux shows it is still active. > > Also, when installing Coreboot, I loose Lenovo's frequent BIOS updates, > and I am not very sure to be protected against Intel meltdown and > Spectre. > > So a reasonable approach to me is to rely on a firewall and monitor > incoming and outgoing packets. Network surveillance is IMHO the only > way to discover an attack. I am using PC Engines APU with coreboot and > open hardware, which is the best I can find in my price range. > > Network surveillance is how I discovered last time that my computer had > been hacked, when I saw packets flowing to China. > > Since then, now I keep no personal document on a computer. > > When I discovered Qubes, it caught my eye but ... > (a) It does not protect from Intel ME backdoors. > (b) Has a Linux firewall running on a normal Fedora kernel, not even > compiled statically with a limited number of modules. This firewall can > be replaced with OpenBSD as discussed on the mailing list. > (c) Using Coreboot might be an alternative, but I don't know how secure > is Coreboot against other attacks. > > So my first opinion would be that Qubes can only protect against a > simple software attack, not a complex hardware attack. > > What's interesting in Qubes is that : > (d) It has reasonable defense in depth, at the scale of today's > hardware. > (e) It has good privacy protection. For example, it can protect me and > my family when surfing on Internet and keep my data private. > > If you can tell me anything more about Qubes security, I am really > interested. I am still waiting for more information before stepping on. > > (1) What we have learned about Intel ME > http://blog.ptsecurity.com/2018/11/what-we-have-learned-about-intel-me.html can the IME really talk to any NIC? Or just the ones that it has drivers for (e.g., other intel products)? If the latter, wouldn't an add-in card (or USB dongle) solve that issue? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7066e924-5548-42ef-b3b6-48bf3a7ffb25%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
> So in theory you would plug your scanner which should appear in sys-
> usb,
> and you'd attach ("proxy") it to a VM where you have your scanning
> software installed. If you're lucky it will work that way but not
> every
> USB device works well with proxying and scanners aren't know to be
> very
> plug friendly. In that case you will have to use sys-usb
> directly
> (either for firmware loading - most scanners need that nowadays - or
> for
> firmware loading + scanning software).
> That's also why you have the option to combine sys-net and sys-usb
> into
> one VM during installation time: some USB networking devices can't be
> proxied so the only way to use them is to have the usb controllers in
> sys-net (or symmetrically, networking support in sys-usb).
Sounds reasonable. I am using a sane scanner which requires no
firmware, so it should work.
> Ditto for the smartcard reader...
OpenSC is pretty standard. I am using a stock CCID smartcard reader.
Should also work.
Thanks !
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/115311007a404367071fe0d23d893a0942bac876.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] More information needed about Qubes security
Hello, I am still brooding over before installing Qubes. My first thinking is that since Intel ME backdoors provide full access to authorities, there is no way we can stop government agencies. Recent research (read 1) shows that Intel ME has access to all parts of a computer, even switched-off. This is not an NSA problem. If the NSA can do it, then any government agency including the Chinese, the Russians, the Germans, the French, India, etc .. can break into anyone's computer. Intel ME even includes a VNC server (VNC is crap), which should be able to display dom0. Intel ME has direct access to network cards and connections are routed to the Intel ME before they reach the network stack. Therefore, network connections from intruders should be invisible to dom0 and other cubes. There is also the alternative to switch to Coreboot and try to disable Intel ME. But I read that on my laptop, a Lenovo Thinkpad X230, it was impossible to completely remove Intel ME. Intel ME is constantly monitoring hardware and if it is removed, the computer will reboot after 30 minutes. In the X230 legacy bios, I disabled Intel ME completely, but a test in Gnu/linux shows it is still active. Also, when installing Coreboot, I loose Lenovo's frequent BIOS updates, and I am not very sure to be protected against Intel meltdown and Spectre. So a reasonable approach to me is to rely on a firewall and monitor incoming and outgoing packets. Network surveillance is IMHO the only way to discover an attack. I am using PC Engines APU with coreboot and open hardware, which is the best I can find in my price range. Network surveillance is how I discovered last time that my computer had been hacked, when I saw packets flowing to China. Since then, now I keep no personal document on a computer. When I discovered Qubes, it caught my eye but ... (a) It does not protect from Intel ME backdoors. (b) Has a Linux firewall running on a normal Fedora kernel, not even compiled statically with a limited number of modules. This firewall can be replaced with OpenBSD as discussed on the mailing list. (c) Using Coreboot might be an alternative, but I don't know how secure is Coreboot against other attacks. So my first opinion would be that Qubes can only protect against a simple software attack, not a complex hardware attack. What's interesting in Qubes is that : (d) It has reasonable defense in depth, at the scale of today's hardware. (e) It has good privacy protection. For example, it can protect me and my family when surfing on Internet and keep my data private. If you can tell me anything more about Qubes security, I am really interested. I am still waiting for more information before stepping on. (1) What we have learned about Intel ME http://blog.ptsecurity.com/2018/11/what-we-have-learned-about-intel-me.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/4715d81e5d1075fed58ddb92d4ec580efcb5171a.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
On 1/14/19 11:59 AM, Alexandre Belgrand wrote:
> Le lundi 14 janvier 2019 à 01:52 +, js...@bitmessage.ch a écrit :
>> It sounds like you've already looked at the docs but here's the link:
>> https://www.qubes-os.org/doc/usb/
>> You have to have sys-usb to attach a usb device like a scanner to an
>> appvm (unless you can just attach the whole usb controller, which
>> you
>> can't).
>
> Pardon my ignorance, I am planning to install Qubes on a laptop.
>
> I need to connect to
> (1) a USB scanner and
> (2) a USB smartcard reader (with OpenSC).
>
> In the documentation it is written:
>
> " Note, you cannot pass through devices from dom0 (in other words: a
> USB VM is required). To use this feature, you need to have the qubes-
> usb-proxy package installed in the template used for the USB qube "
>
> Does it mean I will have to create a USB VM and then connect it to
> other VMs using USB proxy. And I will loose USB keyboard and mouse in
> dom0.
You will need a VM with the USB controller assigned to it. Actually that
VM is created by default at install time (it's called "sys-usb"). You
won't "loose" your USB keyboard/mouse in dom0: those are "proxied" from
sys-usb to dom0 with the help of the qubes-input-proxy daemon, which -
if I'm not mistaken - has nothing to do with proxying of USB devices
from one VM to another.
So in theory you would plug your scanner which should appear in sys-usb,
and you'd attach ("proxy") it to a VM where you have your scanning
software installed. If you're lucky it will work that way but not every
USB device works well with proxying and scanners aren't know to be very
plug friendly. In that case you will have to use sys-usb directly
(either for firmware loading - most scanners need that nowadays - or for
firmware loading + scanning software).
That's also why you have the option to combine sys-net and sys-usb into
one VM during installation time: some USB networking devices can't be
proxied so the only way to use them is to have the usb controllers in
sys-net (or symmetrically, networking support in sys-usb).
Ditto for the smartcard reader...
Hope this helps...
Ivan
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/85d1a3ea-502c-314e-a6a5-3aad1814b399%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
Le lundi 14 janvier 2019 à 01:52 +, js...@bitmessage.ch a écrit : > It sounds like you've already looked at the docs but here's the link: > https://www.qubes-os.org/doc/usb/ > You have to have sys-usb to attach a usb device like a scanner to an > appvm (unless you can just attach the whole usb controller, which > you > can't). Pardon my ignorance, I am planning to install Qubes on a laptop. I need to connect to (1) a USB scanner and (2) a USB smartcard reader (with OpenSC). In the documentation it is written: " Note, you cannot pass through devices from dom0 (in other words: a USB VM is required). To use this feature, you need to have the qubes- usb-proxy package installed in the template used for the USB qube " Does it mean I will have to create a USB VM and then connect it to other VMs using USB proxy. And I will loose USB keyboard and mouse in dom0. So is the only solution to buy a USB card and plug it in the laptop? Kind regards, -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dcb8712b169a3b4e5cb1ea6434fd884583a7e448.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Using OpenBSD as Qubes firewall
On Sunday, January 13, 2019 at 8:29:02 PM UTC+1, alexandre...@mailbox.org wrote: > Dear all, > > > > > > > > >Pardon my ignorance, is it possible to use OpenBSD to provide firewalling > to Qubes? > > > >I have nearly zero confidence in GNU/Linux although I use it everyday. > > > > > > > > >Kind regards, have you looked into Mirage? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/222b20c7-0c08-4583-954f-c88b54229b8c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using OpenBSD as Qubes firewall
Le lundi 14 janvier 2019 à 00:35 +, unman a écrit : > You can find some notes that may help here: > https://github.com/unman/notes/blob/master/openBSD_as_netvm Thanks. This seems very interesting. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/01f7a6b66384b523077051342afc470298207742.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
