[qubes-users] Re: Windows HVM doesn't get updates
On Sunday, April 10, 2016 at 4:21:26 PM UTC-7, Salmiakki wrote: > I just installed Win7 in a HVM and I can ping and I can access websites but > it doesn't find any windows updates. > Any suggestions what I might be missing? > Any ideas where I might look for information? The update just seems to hang... Here is the authoritative way to fix Win7 update issues on a new install. I've used it multiple times, including my recent Qubes HVM install. However, one thing it doesn't say that I highly recommend is to STOP the Windows Update service before installing the downloaded update package(s) in step 3. http://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-solution/f39a65fa-9d10-42e7-9bc0-7f5096b36d0c -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7c0125e9-c538-4849-801b-14e04e6d6839%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix Gateway and normal AppVM behind?
Drew White: > Hi folks, > > If I'm using the Whonix Gateway guest, and I have it as a ProxyVM, is it safe > to assume that if I use a normal AppVM, (non-whonix) behind it, then that > means that everything is still going through the Tor network? > > (Just wanting to make 100% sure) > > Sincerely, > Drew. > Drew, I know you only concern yourself with the most complex, technical details; but every once in a while, you should come see how us small-minded, non-dev "little people" live: Google "Whonix" | https://www.whonix.org/ | https://www.whonix.org/wiki/ | https://www.whonix.org/wiki/Documentation | https://www.whonix.org/wiki/Other_Operating_Systems BTW, all 20 of the questions in your qubes-devel thread (which incidentally has nothing to do with qubes-devel) are also answered in the docs. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5bb9502a-93de-fb0a-c2c7-bc41f8dcc369%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Whonix Gateway and normal AppVM behind?
Hi folks, If I'm using the Whonix Gateway guest, and I have it as a ProxyVM, is it safe to assume that if I use a normal AppVM, (non-whonix) behind it, then that means that everything is still going through the Tor network? (Just wanting to make 100% sure) Sincerely, Drew. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2d71f5bb-ae9b-470b-8280-f217b4fadfe6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to install Wickr in Qubes Debian AppVm ?
On Thu, Nov 03, 2016 at 06:59:09AM -0700, legobloock wrote: > having trouble doing this anyone can help what to type into the terminal? > > https://www.wickr.com/personal#medownload > have you looked at the requirements? They include OpenGL, which isnt enabled in any appVMs.(See the FAQ on this.) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161104000425.GA11856%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Intrusion detection daemons in VMs
Coming out of a discussion in https://groups.google.com/forum/#!topic/qubes-users/hs2yapPlUVA I am interested, does anyone run intrusion detection tools within their VMs? I use OSSEC [1] extensively elsewhere (on servers), but not sure it would work so well in agent-server model in Qubes. 'local' mode would work, but I would still want to get notifications of events/attacks, even from vaulted VMs that can't send email. Since Qubes design suggests we should expect VM compromise, I think it makes sense to having something looking for such a compromise rather than just periodically rebuild my VMs (as I currently do). Anyone else looked into a nice solution? [1] http://ossec.github.io -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/de52cd24-e836-4153-86c4-2edfa4304447%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [FAILED] Failed to start Load Kernel Modules
On Thursday, November 3, 2016 at 4:25:03 PM UTC-5, raah...@gmail.com wrote: > On Thursday, November 3, 2016 at 4:48:01 PM UTC-4, Douglas Harding wrote: > > On Thursday, November 3, 2016 at 3:38:17 PM UTC-5, Douglas Harding wrote: > > > attempting to try R3.1 instead of R3.2 to see if it's possibly just > > > faulty for some reason. (I did checksums, but maybe my specific > > > configuration just won't work with 3.2). I will update after the > > > installation is finished. > > > > This appears to have worked. :) I hope this helps someone else in the > > future. > > I've always gotten the failed to load kernel modules, on multiple diff > machines and I've just always ignored it. What worked or what did you do? > Do you no longer get the message? The message never let me pass it. My machine would freeze indefinitely. To fix it, I just installed the previous 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/63faa77d-f6ad-4b42-9591-fe5931d0297c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: No Kernel update since dirtycow (copy-on-write) exploit?
On Friday, November 4, 2016 at 9:27:24 AM UTC+11, Marek Marczykowski-Górecki wrote: > > In Qubes VM, it's nothing more than "sudo -s" which you have for free > already. Basically, the idea is that someone get code execution in the > VM, there is nothing worse in that VM. Getting root gives you nothing > more - all the user data is in /home/user, accessible from normal user. > For lengthier explanation, see /etc/sudoers.d/qubes[1] in the VM. > > Anyway there is updated kernel package in current-testing repository. Thanks Marek It does raise something else I've been thinking about: since the user home dir is persistent across VM reboots, seems quite likely to store malware there so that it's persistent. So in a way /home/user becomes even more interesting target to someone who wants to attack Qubes.. Perhaps should be a separate topic, but does anyone run intrusion detection tools within their VMs? I use OSSEC extensively but not sure it would work so well in agent-server model in Qubes, perhaps 'local' mode is best.. but would still want to get notifications, even from vaulted VMs that can't send email. Actually I think I'll make that separate topic :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/02fd1011-58ed-4c9d-86cc-f9c51ed13a43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: No Kernel update since dirtycow (copy-on-write) exploit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Nov 03, 2016 at 03:09:51PM -0700, miguel.j...@gmail.com wrote: > On Saturday, October 29, 2016 at 5:27:11 AM UTC+11, dede wrote: > > Qubes still use 4.4.14-11. > > > > So it's still vulnerable, right? > > > > Even qubes not like a normal linux distribution i would sleep better if > > we get a update. > > I'd second this, and I'm surprised not more people are talking about it. > > I know that QubesOS design means we should plan for any VM compromise, and I > even make a routine of rebuilding my more important network-facing VMs just > in case. > > But even still, it would be nice to have a bit of 'defense in depth' - this > Dirty Cow vuln so trivial to exploit, no reason to make it easier. Is it a > big problem to patch the kernel in 3.1/3.2 ? Happy to test a fix in > securitytesting repo. In Qubes VM, it's nothing more than "sudo -s" which you have for free already. Basically, the idea is that someone get code execution in the VM, there is nothing worse in that VM. Getting root gives you nothing more - all the user data is in /home/user, accessible from normal user. For lengthier explanation, see /etc/sudoers.d/qubes[1] in the VM. Anyway there is updated kernel package in current-testing repository. [1] https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes.sudoers - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYG7nJAAoJENuP0xzK19csozAH/2a1cpIKqS/RmL/xWXfyJ5+B eCqL7VZXl1jOwPLa90GWjUDgtGWSYQuTWkpqZuCnbFERsw7RtRCT3tu4IxsLvukQ oV3EwdxKBJS1HGA2yNXa4BHCc6EZ1E0vazdNXMO6RR3f8FU2+nWhhgy9UK4FiLks 25kcsrwbHzJc8p3oBZ21Y9FWNzSAWYApStUnR6Fq+SusIG3OojXUUW9woo0DGwaA TkJ+ucHZbTpVVqFBE3XXA9fBQBzXrLJ8Tuom8r1eGqPTvLZJjNBJu5jfm9QL5uUJ ON8ydp2BTqaNS+yR8eznjAknNNcZhZYgITLzdyz5F1Lb0Joxe8Pg6bNA5YR6a5A= =wZ5R -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/20161103222718.GK22572%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No Kernel update since dirtycow (copy-on-write) exploit?
On Saturday, October 29, 2016 at 5:27:11 AM UTC+11, dede wrote: > Qubes still use 4.4.14-11. > > So it's still vulnerable, right? > > Even qubes not like a normal linux distribution i would sleep better if > we get a update. I'd second this, and I'm surprised not more people are talking about it. I know that QubesOS design means we should plan for any VM compromise, and I even make a routine of rebuilding my more important network-facing VMs just in case. But even still, it would be nice to have a bit of 'defense in depth' - this Dirty Cow vuln so trivial to exploit, no reason to make it easier. Is it a big problem to patch the kernel in 3.1/3.2 ? Happy to test a fix in securitytesting repo. Mig -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/23955332-e3d5-435d-ac2e-dac2e21e2708%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [FAILED] Failed to start Load Kernel Modules
On Thursday, November 3, 2016 at 4:48:01 PM UTC-4, Douglas Harding wrote: > On Thursday, November 3, 2016 at 3:38:17 PM UTC-5, Douglas Harding wrote: > > attempting to try R3.1 instead of R3.2 to see if it's possibly just faulty > > for some reason. (I did checksums, but maybe my specific configuration just > > won't work with 3.2). I will update after the installation is finished. > > This appears to have worked. :) I hope this helps someone else in the future. I've always gotten the failed to load kernel modules, on multiple diff machines and I've just always ignored it. What worked or what did you do? Do you no longer get the message? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bdbb672f-46cc-4c6e-86eb-0a1d9fb63fc4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [FAILED] Failed to start Load Kernel Modules
On Thursday, November 3, 2016 at 3:38:17 PM UTC-5, Douglas Harding wrote: > attempting to try R3.1 instead of R3.2 to see if it's possibly just faulty > for some reason. (I did checksums, but maybe my specific configuration just > won't work with 3.2). I will update after the installation is finished. This appears to have worked. :) I hope this helps someone else in the future. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ec70f37d-ae1c-47ce-ae59-611831a940c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [FAILED] Failed to start Load Kernel Modules
attempting to try R3.1 instead of R3.2 to see if it's possibly just faulty for some reason. (I did checksums, but maybe my specific configuration just won't work with 3.2). I will update after the installation is finished. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eb130e4c-03c7-4278-bc8c-1ca26fad4df3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [FAILED] Failed to start Load Kernel Modules
On Thursday, November 3, 2016 at 3:15:08 PM UTC-5, Douglas Harding wrote: > I have reinstalled 4 times. Every time it was from a fresh install. > > A red "FAILED" pops up stating `[FAILED] Failed to start Load Kernel Modules` > > Then I get failed messages at the bottom: > > `nouveau :01:00.0: gr: failed to load fecs_inst` > `nouveau :01:00.0: DRM: Pointer to flat panel table invalid` > > then it freezes so I have to do a hard reset. > > The only issue I could think of (because nouveau) is that it's my graphics > card, as nVidia has issues. However, when attempting to use the guide on the > official Qubes website -- I do not have the ability to click `“failsafe” boot > menu`as the only thing that shows up is: > > `Qubes, with Xen hypervisor` > `Advanced Options for Qubes (with Xen hypervisor)` > > When I follow "Advanced" I don't have options... However, [FAILED] is no > longer red, it's just grey. > > > -- > What I have tried: > > * reinstall several times > * make sure VT-D is enabled > * I hit "e" to do a temp edit the grub, added "failsafe" after "quiet boot" > * I'm unable to access any logs, command sends me to the grub command prompt. > * unplugging all but 1 monitor > > - > Specs: > > CPU: i5-4570k > GPU: GTX 970 > RAM: 24GB (well over the min. requirements) > SSD: 240GB (plenty of space) > > > Can anyone offer assistance on this? Qubes has been my favorite distro to use > out of the several I had been testing over the last few months. > > Thank you for your time, > Douglas Harding Attempting to install the R1 version to see if perhaps R2 is just faulty for some reason for me. Will update in a few. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/79fe6f19-92ea-4251-b2ea-0e547fd31d15%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [FAILED] Failed to start Load Kernel Modules
I have reinstalled 4 times. Every time it was from a fresh install. A red "FAILED" pops up stating `[FAILED] Failed to start Load Kernel Modules` Then I get failed messages at the bottom: `nouveau :01:00.0: gr: failed to load fecs_inst` `nouveau :01:00.0: DRM: Pointer to flat panel table invalid` then it freezes so I have to do a hard reset. The only issue I could think of (because nouveau) is that it's my graphics card, as nVidia has issues. However, when attempting to use the guide on the official Qubes website -- I do not have the ability to click `“failsafe” boot menu`as the only thing that shows up is: `Qubes, with Xen hypervisor` `Advanced Options for Qubes (with Xen hypervisor)` When I follow "Advanced" I don't have options... However, [FAILED] is no longer red, it's just grey. -- What I have tried: * reinstall several times * make sure VT-D is enabled * I hit "e" to do a temp edit the grub, added "failsafe" after "quiet boot" * I'm unable to access any logs, command sends me to the grub command prompt. * unplugging all but 1 monitor - Specs: CPU: i5-4570k GPU: GTX 970 RAM: 24GB (well over the min. requirements) SSD: 240GB (plenty of space) Can anyone offer assistance on this? Qubes has been my favorite distro to use out of the several I had been testing over the last few months. Thank you for your time, Douglas Harding -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/52f15463-53f8-469f-8e41-df0cd1862d34%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
Am 03.11.2016 um 19:51 schrieb Marek Marczykowski-Górecki: > Really is all that needed? I'd guess you need to have the window visible > during calibration only, which means it should be ok to manually switch > it to fullscreen (from titlebar menu) for that time only. As for the > brightness - is it ok to set it manually? If you take a closer look at the W540's hand rest area you'll notice a small camera-like device. This is a built-in colorimeter. The Windows software coming with it is about the worst piece of "I have to ignore all kinds of security" trash I've ever seen. It is running as "local system" in order to control screen brightness and turn the screen on/interdict sleep while the lid is closed in order to run. I can't really imagine anyone really wanting to use it (considering the fact that the Windows software is carrying about 100MB into your system, parts of it having more privileges than Administrator – who needs that much stuff for calculationg a color profile using specialized hardware?). So yes, the software seems to need those rights (including modifying screen brightness during measurement, at least in the case of Lenovo). > Of course in practice calibration software may not like those > constrains... I would bet on it. Maybe Zrubi can bribe you with 5kg of assorted chocolate to try it yourself (some years ago this https://www.amazon.de/Toblerone-Jumbo-1er-Pack-4-5/dp/B004INT01A used to be quite good currency to convince developers). 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/c96dfcef-f6fa-2b1f-f466-1af92b8478fa%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Arch-template and Firefox (49.0.2)
Hi! I just tried moving my main working environments from the Fedora template to Arch. All in all a much better user experience for nearly everything besides one thing: Firefox tabs are constantly crashing. If I'm opening the same URLs on a native Arch installation or other templates the contents is displayed without any problems. Am I the only one with that problem? And no, no plugins installed at all. Besides that: I could live without ever getiing a Ubuntu (or lookalike) template but it might be time to adopt the Arch template (even if that means the debian template was dropped completely). (Marek: What could we offer to convince a core developer that he always wanted to do this?) 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/92613b45-b8ae-b19f-32f0-97615d6f86e0%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Nov 03, 2016 at 12:01:08PM +0100, Zrubi wrote: > On 11/02/2016 07:28 PM, Marek Marczykowski-Górecki wrote: > > > I have no idea how such software works... Especially at which stage > > calibration is applied. > > The gonme frontend will apply the resulted profile at the end - if > started from the gnome-control-center. > It will gonna fail - as it is not even see any calibration aware device. > (but this is maybe because of the missing colord) > > The other GUI (displaycal) is just create a profile, and the user has a > choice to use (apply) it from a CLI, or whatever. > > > Is it something that application does > > "internally", or adjust display driver options? > > Apps can use the (colord provided) profiles in our own. In the same time > it can be apply X server wise by modifying the graphics driver output > via LUT curvers. > > of course that means that the later have to be done in the GUI domain - > which is currently dom0 > > For the best results we would need both. But in case of Qubes that would > means: > - apply the profile globally in dom0 (or GUI domain) > - provide (the same) profile in VMs via colord > > > The current issue is to create a profile without attaching the > calibration device to dom0. > Even the profile creating is tricky because those calibration software > may try to apply the result but at lest needs to create an app window > which is: > - always on top > - always in focus > - shown on all desktop > - prevents screen blank/lock Really is all that needed? I'd guess you need to have the window visible during calibration only, which means it should be ok to manually switch it to fullscreen (from titlebar menu) for that time only. As for the brightness - is it ok to set it manually? > Those thing should be only be able to achieve by dom0 (GUI domain) > The real strange thing that it was able to pup a window with most of the > features above - but then crashed. The last error message was the result > of that crash. > > The calibration itself ir really simple that window will switch colors, > and the calibrating device (placed over that window) measuring the > actual shown colors, and the "difference" goes to the resulting profile > to get correct colors when applied. If the software do not need to change any video driver properties during the process, it should be ok to run it in the VM. Of course in practice calibration software may not like those constrains... > You can read a more detailed (and probably more accurate) writing about > this here: > https://displaycal.net/#concept > > > >> running the same calibration software directly complains about there is > >> no colord available (masked) > > > > Try unmasking colord (systemctl unmask should do). > > I assumed that colord is masked for a reason by Qubes devs. > Because in a default feadora colord is up and running by default. It's masked mostly to save some RAM. > Will try to unmask it - but not hoping too much. > > As I writing this I see no real chance to make it work without plugging > the calibration device to dom0. - but let me know if you have any idea. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYG4c5AAoJENuP0xzK19cs7wcH/AxJO4RTfX2IEE4j/cyQTX7v E8ZbC3ED7NM+4sloTXkHodyoPTSZmmSOj4SyNeD7Feid4DC7lyPedgCOOWVks6ZD Fy64HwfK+GImzaZXKzqxXuqmfo6TAvVZFxw0CBUQm/pXP/xTTIvULM5sb0DmH+M7 bub6Mcsfvu8fxANwcwmtr7fRUVxf3kg5dldrqHjCI2AHaaRM4gEaoeywMONlhSiI yaR32RhDUSg6pnywlV8phueiuvXlsGAd2f4Q7XCq5oS3ZgOI+iOC+C9hgHZtEbsy uDmb/QBUEd2Ekj/RqPSNIkcn+HSW4uNuEApMkqDwAgo03mPMagEUwPZtZ6xj2bE= =eEgn -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/20161103185134.GW7073%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: ANN: Qubes network server
On 11/02/2016 07:03 AM, Max wrote: > On Thursday, 13 October 2016 01:31:01 UTC+8, Manuel Amador (Rudd-O) wrote: >> Update: >> >> I have dramatically enhanced the documentation of the project: >> >> * https://github.com/Rudd-O/qubes-network-server >> * >> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20your%20first%20server.md >> * >> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20an%20SSH%20server.md >> >> This project is now ready and documented enough to be useful to users of >> Ansible Qubes who want to remotely manage clusters of Qubes OS machines: >> >> * >> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Remote%20management%20of%20Qubes%20OS%20servers.md >> * >> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Enhance%20your%20Ansible%20with%20Ansible%20Qubes.md >> >> I strongly welcome anyone who tries this and shares their experiences. >> It is my goal to get this to be a key part of the Qubes OS strategy. >> >> -- >> >> Rudd-O >> http://rudd-o.com/ > For the "make rpm" command you refer to the local directory of your clone, is > there a tutorial you recommend I should follow for doing this? That *is* the tutorial. cd into your clone, then type "make rpm" (without the quotes). -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/94c88b53-223c-fbd6-e438-6be8ab0d0171%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to install Wickr in Qubes Debian AppVm ?
having trouble doing this anyone can help what to type into the terminal? https://www.wickr.com/personal#medownload -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5f5f5f33-d61d-4948-a965-f3ca804bb8e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] paste clipboard text into rdp session?
On 11/03/2016 12:23 PM, pixel fairy wrote: > is it possible to paste into an rdp session? not share the clipboard with any > app in the session, but the session itself, to type those characters. > > im using remmina, but i dont care what rdp client i use. i just dont want > anything sensitive falling to keyboard timing attacks. > > if not, i realize a couple options. > > 1. keepassx in the appvm. would probably make a dedicated appvm and ssh key > for this. > 2. xdotool in the appvm. > > any other ideas? > I'm using a (dirty) workaround for this: - Qubes copy from my vault - Qubes paste it to the dest AppVM - insert it to a simple terminal/gedit whatever - copy it again from there - paste it to the RDP session. Really annoying - but do not have time and motivation to reveal the problem behind. -- Zrubi -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bbb5149e-c262-12ab-bdc4-4a1e97bb8eae%40zrubi.hu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] paste clipboard text into rdp session?
is it possible to paste into an rdp session? not share the clipboard with any app in the session, but the session itself, to type those characters. im using remmina, but i dont care what rdp client i use. i just dont want anything sensitive falling to keyboard timing attacks. if not, i realize a couple options. 1. keepassx in the appvm. would probably make a dedicated appvm and ssh key for this. 2. xdotool in the appvm. any other ideas? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/410dc02a-ab0c-4692-8dee-45fdde16ffb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On 11/03/2016 12:01 PM, Zrubi wrote: > The current issue is to create a profile without attaching the > calibration device to dom0. > Even the profile creating is tricky because those calibration software > may try to apply the result but at lest needs to create an app window > which is: > - always on top > - always in focus > - shown on all desktop > - prevents screen blank/lock And forget to mention that it will also try to set the screen brightness to maximum before the calibration process starts. > Those thing should be only be able to achieve by dom0 (GUI domain) > The real strange thing that it was able to pup a window with most of the > features above - but then crashed. The last error message was the result > of that crash. -- Zrubi -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3aa64fab-5a1d-a375-d15b-b652d93b5dbe%40zrubi.hu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/03/2016 11:37 AM, Simon wrote: >> I am using UNIX pass, but it has the same flaw. If you copy passwords >> this way they won't automatically get purged from the AppVM, which >> under the assumption that any AppVM is completely compromised at all >> times, is not much of a big deal, but still it would be nicer if the >> password was cleared or even better never copied to the clipboard... > > I think this may be a good point, maybe not of the highest priority > compared to other Qubes issues, but nevertheless a good point even if > from my point of view this could completely uncorrelated from your > tabbed AppVM idea. > > What I understand from your sentence would be a feature like a keyboard > shortcut which, instead of putting the content of the global clipboard > into the AppVM clipboard as Ctrl+Shift-V currently does, would instead > simulate the keystrokes corresponding to the current global clipboard > content (a kind of macro). If you use keepassx you may want to use its auto-type feature, which is designed exactly to prevent password theft by keylogger-only or clipboard-monitor-only malware. Auto type works by typing random parts of the password via simulated keystrokes and other parts via copy-and-paste, making the life of password stealing malware writers miserable ;) > >> Besides it is incredibly annoying to operate this way. I am not >> some prime target of the NSA ^^, and I doubt many of the people using >> qubes will be... So you want to be safe, but you still want the >> convenience... The right way is to block the link, unless it refers to >> a white-listed domain for this identity. > > No, the right way is to propose people an option in the browser's > right-click menu offering them to open this link in an untrusted VM > (similar to the "Send to another VM" or "Open in a disposable VM" option > in the file manager). > > I agree with you that, IMHO, the right-click followed by 'A', > Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter > "shortcut" sequence to achieve the same task currently could and should > be improved in terms of usability for Qubes to reach a wider audience. > But I do like the fact that I have to make so many mistakes in order to copy my data from the "pr0n" VM to the "work-boss" VM... But if I have to copy a pr0n link from a 4chan greentext to another pr0n tab I only have to ctrl+c / ctrl+v like I used to do with plain fedora. I'd strongly disagree with any simplification of inter-vm generic clipboard sharing. I'd agree with some easier facilities for centralized (trusted, without networking) PasswordDatabaseVM. But I'll doubt I'll be using it; I like to keep a "porn" keepass database on the porn VM, many work keepassx db on their respective VM, and so on, to further avoid having a simple "autotype" open the wrong URL. >> The advantage is the same as going back to IE6 times when each tab was >> its own window and having windows with several tabs in addition to >> this madness. I don't see how you can not see the advantage of having >> all browser tabs over all AppVMs organized in a dom0 browser interface >> as tabs in comparison to having tons of floating windows with sub-tabs >> each ;). > > I suppose everyone have their own taste ;). Personally, I prefer to have > windows belonging to different sensitivity levels to be clearly > separated from one another. > > Have you looked toward tabbed windows managers? I do not know if there > is anything which would suit your needs, but their idea as per my > understanding is to handle several windows as tabs. This would however > put two tabs layer instead of one. I do use i3wm as my window manager, and have only 1 monitor with the vertical-split layout; all the others are tabbed, and it works great. It may well emulate the concept of "dom0 browser". >> Are you so sure that your AppVM doesn't have an unique fingerprint >> that potentially could be exposed via a malicious website, browser >> extension or the browser? > > One should not do any change to their Whonix AppVM, so everyone uses the > same, and an app running in the AppVM, no matter how malicious it is, > cannot access anything outside of the AppVm without having to break Xen > isolation first and cannot apply any modification of it which will > survive an AppVM restart. > > So I'm quite confident that there is no easy way to remotely distinguish > two Whonix AppVM instances or identify one. Which is nice, if your threat model is trying to identify the AppVM and not the user behind it - which is usually false. While identification of the client device is one of the way of identifying people it's not the only way, and usually the goal is not the identification of the client device itself. For an easy example, that's why spies in hollywood movies connect to the net from public WiFi hotspots, hotels, airports, but not from home. As I stated in other messages, it's deceptively easy to get carried on to pure paranoia. Model your threat
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On 11/02/2016 07:28 PM, Marek Marczykowski-Górecki wrote: > I have no idea how such software works... Especially at which stage > calibration is applied. The gonme frontend will apply the resulted profile at the end - if started from the gnome-control-center. It will gonna fail - as it is not even see any calibration aware device. (but this is maybe because of the missing colord) The other GUI (displaycal) is just create a profile, and the user has a choice to use (apply) it from a CLI, or whatever. > Is it something that application does > "internally", or adjust display driver options? Apps can use the (colord provided) profiles in our own. In the same time it can be apply X server wise by modifying the graphics driver output via LUT curvers. of course that means that the later have to be done in the GUI domain - which is currently dom0 For the best results we would need both. But in case of Qubes that would means: - apply the profile globally in dom0 (or GUI domain) - provide (the same) profile in VMs via colord The current issue is to create a profile without attaching the calibration device to dom0. Even the profile creating is tricky because those calibration software may try to apply the result but at lest needs to create an app window which is: - always on top - always in focus - shown on all desktop - prevents screen blank/lock Those thing should be only be able to achieve by dom0 (GUI domain) The real strange thing that it was able to pup a window with most of the features above - but then crashed. The last error message was the result of that crash. The calibration itself ir really simple that window will switch colors, and the calibrating device (placed over that window) measuring the actual shown colors, and the "difference" goes to the resulting profile to get correct colors when applied. You can read a more detailed (and probably more accurate) writing about this here: https://displaycal.net/#concept >> running the same calibration software directly complains about there is >> no colord available (masked) > > Try unmasking colord (systemctl unmask should do). I assumed that colord is masked for a reason by Qubes devs. Because in a default feadora colord is up and running by default. Will try to unmask it - but not hoping too much. As I writing this I see no real chance to make it work without plugging the calibration device to dom0. - but let me know if you have any idea. -- Zrubi -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c087c626-81f8-f7dc-604e-4951d8347638%40zrubi.hu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Mara, mara.kuens...@gmail.com wrote : Which is why my idea would be to host Mozilla Sync Service in each App You can already do such thing, the main point being to have each of your Firefox instances to either point to different Sync services or share the same service but use different credential. This way, you can ultimately prevent Firefox from having to store anything locally : Firefox data goes to Sync, downloads you would like to keep goes in your network-less storage AppVM, and everything in the browsing AppVM gets wiped at each AppVM restart. The only limitation for now, as I said in my previous email, is I don't know a way to set an AppVM to use a volatile storage on a day-to-day basis to enforce no modification to remain persistent between AppVM restart except those explicitly allowed through Firefox Sync (and a manual setting when one explicitly needs to modify it: update the add-ons, save a new browser setting, etc.). Using environments as much stateless as possible seems to be one of the goal pursued by Qubes team if I understand their research documents correctly, so even if it not possible right now (unless someone say it is?) I guess sooner or later it will be. I am using UNIX pass, but it has the same flaw. If you copy passwords this way they won't automatically get purged from the AppVM, which under the assumption that any AppVM is completely compromised at all times, is not much of a big deal, but still it would be nicer if the password was cleared or even better never copied to the clipboard... I think this may be a good point, maybe not of the highest priority compared to other Qubes issues, but nevertheless a good point even if from my point of view this could completely uncorrelated from your tabbed AppVM idea. What I understand from your sentence would be a feature like a keyboard shortcut which, instead of putting the content of the global clipboard into the AppVM clipboard as Ctrl+Shift-V currently does, would instead simulate the keystrokes corresponding to the current global clipboard content (a kind of macro). Besides it is incredibly annoying to operate this way. I am not some prime target of the NSA ^^, and I doubt many of the people using qubes will be... So you want to be safe, but you still want the convenience... The right way is to block the link, unless it refers to a white-listed domain for this identity. No, the right way is to propose people an option in the browser's right-click menu offering them to open this link in an untrusted VM (similar to the "Send to another VM" or "Open in a disposable VM" option in the file manager). I agree with you that, IMHO, the right-click followed by 'A', Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter "shortcut" sequence to achieve the same task currently could and should be improved in terms of usability for Qubes to reach a wider audience. Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I imagined also to happen, just in dom0 (which is more trustworthy to me), not in an AppVM. If you would like to filter URLs accessed by a browser without trusting neither the browser nor its AppVM, you may want to setup some web proxy VM between your AppVM and the Firewall VM. The same way the Firewall VM is configurable from Dom0, you could imagine that the proxy could be configurable too to define a per-AppVM white and black lists. The advantage is the same as going back to IE6 times when each tab was its own window and having windows with several tabs in addition to this madness. I don't see how you can not see the advantage of having all browser tabs over all AppVMs organized in a dom0 browser interface as tabs in comparison to having tons of floating windows with sub-tabs each ;). I suppose everyone have their own taste ;). Personally, I prefer to have windows belonging to different sensitivity levels to be clearly separated from one another. Have you looked toward tabbed windows managers? I do not know if there is anything which would suit your needs, but their idea as per my understanding is to handle several windows as tabs. This would however put two tabs layer instead of one. To be able to get one single layer of tabs, you would need to have the browser itself and its rendering engine clearly separated, so you can have the browser (with no Internet access) running in Dom0 handling different rendering engine for each tabs, each being able to run in the same or different tabs (the tab color would then help to distinguish among the AppVM as windows border colors currently do). Chrome used to rely on individual processes for each tab for a long time now, AFAIK it is still an ongoing work on Firefox due to its history (addon compatibility was a great issue). Nevertheless, even with this basis in place I suspect this would still require a huge amount of work to get such tight integration correctly done.
