[qubes-users] Skype Package Installation Issue
I've installed the Skype .dpm package and installed it using dnf install ./..dpm. The installation completed without errors. However, I don't see skype listed in the AppVm's list of available shortcuts or within the installed software app. I've also tried installing Skype on a Debian template with the same result. How do I go about launching the Skype application post install? The Skype web application has no option available for Web calls. The section is greyed out, despite the webcam being loaded on the AppVm and accessable by Cheese. Any help is appreciated. It's been an interesting process. This being the last step for a functional OS. Thanks!! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAB%3D4r5M0ga6cU8BWKA8veYmi1fq%2BudK0R9g%3DRyT6k7vzPDSEGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Scanner use in VM
On Monday, April 10, 2017 at 9:22:47 PM UTC-4, Daniel Acevedo wrote: > I only see my scanner in dom0, using this command: > > # lsusb | grep Canon > > Bus 001 Device 005: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110 > > Of course it doesn't appear in the VMs. > > I know I should assign the USB device where the scanner is plugged to > the VM where I'm going to use it. The problem is that I don't know > which USB Hub I should select (I have 3 different ones) and I'm afraid > of making the wrong move and losing mouse and keyboard control in > Qubes, forcing me to reinstall everything from scratch. > > Any tips would be appreciated. > > Thaks in advance, > Daniel You may be looking for qvm-usb. Run in dom0 with no arguments. The first column is the device name that you supply next to "qvm-usb -a $VM $DEVICE". PS even if you made a mistake and lost mouse and keyboard, couldn't you power cycle and get them back? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ef7aaa22-f465-40da-bda4-cf99fb3f8690%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Scanner use in VM
I only see my scanner in dom0, using this command: # lsusb | grep Canon Bus 001 Device 005: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110 Of course it doesn't appear in the VMs. I know I should assign the USB device where the scanner is plugged to the VM where I'm going to use it. The problem is that I don't know which USB Hub I should select (I have 3 different ones) and I'm afraid of making the wrong move and losing mouse and keyboard control in Qubes, forcing me to reinstall everything from scratch. Any tips would be appreciated. Thaks in advance, Daniel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170410222021.11568ef5%40zoho.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On Mon, Apr 10, 2017 at 03:39:26PM -0400, Chris Laprise wrote: > On 04/10/2017 03:17 PM, Chris Laprise wrote: > >On 04/10/2017 02:55 PM, Reg Tiangha wrote: > > > >I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and > >re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty > >much the only persistent thing left would be contents of /rw/home, which > >is sort of a middle of the road between fully persistent /rw and using > >dispVMs for everything. > > > > > >> > >>I'm definitely going to apply your scripts to my TemplateVMs soon now > >>that I've been made aware, but I wish there were a way to turn off > >>persistent /usr/local and to make AppVMs use the TemplateVM's version > >>instead. I don't use the feature, so I would prefer that /usr/local gets > >>wiped every time like everything else in the root file system since > >>that's the behaviour I expected to happen when I first started using > >>Qubes (I only discovered for myself that it wasn't the case when I was > >>trying to figure out why a custom-compiled version of Wine that I had > >>made and installed in my TemplateVM wasn't showing up in my AppVM; its > >>default prefix is /usr/local, which is why). Is there a way to turn off > >>persistent /usr/local? Or is it something that's baked-in? > > BTW, /usr/local == /rw/usrlocal. Its a symlink. > And it's set in the template - so if you don't want it open the template, remove the symlink and move /usr/local.orig to /usr/local. Then qubes based on that template wont have persistent /usr/local. NB this will break torVMs and maybe other features of your Qubes. An alternative approach would be to run tripwire against persistent directories and monitor changes. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170410215422.GA9202%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
qubenix: > Andrew David Wong: >> On 2017-04-09 15:25, Joonas Lehtonen wrote: >>> Hi, >> >>> if you setup MAC randomization via network manager in a debian 9 >>> template as described here: >>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >>> you still leak your hostname. >> >>> Once your MAC address is randomized you might also want to prevent the >>> disclosure of your netvm's hostname to the network, since "sys-net" >>> might be a unique hostname (that links all your random MAC addresses and >>> the fact that you likely use qubes). >> >>> To prevent the hostname leak via DHCP option (12): >>> - start the debian 9 template >>> - open the file /etc/dhcpd/dhclient.conf >>> - in line number 15 you should see "send host-name = gethostname();" >>> - comment (add "#" at the beginning) or remove that line and store the file >>> - reboot your netvm >> >>> I tested the change via inspecting dhcp requests and can confirm that >>> the hostname is no longer included in dhcp requests. >> >> >> Thanks. Added as a comment: >> >> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 >> >> > > Nice. I was just thinking about this after spending some time on my > routers interface. Thanks for the post! > After testing this, 'sys-net' still shows up on my router interface. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e43a76ea-eba3-9aba-f127-eec495a7fcee%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Persistent /usr/local: Are there risks?
On Monday, April 10, 2017 at 2:55:42 PM UTC-4, Reg Tiangha wrote: > On 04/10/2017 12:41 PM, Chris Laprise wrote: > > > > Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) > > requires privilege escalation. If sudo has no auth process, then there > > is no challenge for the attacker... they can change /rw/usrlocal in > > any case. > > > > But also, they can change /rw/config including rc.local and firewall > > scripts which run as root! > > > > BTW, my "better question" above really referred to the non-home areas > > of /rw. > > > > Ah, got it. Well, that's something, I suppose. > > >> > >> While my versions do exactly what you would expect them to do, the > >> difference is that each time you launch one of my versions, it starts up > >> a key logging service (no root required!) in the background that > >> persists even after you close the app that launched it. So for that > >> entire session (assuming that AppVM is connected to the Internet), I can > >> capture all of your keystrokes. And because /usr/local is persistent and > >> you probably don't constantly check /usr/local for changes (because > >> again, you're not paranoid), those programs will stick around and launch > >> the next time you access the VM. > > > > But this is a problem for things like ~/.bashrc as well. Using PATH= > > or alias, attacker could divert you to a phony `git` command that logs > > your github password before executing the intended operation. > > > > That's why I suggest people consider enabling sudo auth and securing > > shell init scripts in /home (see my post "Protect AppVM init startup > > scripts"). You could even have an in-template startup script that > > resets most of /rw (root-owner bits) to defaults really shouldn't > > be hard. > > > > In that case, your attack scenario hinges on having a Linux escalation > > exploit, and even then it might not last long enough for you to > > collect valuable info (e.g. resets or updates occur that patch the > > vulnerability). > > > > > > Still, though, let's say such Linux escalation exploit exists and a > malicious person can access the AppVM's (let's set aside TemplateVMs for > a moment) file system. They can't stick anything in most places in / > because they'll disappear when the VM shuts down. Changes in /home/user > could work, but because users interact with /home on a daily basis > through shells or file browsers, the likelihood of them noticing changes > there might be a bit higher so that might not be the smartest move. But > how many here on this list regularly check their app/sys VMs for > modifications to /usr/local? I'm doubting it's very many, and that I > guess is my main concern. > > Some people may not even be aware that it *is* persistent, so people who > use something like Whonix who've been targeted might even have stuff > living in /usr/local right now and may not even know it (since privilege > escalation exploits in tor-browser seem to be found every so often). > > I'm definitely going to apply your scripts to my TemplateVMs soon now > that I've been made aware, but I wish there were a way to turn off > persistent /usr/local and to make AppVMs use the TemplateVM's version > instead. I don't use the feature, so I would prefer that /usr/local gets > wiped every time like everything else in the root file system since > that's the behaviour I expected to happen when I first started using > Qubes (I only discovered for myself that it wasn't the case when I was > trying to figure out why a custom-compiled version of Wine that I had > made and installed in my TemplateVM wasn't showing up in my AppVM; its > default prefix is /usr/local, which is why). Is there a way to turn off > persistent /usr/local? Or is it something that's baked-in? absolutely! great discussion! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3cfb5ea6-a88a-44f4-a364-a7d19b34e22e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
Andrew David Wong: > On 2017-04-09 15:25, Joonas Lehtonen wrote: >> Hi, > >> if you setup MAC randomization via network manager in a debian 9 >> template as described here: >> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >> you still leak your hostname. > >> Once your MAC address is randomized you might also want to prevent the >> disclosure of your netvm's hostname to the network, since "sys-net" >> might be a unique hostname (that links all your random MAC addresses and >> the fact that you likely use qubes). > >> To prevent the hostname leak via DHCP option (12): >> - start the debian 9 template >> - open the file /etc/dhcpd/dhclient.conf >> - in line number 15 you should see "send host-name = gethostname();" >> - comment (add "#" at the beginning) or remove that line and store the file >> - reboot your netvm > >> I tested the change via inspecting dhcp requests and can confirm that >> the hostname is no longer included in dhcp requests. > > > Thanks. Added as a comment: > > https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 > > Nice. I was just thinking about this after spending some time on my routers interface. Thanks for the post! -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/913fb528-2469-976e-4e2c-2c276864727c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 03:17 PM, Chris Laprise wrote: On 04/10/2017 02:55 PM, Reg Tiangha wrote: I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty much the only persistent thing left would be contents of /rw/home, which is sort of a middle of the road between fully persistent /rw and using dispVMs for everything. I'm definitely going to apply your scripts to my TemplateVMs soon now that I've been made aware, but I wish there were a way to turn off persistent /usr/local and to make AppVMs use the TemplateVM's version instead. I don't use the feature, so I would prefer that /usr/local gets wiped every time like everything else in the root file system since that's the behaviour I expected to happen when I first started using Qubes (I only discovered for myself that it wasn't the case when I was trying to figure out why a custom-compiled version of Wine that I had made and installed in my TemplateVM wasn't showing up in my AppVM; its default prefix is /usr/local, which is why). Is there a way to turn off persistent /usr/local? Or is it something that's baked-in? BTW, /usr/local == /rw/usrlocal. Its a symlink. -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e66a09ce-41dc-4993-7d3f-74fac990f000%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
On Sunday, April 9, 2017 at 8:49:47 PM UTC+2, Jean-Philippe Ouellet wrote: > On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták > <…@v6ak.com> > wrote: > > > > * DDC (PIN 15+16) – needed for getting the resolution etc., present even in > > current version of VGA. While there is some attack surface, it seems to be > > rather small. > > Note that this is not strictly necessary for things to work though. For VGA, it seems to be clearly true, as DDC was added some time after initial VGA release. But I am not sure if the same applies to HDMI or even for DVI. They don't seem to be designed to work without DDC. Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7b60fde6-00f6-47fa-b8af-af72ae4bac30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
> what about vga or dvi wires? Frankly, my main interest is HDMI. But I have briefly looked at VGA and DVI pinouts. It seems that the only input channels are hotplug (if you count this) and DDC (for resolutions etc.). Plus older VGA seems to have some pre-DDC mechanism called “Monitor ID”. For VGA, you can see scheme http://pinouts.ru/Video/VGA15_pinout.shtml . The “Dir” column is helpful, though it seems to be incorrect at line “I2C bidirectional data line”. > Qubes already ignores hdmi sound driver in my case lol. Well, I am not sure if this is intentional, but I don't think so. > Because really how can we even trust its hardware, its another separate pc > outside of qubes. Well, you do trust you hardware at some degree. Without trusted HW, you cannot trust it runs the SW properly and it does not spy you in other means, e.g., by sending screen content somewhere. Malware in a compromised digital TV could do so and neither Qubes nor cut wires can prevent it. But maybe you decide to trust the TV just partially (e.g., public presentation), so you don't read top-secret messages etc. here. > Same goes for printers if you using it, you already giving up some privacy > regardless of Qubes. Mostly true, but a bit vague. But the situation is the same as with monitors – choose your level of trust and then behave accordingly. Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/63c386f1-6e09-430e-bf4a-541d4d59abee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 02:55 PM, Reg Tiangha wrote: On 04/10/2017 12:41 PM, Chris Laprise wrote: Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) requires privilege escalation. If sudo has no auth process, then there is no challenge for the attacker... they can change /rw/usrlocal in any case. But also, they can change /rw/config including rc.local and firewall scripts which run as root! BTW, my "better question" above really referred to the non-home areas of /rw. Ah, got it. Well, that's something, I suppose. While my versions do exactly what you would expect them to do, the difference is that each time you launch one of my versions, it starts up a key logging service (no root required!) in the background that persists even after you close the app that launched it. So for that entire session (assuming that AppVM is connected to the Internet), I can capture all of your keystrokes. And because /usr/local is persistent and you probably don't constantly check /usr/local for changes (because again, you're not paranoid), those programs will stick around and launch the next time you access the VM. But this is a problem for things like ~/.bashrc as well. Using PATH= or alias, attacker could divert you to a phony `git` command that logs your github password before executing the intended operation. That's why I suggest people consider enabling sudo auth and securing shell init scripts in /home (see my post "Protect AppVM init startup scripts"). You could even have an in-template startup script that resets most of /rw (root-owner bits) to defaults really shouldn't be hard. In that case, your attack scenario hinges on having a Linux escalation exploit, and even then it might not last long enough for you to collect valuable info (e.g. resets or updates occur that patch the vulnerability). Still, though, let's say such Linux escalation exploit exists and a malicious person can access the AppVM's (let's set aside TemplateVMs for a moment) file system. They can't stick anything in most places in / because they'll disappear when the VM shuts down. Changes in /home/user could work, but because users interact with /home on a daily basis through shells or file browsers, the likelihood of them noticing changes there might be a bit higher so that might not be the smartest move. But how many here on this list regularly check their app/sys VMs for modifications to /usr/local? I'm doubting it's very many, and that I guess is my main concern. Some people may not even be aware that it *is* persistent, so people who use something like Whonix who've been targeted might even have stuff living in /usr/local right now and may not even know it (since privilege escalation exploits in tor-browser seem to be found every so often). Some people, maybe. But also notice more than a couple of Qubes users prefer to use dispVMs for most tasks. That is another way around the risk, in addition to the way I suggested. I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty much the only persistent thing left would be contents of /rw/home, which is sort of a middle of the road between fully persistent /rw and using dispVMs for everything. I'm definitely going to apply your scripts to my TemplateVMs soon now that I've been made aware, but I wish there were a way to turn off persistent /usr/local and to make AppVMs use the TemplateVM's version instead. I don't use the feature, so I would prefer that /usr/local gets wiped every time like everything else in the root file system since that's the behaviour I expected to happen when I first started using Qubes (I only discovered for myself that it wasn't the case when I was trying to figure out why a custom-compiled version of Wine that I had made and installed in my TemplateVM wasn't showing up in my AppVM; its default prefix is /usr/local, which is why). Is there a way to turn off persistent /usr/local? Or is it something that's baked-in? -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e53fb1b5-fba6-4006-ff43-473bc7ad5f84%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 12:41 PM, Chris Laprise wrote: > > Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) > requires privilege escalation. If sudo has no auth process, then there > is no challenge for the attacker... they can change /rw/usrlocal in > any case. > > But also, they can change /rw/config including rc.local and firewall > scripts which run as root! > > BTW, my "better question" above really referred to the non-home areas > of /rw. > Ah, got it. Well, that's something, I suppose. >> >> While my versions do exactly what you would expect them to do, the >> difference is that each time you launch one of my versions, it starts up >> a key logging service (no root required!) in the background that >> persists even after you close the app that launched it. So for that >> entire session (assuming that AppVM is connected to the Internet), I can >> capture all of your keystrokes. And because /usr/local is persistent and >> you probably don't constantly check /usr/local for changes (because >> again, you're not paranoid), those programs will stick around and launch >> the next time you access the VM. > > But this is a problem for things like ~/.bashrc as well. Using PATH= > or alias, attacker could divert you to a phony `git` command that logs > your github password before executing the intended operation. > > That's why I suggest people consider enabling sudo auth and securing > shell init scripts in /home (see my post "Protect AppVM init startup > scripts"). You could even have an in-template startup script that > resets most of /rw (root-owner bits) to defaults really shouldn't > be hard. > > In that case, your attack scenario hinges on having a Linux escalation > exploit, and even then it might not last long enough for you to > collect valuable info (e.g. resets or updates occur that patch the > vulnerability). > > Still, though, let's say such Linux escalation exploit exists and a malicious person can access the AppVM's (let's set aside TemplateVMs for a moment) file system. They can't stick anything in most places in / because they'll disappear when the VM shuts down. Changes in /home/user could work, but because users interact with /home on a daily basis through shells or file browsers, the likelihood of them noticing changes there might be a bit higher so that might not be the smartest move. But how many here on this list regularly check their app/sys VMs for modifications to /usr/local? I'm doubting it's very many, and that I guess is my main concern. Some people may not even be aware that it *is* persistent, so people who use something like Whonix who've been targeted might even have stuff living in /usr/local right now and may not even know it (since privilege escalation exploits in tor-browser seem to be found every so often). I'm definitely going to apply your scripts to my TemplateVMs soon now that I've been made aware, but I wish there were a way to turn off persistent /usr/local and to make AppVMs use the TemplateVM's version instead. I don't use the feature, so I would prefer that /usr/local gets wiped every time like everything else in the root file system since that's the behaviour I expected to happen when I first started using Qubes (I only discovered for myself that it wasn't the case when I was trying to figure out why a custom-compiled version of Wine that I had made and installed in my TemplateVM wasn't showing up in my AppVM; its default prefix is /usr/local, which is why). Is there a way to turn off persistent /usr/local? Or is it something that's baked-in? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ocgkev%24rpd%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 02:04 PM, Reg Tiangha wrote: On 04/10/2017 11:51 AM, Chris Laprise wrote: Given the default Qubes security model, its not supposed to matter if malware can persist. Even the read-only nature of root on template-based VMs is supposed to be only a beneficial footnote. OTOH, I'd say your inquiry implies that internal VM security matters to you to at least some degree (no unguarded sudo, etc.) otherwise there is nothing to distinguish the /rw/usrlocal persistence issue from persistence via autostart scripts in /home (which can normally run sudo without any resistence). With sudo authentication enabled, the question of persistence becomes similar to that for a standalone VM... if a malware process can escalate privs (even via a temporary kernel bug) it can persist in the root-owned /rw/usrlocal even in a template-based VM. Maybe a better question is: Should we have the ability to turn off execution of /rw contents in templates? Well, here's a simple for-instance. Say you're a developer of a rival firm and I want to know all of your secrets so I target you. I know you're an emacs user, and I know you use Qubes. I also know you're paranoid enough to segregate all of your development work into one Qubes VM (yay!), but *not* paranoid enough to cut off that VM from the Internet (boo!), so not only do you do dev work in it, but you use the web browser (Chromium, in this case) to interact with websites related to your work (ex. github) but not to do anything else. So (somehow, let's say MITM) I find a way to access your file system and put stuff there. I know that most things get destroyed as soon as the VM is shutdown, so what I do is I find a way to infect your /usr/local/bin with malicious versions of Chromium and emacs and ls and all the other utilities that you'd probably use on a daily basis. Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) requires privilege escalation. If sudo has no auth process, then there is no challenge for the attacker... they can change /rw/usrlocal in any case. But also, they can change /rw/config including rc.local and firewall scripts which run as root! BTW, my "better question" above really referred to the non-home areas of /rw. While my versions do exactly what you would expect them to do, the difference is that each time you launch one of my versions, it starts up a key logging service (no root required!) in the background that persists even after you close the app that launched it. So for that entire session (assuming that AppVM is connected to the Internet), I can capture all of your keystrokes. And because /usr/local is persistent and you probably don't constantly check /usr/local for changes (because again, you're not paranoid), those programs will stick around and launch the next time you access the VM. But this is a problem for things like ~/.bashrc as well. Using PATH= or alias, attacker could divert you to a phony `git` command that logs your github password before executing the intended operation. That's why I suggest people consider enabling sudo auth and securing shell init scripts in /home (see my post "Protect AppVM init startup scripts"). You could even have an in-template startup script that resets most of /rw (root-owner bits) to defaults really shouldn't be hard. In that case, your attack scenario hinges on having a Linux escalation exploit, and even then it might not last long enough for you to collect valuable info (e.g. resets or updates occur that patch the vulnerability). -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5305bc5c-1819-dcce-7d5f-eac9aff951d4%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 11:51 AM, Chris Laprise wrote: > Given the default Qubes security model, its not supposed to matter if > malware can persist. Even the read-only nature of root on > template-based VMs is supposed to be only a beneficial footnote. > > OTOH, I'd say your inquiry implies that internal VM security matters > to you to at least some degree (no unguarded sudo, etc.) otherwise > there is nothing to distinguish the /rw/usrlocal persistence issue > from persistence via autostart scripts in /home (which can normally > run sudo without any resistence). > > With sudo authentication enabled, the question of persistence becomes > similar to that for a standalone VM... if a malware process can > escalate privs (even via a temporary kernel bug) it can persist in the > root-owned /rw/usrlocal even in a template-based VM. > > Maybe a better question is: Should we have the ability to turn off > execution of /rw contents in templates? > Well, here's a simple for-instance. Say you're a developer of a rival firm and I want to know all of your secrets so I target you. I know you're an emacs user, and I know you use Qubes. I also know you're paranoid enough to segregate all of your development work into one Qubes VM (yay!), but *not* paranoid enough to cut off that VM from the Internet (boo!), so not only do you do dev work in it, but you use the web browser (Chromium, in this case) to interact with websites related to your work (ex. github) but not to do anything else. So (somehow, let's say MITM) I find a way to access your file system and put stuff there. I know that most things get destroyed as soon as the VM is shutdown, so what I do is I find a way to infect your /usr/local/bin with malicious versions of Chromium and emacs and ls and all the other utilities that you'd probably use on a daily basis. While my versions do exactly what you would expect them to do, the difference is that each time you launch one of my versions, it starts up a key logging service (no root required!) in the background that persists even after you close the app that launched it. So for that entire session (assuming that AppVM is connected to the Internet), I can capture all of your keystrokes. And because /usr/local is persistent and you probably don't constantly check /usr/local for changes (because again, you're not paranoid), those programs will stick around and launch the next time you access the VM. That's just one idea. My imagination isn't as good as others though, so I'm sure other people can think of nasty things that can be done that doesn't require privilege escalation. Sure, you can mitigate a lot of this by cutting off VM access to the network entirely, but that's because you're smart. The guy next to you may not be as smart (or paranoid). While there would be some merit to cutting off execution in /rw areas, for the most part, the way Qubes is set up works well and that might be going too far. I do think a persistent /usr/local should be optional, however, and ideally, be disabled by default and only turned on if needed. There are some cases where one may want to install custom packages of software that they may have compiled themselves and would rather put them in /usr/local rather than /usr to help keep the file system clean. ~/bin isn't much of a problem since a) it's last in the PATH and b) if you're putting stuff in there, you definitely do so with the intent to use it only on that AppVM's user account. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ocgheb%244tm%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Display Resolution in Win 7 & Qubes 3.2 -> Problem of Qubes Windows Tools 3.2.2.3
Hello, after discovering that my Windows 7 HVM which worked perfectly under Qubes OS 3.1 causing problems with changing the display resolution under Qubes OS 3.2 I made some further research. It seems that there is a problem with Qubes Tools 3.2.2.3 - Plain Install of Qubes OS 3.2 - Installation of a Windows 7 HVM accoring to the documentation - Full Installation of Qubes Windows Tools 3.2.2.3 (except of the Xen PV Disk Driver) => Display resolution can only be set to Full Resolution and 800x600 I've then uninstalled Qubes Tools, and reinstalled it, without the Qubes Tools graphic drivers. Strangely I am then able to change the resolution from within windows. So it seems to me, that something seems to be broken with Qubes Tools 3.2.2.3 under Qubes OS 3.2 regarding the graphic drivers. Is anyone else discovering the same problem? - P -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b859b4ba-e86a-77b2-5a59-330865ae0bf1%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Persistent /usr/local: Are there risks?
On 04/10/2017 01:16 PM, Reg Tiangha wrote: According to the docs, both /home and /usr/local are persistent in an AppVM: https://www.qubes-os.org/doc/software-update-vm/ The default PATH in a Qubes VM (Debian 8) looks like this: user@Email:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/.local/bin:/home/user/bin Unless I'm mistaken, it'll search /usr/local/bin first for a binary, and if it doesn't find it there, it'll go on to the next directory which is /usr/bin. If it does find it, then the search stops and the /usr/local version gets executed, correct? So a silly question: What's stopping an adversary from placing commonly named but malicious binaries into /usr/local/bin like ls or qrexec-related binaries? Unless the scripts and programs that call those programs are hard-coded to use the absolute paths (ex. /bin/dmesg rather than just dmesg), would there not be a danger that the /usr/local versions could be invoked instead in *some* situations? Because /usr/local is persistent, a user may not necessarily know that stuff may have been placed in that directory, unless they're actively scanning it for changes, so if they regularly do work in the default bash shell, they may never know that their 'ls' command or similar may have been compromised. I don't mind a persistent /home so much since that can be useful, and I *can* see some use for a persistent /usr/local in some circumstances, but is there a way to turn the feature off for those who don't need it and make an AppVM use the TemplateVM's version instead? Given the default Qubes security model, its not supposed to matter if malware can persist. Even the read-only nature of root on template-based VMs is supposed to be only a beneficial footnote. OTOH, I'd say your inquiry implies that internal VM security matters to you to at least some degree (no unguarded sudo, etc.) otherwise there is nothing to distinguish the /rw/usrlocal persistence issue from persistence via autostart scripts in /home (which can normally run sudo without any resistence). With sudo authentication enabled, the question of persistence becomes similar to that for a standalone VM... if a malware process can escalate privs (even via a temporary kernel bug) it can persist in the root-owned /rw/usrlocal even in a template-based VM. Maybe a better question is: Should we have the ability to turn off execution of /rw contents in templates? -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11957389-e9f1-3140-863b-87a6a9396d57%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Persistent /usr/local: Are there risks?
According to the docs, both /home and /usr/local are persistent in an AppVM: https://www.qubes-os.org/doc/software-update-vm/ The default PATH in a Qubes VM (Debian 8) looks like this: user@Email:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/.local/bin:/home/user/bin Unless I'm mistaken, it'll search /usr/local/bin first for a binary, and if it doesn't find it there, it'll go on to the next directory which is /usr/bin. If it does find it, then the search stops and the /usr/local version gets executed, correct? So a silly question: What's stopping an adversary from placing commonly named but malicious binaries into /usr/local/bin like ls or qrexec-related binaries? Unless the scripts and programs that call those programs are hard-coded to use the absolute paths (ex. /bin/dmesg rather than just dmesg), would there not be a danger that the /usr/local versions could be invoked instead in *some* situations? Because /usr/local is persistent, a user may not necessarily know that stuff may have been placed in that directory, unless they're actively scanning it for changes, so if they regularly do work in the default bash shell, they may never know that their 'ls' command or similar may have been compromised. I don't mind a persistent /home so much since that can be useful, and I *can* see some use for a persistent /usr/local in some circumstances, but is there a way to turn the feature off for those who don't need it and make an AppVM use the TemplateVM's version instead? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ocgekl%24q3h%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Protect AppVM init startup scripts:
Here is a small script for Linux templates that protects files executed on startup by... bash sh Gnome KDE Xfce X11 Together with enabling sudo authentication, this is a simple way to make template-based VMs less hospitable to malware. LINK: https://github.com/tasket/Qubes-VM-hardening -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0eb0a2c6-5a42-19a4-0ebc-718606d1e245%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HW RNG on dom0?
On Mon, Apr 10, 2017 at 8:23 AM, Johannes Graumann wrote: > I am wondering whether > 1) under QubesOS a (USB) HW RNG like http://www.bitbabbler.org/ is usable Yes. You would need to do some work to make it feed entropy in a safe way though. > and if yes > 2) where attaching it would make most sense? sys-net? dom0? sys-usb, and have a qrexec service in dom0 to collect entropy from it and mix in into the dom0 pool, which will eventually propagate to other VMs. > Can Xen VM's be set up to feed on entropy provided by the host? Yes, in fact we already do so. Discussion: - https://github.com/QubesOS/qubes-issues/issues/673 - https://groups.google.com/d/topic/qubes-devel/5wI8ygbaohk/discussion Implementation: - https://github.com/QubesOS/qubes-core-agent-linux/blob/a69acdabbfb60d88971644cfad50165091a66b9f/init/functions#L95-L101 - https://github.com/QubesOS/qubes-core-admin/blob/19e68bacf22cd965e819dfa4913740ecc14d1c40/core-modules/000QubesVm.py#L1152-L1158 Cheers, Jean-Philippe -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_B5JAjF4%3DS8m%2BK-JexUVjpvqnqKyJounU4LkxRvhqbvCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - GIGABYTE GB-BSi5A-6200
Dear Qubes users, I am a recent Qubes user and especially bought this config to run qubes. Totally happy with it and hopefully using it in a secure way. Best regards, Philippe -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3e41d4f4-cb61-f071-13cb-a266a0c62db8%40crans.org. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-GIGABYTE-GB_BSi5A_6200-20170410-143039.yml Description: application/yaml Qubes-HCL-GIGABYTE-GB_BSi5A_6200-20170410-143039.cpio.gz Description: application/gzip
[qubes-users] HW RNG on dom0?
I am wondering whether 1) under QubesOS a (USB) HW RNG like http://www.bitbabbler.org/ is usable and if yes 2) where attaching it would make most sense? sys-net? dom0? Can Xen VM's be set up to feed on entropy provided by the host? Thanks for any hint. Sincerely, Joh -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1491827036.1975.26.camel%40graumannschaft.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
On 04/09/2017 06:25 PM, Joonas Lehtonen wrote: Hi, if you setup MAC randomization via network manager in a debian 9 template as described here: https://www.qubes-os.org/doc/anonymizing-your-mac-address/ you still leak your hostname. I have seen reports this change in dhcp settings did not work[1], but maybe that was a bug that was fixed. Unfortunately, the effect of these measures is likely to be limited until some changes are made for common NICs[2]. 1. https://serverfault.com/questions/557120/how-do-i-stop-a-linux-computer-from-sending-a-dhcp-hostname 2. https://arxiv.org/pdf/1703.02874v1.pdf -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2b189fab-45d8-146f-a403-6bf03f426b1c%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
>> Once your MAC address is randomized you might also want to prevent the >> disclosure of your netvm's hostname to the network, since "sys-net" >> might be a unique hostname (that links all your random MAC addresses and >> the fact that you likely use qubes). > >> To prevent the hostname leak via DHCP option (12): >> - start the debian 9 template >> - open the file /etc/dhcpd/dhclient.conf sorry there is a typo in the file path: correct file: /etc/dhcp/dhclient.conf >> - in line number 15 you should see "send host-name = gethostname();" >> - comment (add "#" at the beginning) or remove that line and store the file >> - reboot your netvm > >> I tested the change via inspecting dhcp requests and can confirm that >> the hostname is no longer included in dhcp requests. > > > Thanks. Added as a comment: > > https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 thank you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/da8baa69-eefc-674a-e7d6-e44c4163dabc%40openmailbox.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] HVM console windows on "hidpi" displays
Hi all .. I am new here. I have been hacking on Unix systems for about 20 years, but no prior experience with Xen outside of AWS. I have a 2016-generation Dell XPS 13 (9360) which has a 13-inch, 3200x1800 display. Have been struggling through all of the hacks and tricks necessary to get programs to render at a reasonable size. Will summarize those at the end for the benefit of anybody that happens to find this message first in the future.[1] I have just one thing that still runs in Tinyvision, which is the text console that comes up with an HVM guest. Having a hard time figuring out how that window gets rendered. Have tried all the following: ## Theory 1: That window cares what the X server reports via e.g. xdpyinfo. If this is right, then it might be fixed if we can get 'xrandr --dpi 192' to happen at the right place at server start. Created a setdpi.sh that runs 'xrandr --dpi 192 && date >> /tmp/setdpi.sh.log'. Put it at /etc/X11/xinit/xinitrc.d/setdpi.sh >> It runs, and has no effect. Put it as the first thing in /etc/X11/xinit/xinitrc: >> It runs, and has no effect. Set it as display-setup-script in /etc/lightdm/lightdm.conf: >> It runs, and has no effect. Tried it as session-setup-script in /etc/lightdm/lightdm.conf: >> It runs, and has no effect. Also tried "DisplaySize 423 238" in xorg.conf. No effect. In all cases, the HVM console is still tiny, and at startup, xdpyinfo shows 96x96. This is odd because after login, if I run 'xrandr --dpi 192' by hand, xdpyinfo changes to show 192x192. (To get this far required trying several kernels and finding that 4.8.12-12.pvops.qubes.x86_64 from qubes unstable repo works, BTW.) ## Theory 2: It's the guest OS's problem to ask for a bigger display. I was surprised to discover that an OpenBSD HVM guest (which doesn't even work right in most ways), is capable of changing video modes by starting an X server, and the host display gives it a new window at the new resolution. This is also in Tinyvision and not resizable, but that is probably solvable inside the guest OS eventually. I tried many permutations of OpenBSD wsconscfg, and FreeBSD vt (vidcontrol etc), to see if the guest OS could be persuaded to change modes on its fake VGA device, or at least just throw huge fonts at it. No good. The xen device doesn't provide whatever interface the console drivers are looking for, and nothing works. I tried hacking up the xen configs to force the HVMs to start with every known xen video backend: vga, cirrus, vmvga, xen, vbox, qxl, virtio, and gop. All either unsupported or work the same as the default (xen). ## Theory 3: The window is drawn by qubes-guid. Have read some of the code in qubes-gui-agent-xen-hvm-stubdom, and maybe eventually the answer is in here. There is a tantalizing clue in /var/log/xen/console/guest-xxx-dm.log, which gets messages like "dumping mfns: n=282, w=720, h=400, bpp=32." This traces back to line 171 of qubes-gui.c, and 720x400 is the size of the Tinyvision window. ## Theory 4: The simulated vga text console is never going to work. I could ssh to an HVM from another VM with a working terminal. Or I can try to get 'xl console' to work. But both cases will require some modifications in the guest OS first, and it's painful to do anything non-trivial in Tinyvision. Anyone recognize any clues here, or have an explanation of how the console window gets drawn? - [1] Some or all of the following were necessary to apply in each VM: + Xfce "Appearance" settings panel - set "Custom DPI setting" on Fonts tab. + Xfce "Window Manager" settings panel has a theme named "hidpi" which helps with window frames. + Some X applications react to 'xrandr --dpi 192'. Unclear which ones or why. You can verify if this had an effect by asking 'xdpyinfo | grep -b2 resolution' + Some gtk-based UI elements are affected by running: gsettings set org.gnome.desktop.interface scaling-factor 2 gsettings set org.gnome.desktop.interface text-scaling-factor 0.75 + One Debian-8 VM would not persist the Xft change at startup until I did: echo "Xft/DPI 196608" >> ~/.xsettingsd # that number is 192*1024 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9f98b327-80ef-4cc5-b6d2-2e9b3b4a07f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.