Re: [qubes-users] Re: ANN: Qubes network server
On Friday, 4 November 2016 02:48:39 UTC+8, Manuel Amador (Rudd-O) wrote:
> 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/
I have tried that but I get the following error - any idea what this means?
[user@my-new-vm qubes-network-server]$ sudo make rpm
find -name '*.pyc' -o -name '*~' -print0 | xargs -0 rm -f
rm -f *.tar.gz *.rpm
DIR=qubes-network-server-`awk '/^Version:/ {print $2}'
qubes-network-server.spec` && FILENAME=$DIR.tar.gz && tar cvzf "$FILENAME"
--exclude "$FILENAME" --exclude .git --exclude .gitignore -X .gitignore
--transform="s|^|$DIR/|" --show-transformed *
qubes-network-server-0.0.4/doc/
qubes-network-server-0.0.4/doc/Setting up an SSH server.md
qubes-network-server-0.0.4/doc/Standard Qubes OS network model.png
qubes-network-server-0.0.4/doc/Qubes network server model.dia
qubes-network-server-0.0.4/doc/Standard Qubes OS network model.dia
qubes-network-server-0.0.4/doc/Qubes network server model.png
qubes-network-server-0.0.4/doc/Setting up your first server.md
qubes-network-server-0.0.4/Makefile
qubes-network-server-0.0.4/qubes-network-server.spec
qubes-network-server-0.0.4/README.md
qubes-network-server-0.0.4/src/
qubes-network-server-0.0.4/src/usr/
qubes-network-server-0.0.4/src/usr/bin/
qubes-network-server-0.0.4/src/usr/bin/qvm-static-ip
qubes-network-server-0.0.4/src/usr/lib64/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/007FortressQubesProxyVm.py
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/006FortressQubesNetVm.py
qubes-network-server-0.0.4/src/usr/lib64/python2.7/site-packages/qubes/modules/001FortressQubesVm.py
qubes-network-server-0.0.4/TODO
T=`mktemp -d` && rpmbuild --define "_topdir $T" -ta qubes-network-server-`awk
'/^Version:/ {print $2}' qubes-network-server.spec`.tar.gz || { rm -rf "$T";
exit 1; } && mv "$T"/RPMS/*/* "$T"/SRPMS/* . || { rm -rf "$T"; exit 1; } && rm
-rf "$T"
/bin/sh: rpmbuild: command not found
Makefile:13: recipe for target 'rpm' failed
make: *** [rpm] Error 1
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/9df640ab-a725-4c75-b71b-5ff1d220b747%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intrusion detection daemons in VMs
On Friday, November 4, 2016 at 8:35:14 PM UTC+11, Laszlo Zrubecz wrote: > Another - currently implementable - way to use a proxy VM (as it is > currently used as a dnf/yum proxy) and install your desired intrusion > detection software there. > Suricata is a good candidate for such thing: > https://suricata-ids.org/ If I view a malicious jpeg image on a site that drops malware onto my browsing VM, I want to know about that. Quite possible that a proxyVM would not help me here if it doesn't match some known signature. That sounds more like intrusion *prevention* than detection (though I know Suricata does both). Something like OSSEC might, however, tell me that some new file exists or existing file has changed in some unexpected way, or that a new service has started listening on a port (whether or not the Qubes firewall is blocking). The knowledge is what matters to me most. Anyway thanks - I know of many of the products out there, just was interested to hear if anyone had implemented on their Qubes in practice. Cheers -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/adeb35ce-afec-4a49-b361-809e3a9f4262%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 06:51 PM, Marek Marczykowski-Górecki wrote: > 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? Looks like we need a calibration VM! (It would be nice if these VM operations could be included in Qubes OS. You need to calibrate your display? An icon in the System submenu will walk you through it! It's totally doable with Qubes RPC — but the software needs to be written for the purpose!) -- 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/a12094cf-cd5c-fb5d-5c04-05c8c3d20599%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Your Battery is syping on you...
On 11/04/2016 08:32 PM, 198730178489710317470139 wrote: > Hello, > > good to know that Firefox and other mainstream-browser's spy-features don't > work inside the Q-VMs. > > But here are many ways to find out, who is sitting in front of the screen, > without get logged in, e.g. also keyboard-typing-patterns and mouse > movements... > > So for ebanking and free of digital dicriminating shopping I should use > Whonix? For ebanking you want to use a normal AppVM that does not have the Whonix stuff. They will fingerprint you. For shopping you want to use a separate normal AppVM that does not have the Whonix stuff. They will fingerprint you. BUT Those fingerprints will be different and so sites you visit on your shopping VM will not know about your banking habits in any way, and vice versa. For regular browsing you want to have a separate VM that has hardened settings and uses stuff like User Agent Spoofer with all the Firefox fingerprinting settings disabled (battery, gamepad, audio, WebGL, et cetera), as well as uMatrix to disable HTTP requests that you have not authorized. This VM can totally be a Whonix browser + Tor combo. I think I will post a guide for that soon enough. Just remember: Don't bank where you surf, don't shop where you bank, don't surf where you shop. -- 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/639a26e7-f6a1-5b07-2fa7-9f97f24068bb%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intrusion detection daemons in VMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-11-04 02:35, Zrubi wrote: > On 11/03/2016 11:42 PM, miguel.j...@gmail.com wrote: >> 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? > > Intrusion/virus detection inside the affected VM not really makes sense. > > However newer Xen versions has a nice feature: > https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection > > And already a real project using this feature: > https://drakvuf.com/ > > > That feature wound really make sense and would fit in Qubes philosophy > pretty nicely. > Very interesting. Tracking it here: https://github.com/QubesOS/qubes-issues/issues/2417 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYHT9WAAoJENtN07w5UDAweL8P/icYG1gXNo34oA7ajaZ+lEKC 4fw+VMBXpxQovp74kfz26mCtMfP+huguoi5klKTBe+7+/At/tMsMhe6O/Hfs8PLQ 5Ynerq0y6NdSskEThbIrxqAVGh4avlQjloEJwMtlw0Ww0Stj/B0cmocSq/WoR2BS dzf1lEyN2M9IWC7yo1ottx7EnR1LPvBoIri9yJd2z0A3VTgjlXVDbrksvipCdnj3 nHrvpRqr+5wZzrZkUqH8N2IW6eT/ErCDeR7lOBao78VXCSp+BuQCew81ATyCzlkf AH3wSHfJXWPjj27UA+OvctOaT1nBxO9wp/ZBp+vutFFMKcBMzgWHJkhDqmauYPDT Nay6qadL4xnsHlVTXni5RdxO/1gB3R3UOhCeToHh27RxSMKqvezFQ9fxZ0LuYfI1 5581UtcCgpSF9rTuWvproHnSqSHPFNdRz0lhl1JLV8dN0DEaimfaK9WmHPs5RgEI srU+AZgRVnd/mE6iQInEx4Nj940TOA2hQePfF41yPjIaynnWmZXoczUEUyXsgnd6 bsJNXdBeRZUClpC39J9MiueYINQA/5Pz2uOfy/hDuz3enEGf6BX2sHjSv0zlKZkR L9LPN/sVoxYsIdvMxUm/LezBaSfEpFGA94JsJ7eDeDRXXCBwAK9DLhYoDkFXfpiF gBNJPPXExmjP/iqrnKp2 =6yg3 -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/d4ce4c9c-df97-d7d2-c4c2-390208b22411%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On 11/02/2016 06:28 PM, Marek Marczykowski-Górecki wrote: > > > @Marek: > > Do you have any idea what to look for in order to be able to calibrate > > my screen under Qubes? > > I have no idea how such software works... Especially at which stage > calibration is applied. Is it something that application does > "internally", or adjust display driver options? I believe it tweaks the gamma of the X server? -- 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/cc1c4576-004e-195c-5ddf-a5534b659053%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Your Battery is syping on you...
On 11/02/2016 09:49 PM, '109384'019834'09128'340932189 wrote: > Hello, > > in Q the Firefox battery fingerprinting is enabled. > > https://blog.lukaszolejnik.com/battery-status-readout-as-a-privacy-risk/ > > Manual you might disable it: > > 1. start Firefox > 2. open the URL about:config > 3. scroll down to dom.battery.enabled and disable this feature > > It would be nice if the DispVM has running a Firefox, which don't support the > fingerprinting (or even better, a real secure-browser...) Battery access to the system battery is disallowed because the DispVM / AppVM does not have access to the hardware. -- 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/dddc3ce5-3b7b-c038-23ad-ba9e34fbeb4d%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Trying to do an in-place upgrade from 3.1.17 to 3.2
Hi Marek, On Sat, Nov 05, 2016 at 01:57:44AM +0100, Marek Marczykowski-Górecki wrote: > > I believe I also found a workaround: > > sudo qubes-dom0-update enablerepo=qubes-dom0-current-testing > > --releasever=3.2 qubes-release > > sudo qubes-dom0-update enablerepo=qubes-dom0-current --releasever=3.2 does that make sense? > What exactly do you mean? Some X server startup error? Do you have any > logs? X crashed or the system shut down. (It was late at night and due to other hardware problems (using external monitor which at this moment I didnt use anymore since an hour) I had experienced many unexpected sudden poweroffs before so I dont really recall whether just X crashed or the hw…) > What exactly do you get when trying to start sys-net and sys-firewall > from shell? `qvm-start sys-firewall` should work just fine from text > console. Of course you'll not get GUI there, but qvm-run should work. ERROR: ERROR: Failed to connect to qmemman: [Errno 2] No such file or directory > > p.s./btw: https://www.qubes-os.org/doc/upgrade-to-r3.1/ advices one to > > install qubes-mgmt-salt-admin-tools but this package does not exist?! > That's interesting, this step should be in 3.1->3.2 instruction... ah. so I guess I should send a patch for qubes-doc tomorrow… (gn8 ;) -- cheers, Holger -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161105011625.GC16942%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [qubes-users] Re: Trying to do an in-place upgrade from 3.1.17 to 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Nov 05, 2016 at 12:50:56AM +, Holger Levsen wrote: > Hi, > > On Wed, Nov 02, 2016 at 08:26:18AM -0700, Richard wrote: > > On Sunday, October 30, 2016 at 12:00:08 PM UTC-5, Richard wrote: > > > I'm trying to upgrade my Qubes 3.1.17 to 3.2 I've followed the steps > > > outlined here: https://www.qubes-os.org/doc/upgrade-to-r3.2/ However, > > > when I run... > > > > > >sudo qubes-dom0-update --releasever=3.2 qubes-release > > > > > > I receive: > > > Loaded plugins: yum-qubes-hooks > > > Nothing to do > > > No packages downloaded > > > file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] > > > curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml" > > > Trying other mirror. > > > Nothing to do > > > > > > So of course running... sudo qubes-dom0-update --clean also provides a > > > similar error: > > > > > > Errno 14] curl#7 - "Failed to connect to pubmirror1.math.uh.edu > > > port 443: No route to host" > > > Trying other mirror. > > > No new updates available > > > No updates avaliable > > > > > > Is anybody able to advise me what I need to do to be able to do an > > > in-place upgrade to 3.2? > > I stumbled upon the issue, when upgrading a 3.0 system to 3.1 and then > to 3.2 - did you do the same? > > I believe I also found a workaround: > > sudo qubes-dom0-update enablerepo=qubes-dom0-current-testing > --releasever=3.2 qubes-release > sudo qubes-dom0-update enablerepo=qubes-dom0-current --releasever=3.2 > > but then sadly my system crashed during the upgrade (not sure whether > this was hardware fault or bad software which didnt cope with me using > qubes-manager during the dom0 upgrade) and now I'm stuck between 3.1 > and 3.2 and the UI doesnt work anymore, What exactly do you mean? Some X server startup error? Do you have any logs? > so I cannot finish the upgrade > of dom0, as I also could't start sys-net and sys-firewall > manually on the shell :/ > > (yum-complete-transaction also didnt help, I thought all the packages > were downloaded already and this was supposed to work?) > > What way is there to recover the system now? What exactly do you get when trying to start sys-net and sys-firewall from shell? `qvm-start sys-firewall` should work just fine from text console. Of course you'll not get GUI there, but qvm-run should work. > (The system is just a test system, so I could and probably soon will > just reinstall, and I know I could copy the VMs over… but… I'm curious > how to bring this installation back to life… :) > p.s./btw: https://www.qubes-os.org/doc/upgrade-to-r3.1/ advices one to > install qubes-mgmt-salt-admin-tools but this package does not exist?! That's interesting, this step should be in 3.1->3.2 instruction... - -- 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 iQEcBAEBCAAGBQJYHS6LAAoJENuP0xzK19csTEgH/2w4hSi+nU6eWvothb6aP1wJ J9uRvrYMufZFVfZcZqx/+1AUC7VGqnTrmT8MKuWz3TWopRx9UFbAaDH6YIsJf63T yTs0UK1GM2r9wx0Nf2Ua6/V13IEE7LrVmwmss6cB5GGErYJ6Ge27KmuTV5xE7W4R aMvFb7dOHaaucLq+ft8JTKmTWDi5xC8PJrA7kyniIp069xuuHYEcJbdK3/CGOXrh dK9z/p9yxZMjQO6zIlIavUtlHiZqbmEA5G8YSff0It2ZN7iCahycyj46bRwKkvJv lUfVuPgJqcLIKOL21Mq+c8DdpM4xupt+GtdHJVDLc5hOx//pbbqwM2AES8uZG64= =w64B -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/20161105005744.GD7073%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Trying to do an in-place upgrade from 3.1.17 to 3.2
Hi, On Wed, Nov 02, 2016 at 08:26:18AM -0700, Richard wrote: > On Sunday, October 30, 2016 at 12:00:08 PM UTC-5, Richard wrote: > > I'm trying to upgrade my Qubes 3.1.17 to 3.2 I've followed the steps > > outlined here: https://www.qubes-os.org/doc/upgrade-to-r3.2/ However, when > > I run... > > > >sudo qubes-dom0-update --releasever=3.2 qubes-release > > > > I receive: > > Loaded plugins: yum-qubes-hooks > > Nothing to do > > No packages downloaded > > file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] > > curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml" > > Trying other mirror. > > Nothing to do > > > > So of course running... sudo qubes-dom0-update --clean also provides a > > similar error: > > > > Errno 14] curl#7 - "Failed to connect to pubmirror1.math.uh.edu port > > 443: No route to host" > > Trying other mirror. > > No new updates available > > No updates avaliable > > > > Is anybody able to advise me what I need to do to be able to do an in-place > > upgrade to 3.2? I stumbled upon the issue, when upgrading a 3.0 system to 3.1 and then to 3.2 - did you do the same? I believe I also found a workaround: sudo qubes-dom0-update enablerepo=qubes-dom0-current-testing --releasever=3.2 qubes-release sudo qubes-dom0-update enablerepo=qubes-dom0-current --releasever=3.2 but then sadly my system crashed during the upgrade (not sure whether this was hardware fault or bad software which didnt cope with me using qubes-manager during the dom0 upgrade) and now I'm stuck between 3.1 and 3.2 and the UI doesnt work anymore, so I cannot finish the upgrade of dom0, as I also could't start sys-net and sys-firewall manually on the shell :/ (yum-complete-transaction also didnt help, I thought all the packages were downloaded already and this was supposed to work?) What way is there to recover the system now? (The system is just a test system, so I could and probably soon will just reinstall, and I know I could copy the VMs over… but… I'm curious how to bring this installation back to life… :) -- cheers, Holger p.s./btw: https://www.qubes-os.org/doc/upgrade-to-r3.1/ advices one to install qubes-mgmt-salt-admin-tools but this package does not exist?! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161105005056.GA13569%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On Friday, 28 October 2016 12:19:56 UTC+1, Laszlo Zrubecz wrote: > Can you please describe in more details what and how you achieved? > Found this in bash history backup: dispcal -H -y l -R (this is to adjust the brightness to the recommended level) dispcal -v -m -y l -q l -t 6500 -g 2.2 lenovo_6500_22 (this creates the calibration file with selected quality, white point and gamma. inspect the file, transfer it to dom0 and apply with dispwin .cal ) targen -v -d 3 -G -f 128 lenovo_6500_22 (creates a set of patches,you can change the number of patches) dispread -v -N -H -y l -k lenovo_6500_22.cal lenovo_6500_22 (shows patches and measures them) colprof -v -D "Lenovo Yoga 2 40% 6500K 2.2" -C "2016 CP" -q m -a G -n c lenovo_6500_22 (generates an ICC profile, try that, see if you need to tweak settings to improve it) The Gnome calibration tool uses the same utilities as above but it doesn't know that the calibration curves don't get applied in a vm. It should work in dom0 with direct access to USB and X server though. In any case don't forget to apply the calibration file in dom0! Hope this helps. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f74cf4fc-a77c-4511-adcc-232b42339100%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Your Battery is syping on you...
Hello, good to know that Firefox and other mainstream-browser's spy-features don't work inside the Q-VMs. But here are many ways to find out, who is sitting in front of the screen, without get logged in, e.g. also keyboard-typing-patterns and mouse movements... So for ebanking and free of digital dicriminating shopping I should use Whonix? And must I run the Tor network in the background, or can I use Whonix also just as the Qubes Secure Browser? The browser is normally the direct interface to the network, so there might be many reasons, why some organisations have a huge interesst to get this pice of software under their control - instead that you control your laptop (& software). Today there are many "Secure Browser", e.g. like Kaspersky on the market and every browser claims to be more secure than the competitor (on another definition of security in the background). For eBanking it would be a nice solution, if the bank offers a digital counter behind the first banking firewall and you can reach this terminal via an screensharing from a safe endpoint and the screensharing has some embedded authentification and strong enryption in place. But 2016 this sounds like science fiction. So I thought some good robust Secure Browser, which by the way only need some basic navigation (videos are here not in the scope) and could be more slim and robust than any mainstream browser. Thanks and 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/5bd4faae-a264-459f-86d6-da6150d601e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XScreenSaver for dom0 pops up
On Thursday, November 3, 2016 at 12:50:13 AM UTC-4, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2016-11-02 08:56, John Maher wrote: > > On Thursday, October 27, 2016 at 12:42:18 AM UTC-4, Andrew David Wong wrote: > > On 2016-10-26 15:53, Gaijin wrote: > On 2016-10-26 13:38, John Maher wrote: > > On Wednesday, October 26, 2016 at 9:05:48 AM UTC-4, Gaijin wrote: > >> On 2016-10-26 12:43, John Maher wrote: > >>> I'm getting the strangest thing on my screen. I'll be working and the > >>> XScreenSaver dialog pops up (indicating the screen is locked) and the > >>> screen goes black. However, the screen is not locked. I have to move a > >>> window around to redraw my screen. This has always happened since I > >>> started using Qubes about 3 weeks ago. There appears to be no pattern > >>> that prompts this response. Bizarre! Any thoughts? > >>> > >>> Thanks. > >>> > >>> John > >> > >> Yeah. I had the same thing happen when I upgraded to R3.2 as well. I > >> asked the same thing but nobody replied. > >> https://groups.google.com/forum/#!topic/qubes-users/xjHi2TcYBAQ > >> > >> It still happens from time to time. Seems to happen less if I have a > >> lot > >> of free memory. Closing down some memory hungry AppVMs seems to lessen > >> it, but I haven't been able to specifically replicate it. > > > > Interesting, because I think I have more than enough memory (32 GB). > > Thanks. > > I've got 16GB myself. It's not that the memory is full, but it seems to > happen more when I have a lot of VMs open in one desktop. That may just > be a coincidence though. > > I'm glad to see it wasn't just me though. I never had this happen with > earlier versions of Qubes on the same hardware. Not sure if it might be > the XFCE or a video driver issue. (I've never installed the nVidia > drivers.) > > > > > Thank you both for reporting this. Gaijin, I'm sorry I missed your thread. > > > > Just to confirm: Are you both using Xfce4? > > > > Tracking the issue here: > > > > https://github.com/QubesOS/qubes-issues/issues/2399 > > > > > > Sorry for the delay in responding. I used the default install for 3.2. > > > > I also just noticed that it appears that memory is not being purged when > > apps are closed. Today when I "woke up" the screen from one of these odd > > screen saver like issues, it very briefly displayed a browser window with a > > site I was on yesterday. I looked carefully and confirmed that I did not > > actually have that window open on my system. It's as if something from > > yesterday's memory was sent to the screen and then closed. Rather > > disconcerting. > > > > John > > > > I don't think that should necessarily be disconcerting. The Qubes security > model does not include or rely upon purging memory at any particular time > interval. It assumes that you, the authentic single user, should be the only > one with access to dom0's screen content. So, the fact that you're allowed to > see your screen content from yesterday doesn't constitute any violation of > the security model. You're still the same trusted user as you were yesterday. > (If I've misunderstood your concern, please let me know.) > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJYGsH3AAoJENtN07w5UDAwKtIP/2vblyc4Rf9uwU3M+WGv2K7V > T7VoTDfGjB8XWyX6LZW/TrtameFmAj/Rb0bINOrIWpkrP9RdNUm+0/BR10NkcLul > FqaxMOcl2u2Tk775VjYtC+Z7y1ycJDQjaMvtqrdDQkeGhMumzcDOHD9RufTFSIRm > 8ke7GxfMQBH7R0DJ5E26B7HZJg73k1RKFT5BbpmKrfHxBBEaJTUALeNFZnp2ekl+ > HrRV4u8+T/Tbwzha5e/iTvJEVTMcMxzD4uziaN+TfiK2Iwp40w0W8IdmRjPzdkLI > +PDhAfjpQCEcZIPT/V+u6GsMhUDJo5ABPs/as17YY4b8VMwm9F7/J2Oo6nfwl/Rh > gOnwVLFQKUtq3iaNbORDzAjBSEny6wYKlfvpL3IWGAHhH0mbP5j1ivSJoF+navuD > qPMvMyAuhFh7hSsTPJ0CTMrDZYTGVlSryLrvXUwl5Lf6zplXRxO6uGu3ruUnepxR > 9izVXApPBv/Cc41G3wrCUGN3deE1OpzNSxhQS+NK4B3kJSGAm4+Zi/F/B8yiR6Lt > L/DiLI04X1LZ/XW+ZrKKiQbqVKAzeDqkDPW1D4POEckQnEfPqMcc32LzQVf6ORvX > Xzjn+UhUcdTzINAuISwYeBdvBTk6Wk80T80nChZJdnSdWi6klvbcof96UNdD3sja > swBLAb3aU4hobRxFAcL7 > =Fv0E > -END PGP SIGNATURE- If the memory that temporarily renders to the screen is as isolated from other appvms as expected rendered content (like an open windows), then, yes, I'm not concerned about leakage from one environment to another. I will say that it is simply disconcerting to see it display, security implications aside. More important to me, though, is the hope that this "screen saver" triggering will go away on future updates. Let me know if there is anything I can do to help that process. John -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroup
Re: [qubes-users] Intrusion detection daemons in VMs
On 11/04/2016 09:35 AM, Zrubi wrote: On 11/03/2016 11:42 PM, miguel.j...@gmail.com wrote: 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? Intrusion/virus detection inside the affected VM not really makes sense. Please consider a mail client/VM. Something could get into the user space extensions and simply monitor mail while gathering account information - working temporarily while hoping that the infection would be saved and re-used in future sessions (an argument for never using mail client internal browsers, and for always running WAN-apps in DispVMs) However newer Xen versions has a nice feature: https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection And already a real project using this feature: https://drakvuf.com/ That feature wound really make sense and would fit in Qubes philosophy pretty nicely. Another - currently implementable - way to use a proxy VM (as it is currently used as a dnf/yum proxy) and install your desired intrusion detection software there. Suricata is a good candidate for such thing: https://suricata-ids.org/ (I would just need more time and more RAM to play with such things ;) Yet another possibility is using Grsecurity RBAC. "Train" your VM RBAC rules for normal operation for a day, then turn on enforcing mode and block/flag any system or user actions that are exceptional. (RBAC can easily be programmed to allow access only to specific, authorized net addresses - perhaps easier than devising an iptables-adjusting script) This RBAC protection is an optional part of the standard kernel hardening patch. IIRC other kernel hardening software have something similar to RBAC. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87c1dc02-5d24-537c-4d5c-5e916f7e223e%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On Friday, 28 October 2016 12:19:56 UTC+1, Laszlo Zrubecz wrote:
> On 09/03/2016 12:49 AM, Connor Page wrote:
> > I have calibrated my yellow screen using argyllcms.
> > I don't attach usb devices to dom0 so installed it in sys-usb as well.
> > used
> > https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/
> > as a rough guide.
> > to get the calibration done you just need to run dispcal and then transfer
> > the calibration file to dom0.
> > then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart
> > item with that command (probably,
> > using the full path to the calibration file) and you're done.
>
> I just started to experiment with display color correction things.
>
> I wonder how it is workig in Qubes because as far as i know:
>
> - the display profile is used only the programs are aware of icc profiles.
Some window managers do this too.
>
> - the X server runs in dom0, the apps are in AppVMs - but no
> communication about display prifiles (colord) because of the qubes gui
> protocol.
True. There's even no display object to have profile attributes, so colord is
useless.
>
> > I went further and created an icc profile for use in firefox and photo
> > software.
> If no colord is runnin in an appvm, how they apply your prifile then?
> You just manually configure all of the icc profile aware apps??
>
Yes and no. ICC profiles consist of two parts, vcgt and colour correction. vcgt
is used by X server to set gamma and white point. it can be produced separately
("calibration file"), and loaded by dispwin in dom0. this corrects tint and
sets midtones as you need them (gamma).
when calibration is working then you can create a colour correction matrix for
the specific rendering intent you're going to use in icc aware applications.
that matrix can be saved as an icc profile for vms and manually selected in
apps. that profile should be used only with the calibration file that was
loaded when creating the icc profile. as I use only one display and at a
specific brightness setting then there's no need to change settings anymore.
when re-calibration is due then files can just be overwritten with new ones.
>
> Can you please describe in more details what and how you achieved?
follow the guide I referenced above and remember to transfer the calibration
file to dom0 and apply it there before proceeding. the settings in the guide
are rather crude but for a first pass they're ok. if it works for you then you
can try higher quality settings.
>
> Thanks.
>
>
> --
> 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/f0182eb7-7313-41c7-b8f2-6ba898d63efd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/04/2016 10:59 AM, Simon wrote: > Hi Alex, > > Alex wrote : >> On 11/03/2016 11:37 AM, Simon wrote: 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 ;) >> > > Do you mean that KeepassX auto-type feature works in a cross-AppVM > way? No, it does not - it works this way by design, which is not specifically made for Qubes but for any windowing gui environment (also windows, osx). So you can use auto-type inside a single AppVM (where you have both keepassx and your browser), but you cannot use it cross-appVM because of Qubes' window content redirection. I don't know exactly how it works on linux, but I think it just sends window messages, so it works on the local X windows inside an AppVM, but it will not automatically do anything qubes-related. > The only way it should be possible would be to store Keepass(X)'s > database alongside with the browser, but in this case I see no > substantial benefits over using the browser's own password management > DB (unless we are talking about an application without similar > feature, like handling SSH password for instance). I do use it for other applications, so I like to have it all centralized and easily portable/syncable without having a bunch of text files. Like I said in an earlier e-mail, I also like the increased practical security with respect to browser-kept credentials - it surely is not much of a protection, since owning the browser you can reach local files/programs, but it just makes this difficult and hardly applicable to everybody. The reasoning is, if you develop an exploit to gather all passwords kept by Firefox or Chrome, it may just be some javascript exploit. If you get to run arbitrary code as the tab user it often gets much more complicated; you are more likely to stop at gathering passwords kept in the internal DB rather than go full-nuclear on trying to access every password keeper that may be installed, in any version that may exist, to convince it in giving you all of the passwords. Database files from password keepers are usually encrypted, so the browser exploit can't just copy any *kdbx file it finds... That's what I mean by saying "it's not secure, it's just much more unlikely as an attack". > [...] > What I'm talking here is about a user-friendly way to open an > untrusted link from a sensitive AppVM into an untrusted AppVM, this > should actually not involve the clipboard at all but be a simple, > classical right-click operation. This indeed seems a nice idea. I can see the problem in implementing that; the interfaces for opening an URL are all but standard, sadly :( something like Android's Intent system, ported to a desktop OS, would provide a single tapping point to intercept the action (and, in our case, ask the user "do you want to open that in a dispVM?") > I do not think there is really any risk of wrong manipulation here: > personally I do not remember having mistakenly right-clicked on a > file and opened it in a disposable VM or sent it to another VM when I > just wanted to open it locally using a simple left-click. I agree. >>> 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. > > From my understanding, there is actually two level of correlation > when you want to convict someone: > > 1) You demonstrate that it was the same machine which was used for > all incriminated actions. 2) You demonstrate the link between the > suspect and the machine. > > In your statement, for n incriminated actions, you would need to > demonstrate n times the involvement of the suspect which can be very > hard, if not impossible. > > It is far easier to demonstrate that the same computer has been used > for all of the n incriminated actions (either actively by putting > some tracking bug on it or passively by correlating various > information for instance), no matt
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Alex, Alex wrote : On 11/03/2016 11:37 AM, Simon wrote: 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 ;) Do you mean that KeepassX auto-type feature works in a cross-AppVM way? In one dedicated, networkless AppVM I have Keepass (sadly started some time ago with the new DB version which, AFAIK, is still not supported by KeepassX :( ), in another network-enabled AppVM I have the browser (or any other software for that matters). As per my understanding there is no way for the Keepass(X) software to emulate keystrokes on the browser's interface, unless I missed something very important in Qubes' architecture. The only way it should be possible would be to store Keepass(X)'s database alongside with the browser, but in this case I see no substantial benefits over using the browser's own password management DB (unless we are talking about an application without similar feature, like handling SSH password for instance). 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. I'm not talking about clipboard sharing by itself, which I also consider to be good as it is now (unless maybe the minor fact that it overwrites the default common shortcut to paste something in a terminal, but that's really not big deal). What I'm talking here is about a user-friendly way to open an untrusted link from a sensitive AppVM into an untrusted AppVM, this should actually not involve the clipboard at all but be a simple, classical right-click operation. I do not think there is really any risk of wrong manipulation here: personally I do not remember having mistakenly right-clicked on a file and opened it in a disposable VM or sent it to another VM when I just wanted to open it locally using a simple left-click. The only real risk of wrong manipulation is to directly open the untrusted link in the sensitive VM. The current situation does not help against that, actually it even encourage to do such wrong practice by making it more difficult to open a link in a different AppVM. 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". Thank you for this confirmation. I never used such windows manager myself, but this was indeed my assumption. I hope Mara will have the opportunity to check this :) ! 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, airp
Re: [qubes-users] Intrusion detection daemons in VMs
On 11/03/2016 11:42 PM, miguel.j...@gmail.com wrote: > 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? Intrusion/virus detection inside the affected VM not really makes sense. However newer Xen versions has a nice feature: https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection And already a real project using this feature: https://drakvuf.com/ That feature wound really make sense and would fit in Qubes philosophy pretty nicely. Another - currently implementable - way to use a proxy VM (as it is currently used as a dnf/yum proxy) and install your desired intrusion detection software there. Suricata is a good candidate for such thing: https://suricata-ids.org/ (I would just need more time and more RAM to play with such things ;) -- 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/890bc090-fc22-9d91-b8bc-a8f55b1fa665%40zrubi.hu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?
On 11/03/2016 07:51 PM, Marek Marczykowski-Górecki wrote: > 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? Theoretically yes, setting up those things manually should be enough - but the actual software simply not designed to this case. > 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... Just found out that some test during an 'accurate' (long) calibration process do want to modify (apply the half baked profile) driver settings and checking the results, then make modification and checking it again. Doing this till find the best results. So calibrating from a Qubes AppVM seems to be a dead end. (but I still in a hope for a calibrated display - it is really needed if you want to work on photographs - like I do) Already tried to lower the security bar and attached the device to dom0, and run the calibration there. The software is running fine, however applying the resulted (or any other pre definde/test) profile seems not working as expected. (no effect seen) Work in progress in this part -- 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/3143c292-5973-5307-1b91-697255f94652%40zrubi.hu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
