Re: [qubes-users] USB VM
Hi JJ, Did some more testing, you were right, I only have 3. I have 2 bus's on the motherboard... I plugged a USB drive into each set to find out which were which. But that doesn't explain why it isn't working when I even just attach my USB3 card to the USBVM. That alone should work, but it doesn't. So this means I should be able to attach the USB3 card, and the 4 other USB to the USBVM, leaving 2 attached to Dom0 for my use. So why does it have the error? -- 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/96751700-6a17-4829-b224-5ee6841a2c39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. /: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M #(Back ports 1-2) |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M # bus 02-09 USB3 PCIE card (4 ports) /: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 2: Dev 9, If 0, Class=Mass Storage, Driver=usb-storage, 480M # USB HDD. USB3 card |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 3: Dev 11, If 0, Class=Mass Storage, Driver=usb-storage, 480M # USB HDD. Monitor SIDE 2 ports |__ Port 3: Dev 13, If 0, Class=Mass Storage, Driver=usb-storage, 480M # USB HDD. Monitor UNDERNEATH 2 ports /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M # USB HDD. #(Back ports 3-4 , Front 2 ports)
Re: [qubes-users] USB VM
On Wednesday, 28 September 2016 13:27:17 UTC+10, johny...@sigaint.org wrote: > > Hi JJ, > > > > My PC has 10 USB Bus's. > > My keyboard and mouse are on bus 10, which is PCI device .XX.X and I > > left that one on Dom0. > > Are they 10 separate PCI devices, 10 separate USB buses? > > I'd be very surprised if that were the case. But also very impressed, and > wanting such a motherboard for myself. It'd be awesome for Qubes. > > But it's more likely that it's a single USB controller with 10 ports. > > If you do a "lspci" do you see 10 different USB PCI devices? (Well, it > would probably be 20, as each USB bus usually shows up with a USB 1.1 and > a USB 2.0 version.) I have USB1 and USB2 hubs. (according to lsusb) > Or does "lspci" just show two USB PCI devices (one 1.1, and one 2.0)? attached, view it for yourself. :} in that list though, I only have 1 keyboard and 1 mouse plugged in. I will do some more with more devices plugged in so you can see where the devices attach to. I have 2 ports on the back on 1 bus, 2 ports on another. 2 ports on the front on another bus. I have a PCIE card with 4xUSB3 ports. I also have 1xUSB Internal (can be used as a boot device, as a Qubes boot device even) My monitor is plugged into the USB3 card, which has 4 USB ports and a Multimedia card reader in it. My other 2 USB port monitor is NOT plugged in. I have 2xUSB3 on the front that aren't plugged in. > The USB PCI device can have 10 *ports*, and still just be one PCI device, > assignable to only a single Qubes VM. > > I have 8 ports (well, 6 after blowing 2 of them on some projects, but > that's another story), which are handled by a single USB PCI device (which > has two presences, one for 1.1 (ohci), one for 2.0 (ehci). > > (I'm rather impressed that the single controller let me blow two ports, > while keeping the others alive. Nice isolation, NVIDIA!): > > # lspci > 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3) > 00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3) > > "lsusb -t" is also telling: > > # lsusb -t > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/8p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M > |__ Port 4: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, xxxM > |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, xxxM > |__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, xxxM > |__ Port 8: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, xxxM > > USB ports are not the same as USB PCI devices/busses. And the only reason > you see two Bus's in both cases above, is because it's a USB 1.1 and USB > 2.0 presence of the same single USB controller. > > It *may* be possible to assign the 2.0 controller instance (fast hard > drives, thumb drives, etc.) to a given VM, while keeping the slower 1.1 > HID instance (keyboard, mouse) in dom0, but I wouldn't count on it. (I > might try that when I get a chance.) > > We'd possibly need Andrew or Merek or some other Qubes expert to answer that. > > Just get your keyboard/mouse onto PS/2, and then things get a lot simpler > to figure out. > > > However I now have another issue... > > > > "Error starting VM 'sys-usb': Requested operation is not valid: PCI device > > :00:1a.0 is in use by driver xenlight, domain sys-usb" > > > > What does this mean? > > It does this for each PCI device. I have removed them 1 by 1 just to > > verify. > > > > Why won't it just assign the device? > > Perhaps because you really only have one USB PCI device/bus, and because > two of the ports are tied up in dom0 with your USB keyboard/mouse it wants > to (out of necessity) control them all (well, the one USB controller, > really) and won't let you assign individual ports on the common USB PCI > bus to different VM's?? > > I've never seen that error, so I'm just guessing; that's a question for > the Qubes dev experts. > > I'm actually still running my boot/root drive off of USB until an imminent > reinstall (with btrfs root, yay!), so I'm a bit of a hypocrite singing the > praises of USB VM isolation. As long as my boot/root is on USB, I can't > create a USB VM, despite having a PS/2 keyboard/mouse. Soon... Soon... > > Cheers > > JJ -- 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/7da5570e-7d36-4e4f-8a3d-c00e32e77df1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. 00:00.0 Host bridge: Intel Corporation 5520 I/O Hub to ESI Port (rev 22) 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 22) 00:03.0 PCI bridge:
Re: [qubes-users] USB VM
> Hi JJ, > > My PC has 10 USB Bus's. > My keyboard and mouse are on bus 10, which is PCI device .XX.X and I > left that one on Dom0. Are they 10 separate PCI devices, 10 separate USB buses? I'd be very surprised if that were the case. But also very impressed, and wanting such a motherboard for myself. It'd be awesome for Qubes. But it's more likely that it's a single USB controller with 10 ports. If you do a "lspci" do you see 10 different USB PCI devices? (Well, it would probably be 20, as each USB bus usually shows up with a USB 1.1 and a USB 2.0 version.) Or does "lspci" just show two USB PCI devices (one 1.1, and one 2.0)? The USB PCI device can have 10 *ports*, and still just be one PCI device, assignable to only a single Qubes VM. I have 8 ports (well, 6 after blowing 2 of them on some projects, but that's another story), which are handled by a single USB PCI device (which has two presences, one for 1.1 (ohci), one for 2.0 (ehci). (I'm rather impressed that the single controller let me blow two ports, while keeping the others alive. Nice isolation, NVIDIA!): # lspci 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3) 00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3) "lsusb -t" is also telling: # lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/8p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M |__ Port 4: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, xxxM |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, xxxM |__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, xxxM |__ Port 8: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, xxxM USB ports are not the same as USB PCI devices/busses. And the only reason you see two Bus's in both cases above, is because it's a USB 1.1 and USB 2.0 presence of the same single USB controller. It *may* be possible to assign the 2.0 controller instance (fast hard drives, thumb drives, etc.) to a given VM, while keeping the slower 1.1 HID instance (keyboard, mouse) in dom0, but I wouldn't count on it. (I might try that when I get a chance.) We'd possibly need Andrew or Merek or some other Qubes expert to answer that. Just get your keyboard/mouse onto PS/2, and then things get a lot simpler to figure out. > However I now have another issue... > > "Error starting VM 'sys-usb': Requested operation is not valid: PCI device > :00:1a.0 is in use by driver xenlight, domain sys-usb" > > What does this mean? > It does this for each PCI device. I have removed them 1 by 1 just to > verify. > > Why won't it just assign the device? Perhaps because you really only have one USB PCI device/bus, and because two of the ports are tied up in dom0 with your USB keyboard/mouse it wants to (out of necessity) control them all (well, the one USB controller, really) and won't let you assign individual ports on the common USB PCI bus to different VM's?? I've never seen that error, so I'm just guessing; that's a question for the Qubes dev experts. I'm actually still running my boot/root drive off of USB until an imminent reinstall (with btrfs root, yay!), so I'm a bit of a hypocrite singing the praises of USB VM isolation. As long as my boot/root is on USB, I can't create a USB VM, despite having a PS/2 keyboard/mouse. Soon... Soon... Cheers JJ -- 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/64d179f7274c52e3eda2c6401259dcf2.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB VM
On Wednesday, 28 September 2016 12:46:10 UTC+10, johny...@sigaint.org wrote: > Pretty sure the answer is "no." You can assign a whole USB bus (which is > typically a single PCI device) to a VM, but you can't split it up beyond > that, other than the default of having dom0 relay specific devices to > specific VM's (which isn't dom0 USB isolation at all). > > My mobo has 8 USB ports, but they're all on a single bus, so it's all or > nothing. > Hi JJ, My PC has 10 USB Bus's. My keyboard and mouse are on bus 10, which is PCI device .XX.X and I left that one on Dom0. However I now have another issue... "Error starting VM 'sys-usb': Requested operation is not valid: PCI device :00:1a.0 is in use by driver xenlight, domain sys-usb" What does this mean? It does this for each PCI device. I have removed them 1 by 1 just to verify. Why won't it just assign the device? FYI: I have plenty of adapters lying around. But thanks for thinking about that. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/70d18024-3a9c-433f-8056-8047153e901b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB VM
> It may no longer be the case, but it used to be that most USB keyboards > and mice had controllers that also automatically auto-detected and > supported PS/2, with a simple passive passthrough dongle between the > USB->PS/2 connection. > > http://www.ebay.com/itm/Cool-PS2-Female-to-USB-Male-Port-Mouse-Adapter-Converter-Connector-for-Keyboard-/321935935564?hash=item4af4e0884c:g:F98AAOSwgApW-yRg > > $0.75 each, including international shipping. > > You or someone you know may even have such dongles kicking around; if so, > given them a try. The common logitech ones seem to work for most every > keyboard/mouse I've tried. I should mention that if you're paranoid, are a high-value targeted individual, or simply have a psycho on your butt, you may want to do a good check of such a dongle with a ohmmeter or scope. Or even better, wire your own. It's a wonderful place to hide a keylogger. :) http://www.keydemon.com/ps2_hardware_keylogger/ https://www.keelog.com/usb_hardware_keylogger.html http://www.instructables.com/id/How-to-build-your-own-USB-Keylogger/ I have a couple of these in my "JJ's Meseum of Dodgy Devices." Thankfully I didn't have to pay for them myself, but they were graciously snuck into my inventory of parts by secret admirers. So very kind of them, and without even wanting credit. :) Cheers JJ -- 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/942e123f99dcd7bc60f509d719d7.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB VM
> I want to get the USB VMs to work, but I use keyboard and mouse via USB, > not PS/2, so it will not permit me to configure it. > > I wish to attach specific USB Ports to Dom0, which is 1 of the bus's. And > the other USB bus's to the USBVM, but I can't find out what device to > attach to Dom0 to allow this. > > I know what my USB3 is because that's a PCIe card. So that's easy enough > to push to a USBVM. But the others, not so easy. > > Is it possible to assign specific USB ports instead of whole USB bus's? Pretty sure the answer is "no." You can assign a whole USB bus (which is typically a single PCI device) to a VM, but you can't split it up beyond that, other than the default of having dom0 relay specific devices to specific VM's (which isn't dom0 USB isolation at all). My mobo has 8 USB ports, but they're all on a single bus, so it's all or nothing. It's worth looking into whether your keyboard/mouse support PS/2. It may no longer be the case, but it used to be that most USB keyboards and mice had controllers that also automatically auto-detected and supported PS/2, with a simple passive passthrough dongle between the USB->PS/2 connection. http://www.ebay.com/itm/Cool-PS2-Female-to-USB-Male-Port-Mouse-Adapter-Converter-Connector-for-Keyboard-/321935935564?hash=item4af4e0884c:g:F98AAOSwgApW-yRg $0.75 each, including international shipping. You or someone you know may even have such dongles kicking around; if so, given them a try. The common logitech ones seem to work for most every keyboard/mouse I've tried. Or, if you're handy with a soldering iron, make your own. https://imgur.com/a/n3BJ0 I've chopped up an old PS/2 cable and soldered it to a USB keyboard successfully in the past. (Even just cut and twisted the wires together in a pinch, lol. Worked great.) Worst case, splurge the <$10 each on getting a nice PS/2 mouse and keyboard, and proceed with far greater confidence/security, and more easily isolate your USB to a VM. (Heck, I'd send you a free PS/2 mouse/keyboard if it didn't cost more to ship than to it would be for you to purchase new.) Maybe it's less common these days for keyboards/mice to support that feature, but it's hardly difficult even today to buy or find a good PS/2 mouse and keyboard for dirt cheap. JJ -- 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/9a89fa98a26dc3959505a12ab81dd1f1.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
> You can get a motherboard that has a removable bios chip that you can just > snap in to replace, Then call the company and have them send you one or > two to hold onto for emergency lol. There is also mobos with dualbios, > most ly this is for bringing a bricked board back to life. I actually have one of those motherboards here. It sounded like a very kick-ass feature, the double-bios to restore in case of problems. And the board has 8 SATA, a dozen USB, some serious video and audio capabilities, 32g memory capabilities, IOMMU, etc. But it was given to me out of the blue right after I retired a dodgy/compromised machine, so I'm a little wary. A shame, because it's one hell of a motherboard. I might fire it up with Qubes in a non-critical/non-trusted manner. (Or set it up in a Windows machine, sell it, and buy a known secure motherboard. :) ) > Also don't forget malware can reside in other firmware also. SO that > means all pci devices, like gpu, netcard. etc... most experts will > tell you just to replace everything to be sure if you think you are > compromised at that level and its important. Would you say a motherboard that integrates a lot of that (with the dual recovery BIOS) would be less prone to compromise (or at least easier to restore from compromise) than a machine that separate PCI cards providing that sound/video/net? Presumably, if you can trust the vendor and its BIOS, one flashing of the BIOS (or recovery from the backup) should restore you to a state that could be trusted. A lot easier than doing the same (if even possible) for the net/sound/video add-on cards, no? Or would it be easier for a threat actor to attack a specific motherboard and its integrated peripherals, rather than a random set of add-on cards? JJ -- 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/54219c183f184f416f6dda20c57ec5ba.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
> Yeah, Joanna is seriously epic. Upon that, we can all agree. Everything she designs or writes up, seems bang-on (and wonderfully informative) in this increasingly security-threatened world we're living in. She's probably just a fictional character created by the NSA to mesmerize and lure us Linux geeks into this honeypot known as Qubes. :) (Even I'm not quite that paranoid. Yet, at least.) > How about Raspberry Pi..? That seems to have very few components. That's interesting. As a side project (one of s s many), I'm working on a Arduino-based system that will let me do secure, encrypted note-taking, email, SMS, messaging, etc., with (similarly secure/encrypted/hack-proof) mouse/keyboard/storage, as well as even being a platform for further development of the same system, without dependency upon a vulnerable PC or laptop. And also being lower-power and mobile, which helps security further. Things like secure and encrypted SMS, messaging, email, note taking, PDA-like functionality (on par with Palm Pilots in days of old) are certainly possible, without being threatened by hacks from all the organized (or disorganized) crooks or overly-aggressive governments pushing, unhindered and beyond reproach, way beyond constitutional and ethical boundaries. They will be portable, low power, low cost, open source, transparent tools that could be used by the oppressed, the abused, whistle-blowers, the relentlessly hacked, that are afraid to speak out, as well as the general public. I've been focused upon Arduino/atmega328 due to the low cost, accessibility, transparency, etc.. (The harassment I've personally been undergoing has been keeping me, errr, rather "frugal," so the atmega328 platform is appealing.) Raspberry is a bit like Arduino/atmega on steroids. I've not gone there because it draws more power, costs more; but at the end of the day, it's more powerful and probably has similar security/transparency as the Arduino/atmega328 if done properly. And with its additional processing power, it's a more likely candidate for replacing a PC for things like web browsing, Tor, VPN, PGP, (things a bit beyond atmega328's capabilities). And in those cases, the extra cost is still far below even a basic notebook or tablet. (Not sure how it rates power-consumption-wise as compared to notebooks/tablets, maybe a bit worse. I see it used a lot for home media PC's, which I doubt would last long on a couple of CR2032 batteries. :) But still way better than a PC, as long as we still can rely upon power to our homes, it'll do. :) ) I am firmly convinced that the only salvation to corrupt surveillance states and the take-over of the world by the greedy and corrupt, is a revolution to more simplistic, secure, and (especially) transparent technology that achieves a lot of the same things as today's hopelessly complex smartphones, Wifi, broadbands, web browsers. I'll stop the rant now. :) But progressing/expanding up to the Raspberry's power while still achieving the same goals, is something I'm going to seriously ponder. (There are a number of other processors, like STM32 and others, that can similarly bring more processing power without blowing security. My approach is quite portable, so any or all of the platforms should be viable to include in the solution.) Thanks for the inspiration. :) JJ -- 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/b78f3e35c0cd398b824136b4e5ca75bc.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] System still freezes, still no resolution.
On Wednesday, 28 September 2016 11:28:45 UTC+10, Drew White wrote: > On Wednesday, 28 September 2016 03:54:10 UTC+10, raah...@gmail.com wrote: > > Is your issue after a wake from suspend? Desktop freezes on me on one > > machine if it is left asleep for too long. I figure its related to bios or > > what vms were running when it went to sleep. I also find its less of a > > problem on kde then on xfce. In my case it also seems to happen more often > > if i wake machine up from power button rather then a keyboard press. > > Well, it just happened again. > While I was using it. > I'll attach the log fine. But as far as I can tell, it's because Qubes uses > ystemD. And when that runs out of RAM to use, it locks up. and since > everything runs as SystemD, just like Windows, everything locks up, instead > of 1 process. > > How do I install another O/S as Dom0? (it is Linux) > How do I install another O/S as integrated guests? (it is Linux) > > Help please? Addn: I forgot to mention, this time, nothing kept running in the background, EVERYTHING was frozen. Not even the logging kept going. -- 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/8bd05fb7-5e45-4e07-9bf0-5b3b5b886bcf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: System still freezes, still no resolution.
After 10 minutes of running, I have less than 50 Mb free RAM in Dom0. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/810971d3-78fc-4a93-b767-f321b04f8aa5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] System still freezes, still no resolution.
On Wednesday, 28 September 2016 03:54:10 UTC+10, raah...@gmail.com wrote:
> Is your issue after a wake from suspend? Desktop freezes on me on one machine
> if it is left asleep for too long. I figure its related to bios or what vms
> were running when it went to sleep. I also find its less of a problem on kde
> then on xfce. In my case it also seems to happen more often if i wake
> machine up from power button rather then a keyboard press.
Well, it just happened again.
While I was using it.
I'll attach the log fine. But as far as I can tell, it's because Qubes uses
ystemD. And when that runs out of RAM to use, it locks up. and since everything
runs as SystemD, just like Windows, everything locks up, instead of 1 process.
How do I install another O/S as Dom0? (it is Linux)
How do I install another O/S as integrated guests? (it is Linux)
Help please?
--
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/5d91201a-81a1-4214-88e7-95f4b36156ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
==
Wed Sep 28 10:55:01 AEST 2016
--
Filesystem Size Used Avail Use% Mounted on
devtmpfs2.0G 0 2.0G 0% /dev
tmpfs 2.0G 1.2M 2.0G 1% /dev/shm
tmpfs 2.0G 1.6M 2.0G 1% /run
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/sda324G 3.0G 20G 14% /
tmpfs 2.0G 20K 2.0G 1% /tmp
xenstore2.0G 168K 2.0G 1% /var/lib/xenstored
/dev/sda1 485M 114M 346M 25% /boot
/dev/sda2 211G 170G 31G 85% /var/lib/qubes
tmpfs 393M 0 393M 0% /run/user/{user-id}
tmpfs 393M 8.0K 393M 1% /run/user/{user-id}
/dev/sdb1 1.4T 1.4T 24G 99% /run/media/{user}/{driveid}
--
top - 10:55:01 up 29 min, 2 users, load average: 0.15, 0.11, 0.09
Tasks: 319 total, 2 running, 317 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.5 sy, 0.0 ni, 98.5 id, 0.3 wa, 0.0 hi, 0.0 si, 0.4 st
KiB Mem : 4021248 total,29992 free, 647188 used, 3344068 buff/cache
KiB Swap:0 total,0 free,0 used. 3272200 avail Mem
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
1375 root 20 0 1208156 138944 16488 S 0.0 3.5 0:40.26
/usr/sbin/libvirtd
2429 root 20 0 471568 119596 46572 S 0.0 3.0 1:15.27 /usr/bin/X
-background none :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp
vt1 -novtswitch
2551 {user}20 0 1064608 110784 58184 S 0.0 2.8 0:25.71
/usr/bin/python2 /usr/bin/qubes-manager -session
22e377861-de6d-4a80-bcbb-bca633662d3a_1473145497_828268
2547 {user}20 0 725028 68748 37600 S 0.0 1.7 0:02.11 xfdesktop
--display :0.0 --sm-client-id 20f7090c4-72bd-4a35-835a-cef95d8d23a7
2543 {user}20 0 514208 36048 20136 S 0.0 0.9 0:01.34 xfce4-panel
--display :0.0 --sm-client-id 29b506d82-70ff-48be-8d61-f796aa02cdc8
2542 {user}20 0 334292 33680 17268 S 0.0 0.8 0:06.25 xfwm4
--display :0.0 --sm-client-id 20396542a-441a-4b46-b663-130920bb
6923 {user}20 0 445460 32996 18288 S 0.0 0.8 0:00.22
/usr/bin/python /usr/lib/qubes/icon-receiver
2687 {user}20 0 445192 32840 18352 S 0.0 0.8 0:00.20
/usr/bin/python /usr/lib/qubes/icon-receiver
2711 {user}20 0 445192 32648 18164 S 0.0 0.8 0:00.17
/usr/bin/python /usr/lib/qubes/icon-receiver
1523 root 20 0 583180 31364 18204 S 0.0 0.8 0:00.56
/usr/bin/python2 /usr/lib/qubes/qmemman_daemon.py
2534 {user}20 0 479428 27896 13400 S 0.0 0.7 0:00.64
xfce4-session
3533 {user}20 0 559228 26944 21204 S 0.0 0.7 0:33.49
/usr/bin/Thunar file:///run/media/{user}/Drew1_5
2557 {user}20 0 488024 24140 19360 S 0.0 0.6 0:00.18
xfce4-power-manager --restart --sm-client-id
2d75b6a48-8608-4e8e-a374-d28b1677ed75
2729 {user}20 0 524880 21396 17600 S 0.0 0.5 0:01.24
/usr/bin/xfce4-terminal
2576 {user}20 0 712960 21216 17804 S 0.0 0.5 0:00.08
/usr/lib64/xfce4/panel/wrapper-1.0 /usr/lib64/xfce4/panel/plugins/libmixer.so
13 18874411 mixer Audio Mixer Adjust volume levels
2593 {user}20 0 463612 20388 17640 S 0.0 0.5 0:00.21
/usr/lib64/xfce4/notifyd/xfce4-notifyd
2595 {user}20 0 474064 19536 16768 S 0.0 0.5 0:00.34
/usr/lib64/xfce4/panel/wrapper-1.0 /usr/lib64/xfce4/panel/plugins/libfsguard.so
8 18874418 fsguard Free Space Checker Monitor free disk space
2599 {user}20 0 459648 18588 16292 S 0.0 0.5 0:06.85
Re: [qubes-users] System still freezes, still no resolution.
On Wednesday, 28 September 2016 03:54:10 UTC+10, raah...@gmail.com wrote: > Is your issue after a wake from suspend? Desktop freezes on me on one machine > if it is left asleep for too long. I figure its related to bios or what vms > were running when it went to sleep. I also find its less of a problem on kde > then on xfce. In my case it also seems to happen more often if i wake > machine up from power button rather then a keyboard press. Well, it just happened again. While I was using it. I'll attach the log fine. But as far as I can tell, it's because Qubes uses SystemD. And when that runs out of RAM to use, it locks up. and since everything runs as SystemD, just like Windows, everything locks up, instead of 1 process. How do I install another O/S as Dom0? (it is Linux) How do I install another O/S as integrated guests? (it is Linux) Help please? -- 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/ba8e5b49-1540-4e93-9342-c98c09e25c5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@gmail.com: > On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: >> raahe...@gmail.com: >>> or just only allow https in the vm firewall settings. >> >> I assume you mean whitelisting TCP port 443? If so, be aware that while >> this will stop most non-HTTPS traffic, there is nothing that prevents >> other protocols from using port 443. It's a fairly well-known attack on >> Tor's "stream isolation by port" feature for websites to use nonstandard >> ports in order to get isolated in the wrong Tor circuit (e.g. in order >> to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by >> port by default. >> >> Whitelisting TCP port 443 is still better than nothing, though, assuming >> that you don't expect any legitimate traffic to go over other ports. >> Just be aware that it's trivially easy to bypass for an attacker. >> >> Assuming that you're using a Firefox-based browser (including Tor >> Browser), you can get some defense in depth by also enabling the feature >> of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong >> with combining this with the firewall whitelist that you suggested. >> >> Cheers, >> -Jeremy > > oh I see now there is the feature in the plugin ive never used lol. I still > think its unescessary if you already blocking that traffic with the firewall, > especially if that plugin or browser is compromised, especially with latest > news about firefox plugins. For example noscript itself is considered a > vulnerability on firefox now. As I said, it gets you defense in depth because the two mechanisms prevent different (though overlapping) attacks. HTTPS Everywhere's feature for blocking non-TLS requests will block non-TLS requests from Firefox that use port 443, while the FirewallVM won't be able to stop this. For example, a request to http://www.nsa.gov:443/ will be stopped by HTTPS Everywhere, since it knows the protocol being used as opposed to just the TCP port. The FirewallVM, on the other hand, will block TCP connections on ports other than 443 even if Firefox in the AppVM is compromised. E.g. you visit https://www.nsa.gov/ , they deploy a Firefox zero-day, and are thus able to bypass HTTPS Everywhere. Both of these attacks have a lot of overlap (e.g. a simple request to http://www.nsa.gov/ will be blocked by both). But each defense does prevent some types of attack that the other doesn't, so it makes sense IMO to use both. Definitely won't hurt you, and it might help depending on what attacks get aimed at you. (Of course, either of those defenses alone is likely to prevent the vast majority of real-world attacks, but I'd still suggest doing both. Justified paranoia is why we're all here, right? :) ) Cheers, -Jeremy -- 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/6560bf5f-8710-40e8-0a14-be32c57adae3%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] System still freezes, still no resolution.
On Wednesday, 28 September 2016 03:54:10 UTC+10, raah...@gmail.com wrote: > Is your issue after a wake from suspend? Desktop freezes on me on one machine > if it is left asleep for too long. I figure its related to bios or what vms > were running when it went to sleep. I also find its less of a problem on kde > then on xfce. In my case it also seems to happen more often if i wake > machine up from power button rather then a keyboard press. Short answer: no. Long answer: It isn't from waking, it never goes to sleep, only blanks the screen itself. I changed to XFCE because it was happenning overnight on KDE. XFCE takes a lot longer to happen. Since mine never sleeps, and is always working (I am a programmer), all I normally do is move the mouse and it comes back to life from the lock screen. But this PC locking up is odd. It never happpenned in version. or 3.0 that I can remember. Nope, it did happen once when Qubes Manager absorbed all the RAM. Since that 1 leak was fixed, it didn't happen in 3.0. And that didn't matter if I used KDE or XFCE. I wish they would go back to the older GUI instead of this new wanky one. -- 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/2e08aed4-1cc5-4d98-ab7e-2c1c14200cf1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: > raahe...@gmail.com: > > or just only allow https in the vm firewall settings. > > I assume you mean whitelisting TCP port 443? If so, be aware that while > this will stop most non-HTTPS traffic, there is nothing that prevents > other protocols from using port 443. It's a fairly well-known attack on > Tor's "stream isolation by port" feature for websites to use nonstandard > ports in order to get isolated in the wrong Tor circuit (e.g. in order > to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by > port by default. > > Whitelisting TCP port 443 is still better than nothing, though, assuming > that you don't expect any legitimate traffic to go over other ports. > Just be aware that it's trivially easy to bypass for an attacker. > > Assuming that you're using a Firefox-based browser (including Tor > Browser), you can get some defense in depth by also enabling the feature > of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong > with combining this with the firewall whitelist that you suggested. > > Cheers, > -Jeremy oh I see now there is the feature in the plugin ive never used lol. I still think its unescessary if you already blocking that traffic with the firewall, especially if that plugin or browser is compromised, especially with latest news about firefox plugins. For example noscript itself is considered a vulnerability on firefox now. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5a29f491-7cf3-4311-b532-edf7441643a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: > raahe...@gmail.com: > > or just only allow https in the vm firewall settings. > > I assume you mean whitelisting TCP port 443? If so, be aware that while > this will stop most non-HTTPS traffic, there is nothing that prevents > other protocols from using port 443. It's a fairly well-known attack on > Tor's "stream isolation by port" feature for websites to use nonstandard > ports in order to get isolated in the wrong Tor circuit (e.g. in order > to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by > port by default. > > Whitelisting TCP port 443 is still better than nothing, though, assuming > that you don't expect any legitimate traffic to go over other ports. > Just be aware that it's trivially easy to bypass for an attacker. > > Assuming that you're using a Firefox-based browser (including Tor > Browser), you can get some defense in depth by also enabling the feature > of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong > with combining this with the firewall whitelist that you suggested. > > Cheers, > -Jeremy I do https only on most of my vms. Of course nothing is 100% but i'm not sure if you are saying that would make me more vulnerable? I believe this is common qubes practice among even the devs. what extra benefits would https everywhere plugin have over the firewall? I do use this plugin on the vms that aren't restricted to only https, I also use ublock origin. I also always use noscript or scriptsafe on all vms. But is there extra settings to use in https everywhere, because all I thought it does was verify certs with the fsf. I use it on all my machines and maybe i'm missing the setting to stop http connections, but I think the firewall is all you need and separate from the browser itself. But by blocking everything but https is helpful not just against mitm, but say for example in your email vm where you dont' want to accidentally click a bad link.So if some sketchy non http link you would be forced to copy it to a less privileged vm to open it. -- 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/18285799-3c78-4349-b368-22b1329c4329%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
On Tuesday, September 27, 2016 at 7:27:43 PM UTC-4, raah...@gmail.com wrote: > On Tuesday, September 27, 2016 at 5:38:59 PM UTC-4, Unman wrote: > > On Tue, Sep 27, 2016 at 12:41:12PM -0700, raahe...@gmail.com wrote: > > > On Sunday, September 25, 2016 at 9:46:13 AM UTC-4, nishi...@gmail.com > > > wrote: > > > > Hello, > > > > > > > > I am surprised that there is no way to disable ipv6 on Debian template. > > > > > > > > I reinstalled first the template using documentation > > > > https://www.qubes-os.org/doc/reinstall-template/ > > > > > > > > Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, > > > > I did reboot the Template but it didn't change the outcome, I still had > > > > ipv6 ports opened using "netstat -antp" > > > > > > > > I even added "sudo ip6tables -P INPUT DROP" in "/rw/config/rc.local", > > > > but I still got those distant servers listening when I check using > > > > commands like "sudo lsof -i6" or "netstat -antp" on my Debian Template. > > > > > > > > What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd > > > > on PID 1 ? Looks suspicious, I thought Ipv6 was disabled by default on > > > > Qubes. > > > > > > > > Regards > > > > > > You have to change kernel parameters a diff way I believe. try this > > > method from whonix instructions. > > > https://www.whonix.org/wiki/Qubes/Install > > > > > > to list the parameters use qvm-prefs -l debian-8 kernelopts > > > > > > To change them do qvm-prefs -s debian-8 kernelopts "nopat ipv6.disable=1" > > > > > > Then restart template and vms. > > > > > > > As I pointed out, changing parameters in the template will not affect the > > VMs. > > You need to change the option individually for each qube where you want > > to disable IP6. > > > > unman > > I pointed out how to change the parameters. You do the command from dom0 for > the template you want ipv6 disabled. Basically The same method whonix > instructs on how to install apparmor on debian template. This is how I > disable ipv6. you can verify this from a terminal in one of the proxies or vms based on that template with lsof or netstat and see no more ipv6 connections. -- 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/13ed43ba-4151-4b52-9d25-3d4fff210b63%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
On Tuesday, September 27, 2016 at 5:38:59 PM UTC-4, Unman wrote: > On Tue, Sep 27, 2016 at 12:41:12PM -0700, raahe...@gmail.com wrote: > > On Sunday, September 25, 2016 at 9:46:13 AM UTC-4, nishi...@gmail.com wrote: > > > Hello, > > > > > > I am surprised that there is no way to disable ipv6 on Debian template. > > > > > > I reinstalled first the template using documentation > > > https://www.qubes-os.org/doc/reinstall-template/ > > > > > > Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, I > > > did reboot the Template but it didn't change the outcome, I still had > > > ipv6 ports opened using "netstat -antp" > > > > > > I even added "sudo ip6tables -P INPUT DROP" in "/rw/config/rc.local", but > > > I still got those distant servers listening when I check using commands > > > like "sudo lsof -i6" or "netstat -antp" on my Debian Template. > > > > > > What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd on > > > PID 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes. > > > > > > Regards > > > > You have to change kernel parameters a diff way I believe. try this > > method from whonix instructions. https://www.whonix.org/wiki/Qubes/Install > > > > to list the parameters use qvm-prefs -l debian-8 kernelopts > > > > To change them do qvm-prefs -s debian-8 kernelopts "nopat ipv6.disable=1" > > > > Then restart template and vms. > > > > As I pointed out, changing parameters in the template will not affect the > VMs. > You need to change the option individually for each qube where you want > to disable IP6. > > unman I pointed out how to change the parameters. You do the command from dom0 for the template you want ipv6 disabled. Basically The same method whonix instructs on how to install apparmor on debian template. This is how I disable ipv6. -- 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/9d5aafb3-f3e1-4d50-b1eb-e7a681059c81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 4:27:01 PM UTC-4, neilh...@gmail.com wrote: > How about Google Chromebooks which have a system to auto-restore the OS if it > thinks it's been tampered with..? > > Or what about a read-only BIOS in the first place..? > > Is there any reason BIOS can't be read-only..? > > I basically want a computer which is most easy to wipe/reinstall and then > it's truly wiped. You can get a motherboard that has a removable bios chip that you can just snap in to replace, Then call the company and have them send you one or two to hold onto for emergency lol. There is also mobos with dualbios, most ly this is for bringing a bricked board back to life. Also don't forget malware can reside in other firmware also. SO that means all pci devices, like gpu, netcard. etc... most experts will tell you just to replace everything to be sure if you think you are compromised at that level and its important. -- 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/8130b1be-a0c0-46ec-9d3f-1bfe5bc18d7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
Yeah, Joanna is seriously epic. How about Raspberry Pi..? That seems to have very few components. -- 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/b628b960-618f-41da-b0ae-3b15282af050%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
On Tue, Sep 27, 2016 at 09:15:47PM +, Jeremy Rand wrote: > johnyju...@sigaint.org: > >> The "listening" services are less of a concern, since the firewall > >> wouldn't permit any incoming connections to be passed through to start > >> with. It's the "phone home" style services, like time sync, Samba name > >> lookups on microsoft servers, and such, that are more concerning, and > >> privacy-busting. > > > > The paranoid part of me (which is about 95% of me) half-suspects that NTP > > is actively monitored by the powers that be, to keep tabs on us > > security-minded Linux geeks. > > > > There's been enough major security bugs in NTP, that one must wonder if > > they're akin to the heartbleed/rng/SSL/etc. compromises that don't > > necessarily look like innocent mistakes. > > > > Qubes is good at trying to get dom0 to push the time to the VM's by its > > own means. And if you set the ClockVM to sys-whonix, say, you remove, or > > at least greatly reduce, the ability of TPTB to track your setting your > > clock. :) > > > > However, as mentioned, the default of using NTP time syncing is enabled by > > default in the Debian-8 template, which defeats that protection for Debian > > Appvms, unless you disable it in the template. Just an oversight, I'm > > sure. (No sarcasm, for once.) > > > > My PC's RT clock might drift by a few seconds each week, if that; I'm not > > sure why time synchronization has to be so damn frequent and aggressive. > > A red flag for the paranoid. :) > > > > I have a RS232 GPS dongle that spits out the time with 1-second accuracy > > (or atomic-clock level accuracy, if you use the 1-second clock-tick signal > > available on one of the chips, which I have done, lol). > > > > I plan on hooking that up to my Qubes setup in the near future, and > > disabling network-based clock sync all together. > > > > (Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard > > with no RS232 support. :) ) > > > > Might be a good open-sourced hardware project. I think I've seen some out > > there already, although not necessarily integrated smoothly into Qubes. > > > > Just one more hole to make sure we plug. > > > > JJ > > You might find Jake Appelbaum's tlsdate interesting, or Adam Langley's > Roughtime. Both are quite a bit more secure than NTP, although tlsdate > doesn't work with TLS 1.3, and Roughtime is still a proof of concept. > > Cheers, > -Jeremy > Or sdwdate in Whonix -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160927220140.GC5446%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
On Tue, Sep 27, 2016 at 09:13:30PM -, johnyju...@sigaint.org wrote: > > My PC's RT clock might drift by a few seconds each week > > Actually, it's not even that bad. I'm sure I've fired up motherboards or > laptops that haven't been touched in years, and their clocks were accurate > within a minute. > > So there's no need for synchronizing your time so frequently. > > I just read that NTP apparently adjust the frequency of polling based upon > how fast your clock seems to be drifting, which is admirable. > > http://www.ntp.org/ntpfaq/NTP-s-algo.htm > > But the poll interface ranges from 64 to 1024 seconds; even at the high > end, that seems unnecessarily frequent from the very small amount of clock > drift I've experienced. > > But flipping to a GPS-based source instantly eliminates those concerns. > > Question: for what purpose do we require super-accurate clocks in the > first place? There are some rolling password algorithms based upon time, > and certificates handling will get cranky if you're months or years off, > but other than that, what is the necessity of keeping a PC within seconds > of the correct time? > > (On tails, when it starts up, it does a time synchronization, claiming > it's required for Tor purposes. Anyone know the nature of that?) > > JJ > Like many encrypted tunnel setups, Tor requires both ends to have similar date/time. You can easily test this by manually setting to the wrong time, and watching the Tor fail. Tor also checks your local date/time against the consensus status document, and will warn you if it's off. If it's too far, you won't get tunnels. Connecting to Hidden services , I think, requires that local date/time be within 60 mins of the service provider. Tails has a mechanism to set local time. Whonix has a similar mechanism, also available in Whonix-Qubes. 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/20160927215839.GB5446%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
On Tue, Sep 27, 2016 at 12:41:12PM -0700, raahe...@gmail.com wrote: > On Sunday, September 25, 2016 at 9:46:13 AM UTC-4, nishi...@gmail.com wrote: > > Hello, > > > > I am surprised that there is no way to disable ipv6 on Debian template. > > > > I reinstalled first the template using documentation > > https://www.qubes-os.org/doc/reinstall-template/ > > > > Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, I > > did reboot the Template but it didn't change the outcome, I still had ipv6 > > ports opened using "netstat -antp" > > > > I even added "sudo ip6tables -P INPUT DROP" in "/rw/config/rc.local", but I > > still got those distant servers listening when I check using commands like > > "sudo lsof -i6" or "netstat -antp" on my Debian Template. > > > > What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd on > > PID 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes. > > > > Regards > > You have to change kernel parameters a diff way I believe. try this method > from whonix instructions. https://www.whonix.org/wiki/Qubes/Install > > to list the parameters use qvm-prefs -l debian-8 kernelopts > > To change them do qvm-prefs -s debian-8 kernelopts "nopat ipv6.disable=1" > > Then restart template and vms. > As I pointed out, changing parameters in the template will not affect the VMs. You need to change the option individually for each qube where you want to disable IP6. 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/20160927213857.GA5446%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
johnyju...@sigaint.org: >> The "listening" services are less of a concern, since the firewall >> wouldn't permit any incoming connections to be passed through to start >> with. It's the "phone home" style services, like time sync, Samba name >> lookups on microsoft servers, and such, that are more concerning, and >> privacy-busting. > > The paranoid part of me (which is about 95% of me) half-suspects that NTP > is actively monitored by the powers that be, to keep tabs on us > security-minded Linux geeks. > > There's been enough major security bugs in NTP, that one must wonder if > they're akin to the heartbleed/rng/SSL/etc. compromises that don't > necessarily look like innocent mistakes. > > Qubes is good at trying to get dom0 to push the time to the VM's by its > own means. And if you set the ClockVM to sys-whonix, say, you remove, or > at least greatly reduce, the ability of TPTB to track your setting your > clock. :) > > However, as mentioned, the default of using NTP time syncing is enabled by > default in the Debian-8 template, which defeats that protection for Debian > Appvms, unless you disable it in the template. Just an oversight, I'm > sure. (No sarcasm, for once.) > > My PC's RT clock might drift by a few seconds each week, if that; I'm not > sure why time synchronization has to be so damn frequent and aggressive. > A red flag for the paranoid. :) > > I have a RS232 GPS dongle that spits out the time with 1-second accuracy > (or atomic-clock level accuracy, if you use the 1-second clock-tick signal > available on one of the chips, which I have done, lol). > > I plan on hooking that up to my Qubes setup in the near future, and > disabling network-based clock sync all together. > > (Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard > with no RS232 support. :) ) > > Might be a good open-sourced hardware project. I think I've seen some out > there already, although not necessarily integrated smoothly into Qubes. > > Just one more hole to make sure we plug. > > JJ You might find Jake Appelbaum's tlsdate interesting, or Adam Langley's Roughtime. Both are quite a bit more secure than NTP, although tlsdate doesn't work with TLS 1.3, and Roughtime is still a proof of concept. Cheers, -Jeremy -- 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/6179d0f8-9f5b-5180-70dc-b60aec8c0aae%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
> My PC's RT clock might drift by a few seconds each week Actually, it's not even that bad. I'm sure I've fired up motherboards or laptops that haven't been touched in years, and their clocks were accurate within a minute. So there's no need for synchronizing your time so frequently. I just read that NTP apparently adjust the frequency of polling based upon how fast your clock seems to be drifting, which is admirable. http://www.ntp.org/ntpfaq/NTP-s-algo.htm But the poll interface ranges from 64 to 1024 seconds; even at the high end, that seems unnecessarily frequent from the very small amount of clock drift I've experienced. But flipping to a GPS-based source instantly eliminates those concerns. Question: for what purpose do we require super-accurate clocks in the first place? There are some rolling password algorithms based upon time, and certificates handling will get cranky if you're months or years off, but other than that, what is the necessity of keeping a PC within seconds of the correct time? (On tails, when it starts up, it does a time synchronization, claiming it's required for Tor purposes. Anyone know the nature of that?) JJ -- 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/e9811afeee4015304424657087604877.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@gmail.com: > or just only allow https in the vm firewall settings. I assume you mean whitelisting TCP port 443? If so, be aware that while this will stop most non-HTTPS traffic, there is nothing that prevents other protocols from using port 443. It's a fairly well-known attack on Tor's "stream isolation by port" feature for websites to use nonstandard ports in order to get isolated in the wrong Tor circuit (e.g. in order to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by port by default. Whitelisting TCP port 443 is still better than nothing, though, assuming that you don't expect any legitimate traffic to go over other ports. Just be aware that it's trivially easy to bypass for an attacker. Assuming that you're using a Firefox-based browser (including Tor Browser), you can get some defense in depth by also enabling the feature of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong with combining this with the firewall whitelist that you suggested. Cheers, -Jeremy -- 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/8d47d4b9-7ed4-84f4-e697-13db24877024%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
> The "listening" services are less of a concern, since the firewall > wouldn't permit any incoming connections to be passed through to start > with. It's the "phone home" style services, like time sync, Samba name > lookups on microsoft servers, and such, that are more concerning, and > privacy-busting. The paranoid part of me (which is about 95% of me) half-suspects that NTP is actively monitored by the powers that be, to keep tabs on us security-minded Linux geeks. There's been enough major security bugs in NTP, that one must wonder if they're akin to the heartbleed/rng/SSL/etc. compromises that don't necessarily look like innocent mistakes. Qubes is good at trying to get dom0 to push the time to the VM's by its own means. And if you set the ClockVM to sys-whonix, say, you remove, or at least greatly reduce, the ability of TPTB to track your setting your clock. :) However, as mentioned, the default of using NTP time syncing is enabled by default in the Debian-8 template, which defeats that protection for Debian Appvms, unless you disable it in the template. Just an oversight, I'm sure. (No sarcasm, for once.) My PC's RT clock might drift by a few seconds each week, if that; I'm not sure why time synchronization has to be so damn frequent and aggressive. A red flag for the paranoid. :) I have a RS232 GPS dongle that spits out the time with 1-second accuracy (or atomic-clock level accuracy, if you use the 1-second clock-tick signal available on one of the chips, which I have done, lol). I plan on hooking that up to my Qubes setup in the near future, and disabling network-based clock sync all together. (Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard with no RS232 support. :) ) Might be a good open-sourced hardware project. I think I've seen some out there already, although not necessarily integrated smoothly into Qubes. Just one more hole to make sure we plug. JJ -- 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/bf7ec94cf1cebb9c873ff1cdb58667bf.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: I can't disable ipv6 on Debian Template
> Also just to add qubes devs have fedora template with less listening > process then debian-8 which is not default and more community based. But > if you want to use use debian instead for your sysnet or firewall or w/e. > You can disable all the listening processes yourself. It's an outstanding ticket (among a few other related ones): https://github.com/QubesOS/qubes-issues/issues/1928 As compared to all the other stuff the Qubes devs have on their plates, I assume it's a relatively low priority, since Debian-8 is a bit of an "addon" as compared to Fedora-23, and its easy enough for someone to fix in the template themselves. The "listening" services are less of a concern, since the firewall wouldn't permit any incoming connections to be passed through to start with. It's the "phone home" style services, like time sync, Samba name lookups on microsoft servers, and such, that are more concerning, and privacy-busting. I was not pleased to see the Debian vm, by default, connecting to some microsoft servers for Samba name resolution, lol. Especially when I never use any SMB style naming, nor programs, to start with. Cheers JJ -- 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/3d3fd84cfffb6a89a3e285ae6981ea3d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
> How about Google Chromebooks which have a system to auto-restore the OS if > it thinks it's been tampered with..? Doesn't that imply trust in Google, who is known to cooperate with NSA and such (as required by US law)? I have had serious problems with a hacked Android phone, and the "weirdness" went away when I avoided installing Google Play Store/Services. The minute I install Google Play, it appears to be compromised, accessing files and uploading constantly. (A device should download, not upload, lol.) Personally, I have little doubt that Google has backdoors in Play Services for law enforcement, and I also have no doubt that those backdoors have been misused for inappropriate/nefarious purposes (LOVINT style). So Chromebooks, no. Unless everything is open source top to bottom, and I can build it myself. But who has time for that. > Or what about a read-only BIOS in the first place..? > > Is there any reason BIOS can't be read-only..? Lol, that seems like the most basic, logical, simple answer, that I've never seen implemented. A simple switch or jumper could disable the write line on the BIOS flash. In the (very) rare case when you need to flash a BIOS (especially rare on older machines), flipping the switch or connecting the jumper would be such a minor inconvenience. I'm tempted to look up the specs of the flash BIOS chip on my motherboard, and see if I can hack in that tweak myself. I've noticed that with my flashrom reading/comparison, that the beginning of the BIOS area changes when I change BIOS settings, and corresponds to the stuff dumped by 'dmidecode.' Does this mean that your BIOS settings are actually stored in the same flash rom as the BIOS? If so, I'm not necessarily sure that the same write-line-jumper hack is any worse. Maybe even better. It'd also protect against any BIOS setting changes. Are there any BIOS setting changes that *need* to be updated on the fly by the BIOS without user intervention? (If the settings are indeed typically stored in the same flash.) Whenever I reboot, I see some "updating nvvm blah blah blah" thing, which implies that maybe there is some writes to the BIOS settings upon boot. One way to find out, lol... (Looks at soldering iron...) This motherboard is on its last legs (after a poweroff, it's real cranky to wake up, takes reconnecting the power a dozen times or more before it fires up), so experimenting with making the BIOS flash chip read-only isn't a terribly risky project. Will report back with any results if I try it. > I basically want a computer which is most easy to wipe/reinstall and then > it's truly wiped. Computers should have *zero* state in the first place, as in days of old. The state should be kept on your storage devices, operating system, etc.. I seem to recall an article on that particular point, maybe even by the legendary Joanna herself. Google, Google, Google... (Actually, Duckduckgo, Duckduckgo, Duckduckgo): Yeah, it was, God love her: http://blog.invisiblethings.org/2015/12/23/state_harmful.html JJ -- 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/3e701c3a47b5d28743c73423e8f5746d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 3:35:54 PM UTC-4, johny...@sigaint.org wrote: > > On Tuesday, September 27, 2016 at 6:51:31 AM UTC-4, neilh...@gmail.com > > wrote: > >> If I think a computer has been infected, is there anything else I should > >> wipe/re-install other than > >> > >> 1. Hard Drive / Operating System > >> > >> 2. BIOS > > This also brings up the question of BIOS vs. EFI, which has some parallels > to the Ethernet vs. WiFi security discussion in that other exciting > thread. > > EFI supposedly has more lines of code than the Linux kernel, which can't > be good. > > In my opinion, the device drivers should manage the hardware, not the > motherboard's BIOS/EFI. The BIOS should be just enough to get the base > system loaded from disk, and it can do its thing. > > The complexity and attack surface of EFI concerns me, which is why I'm > glad to stick with BIOS, until I'm forced to EFI. (Also, I'm broke, lol. > Another reason I'm sticking with my BIOS-based motherboards.) > > (will Qubes 4.0 force that as well? Likely the newer hardware required > for Qubes 4.0 will be EFI-only, so the question may be moot.) > > I know TPM/Anti-Evil-Maid is an EFI-only thing, and supposedly a useful > (essential?) thing for boot security. But is it worth the massive amount > of extra code involved? > > Any opinions on the BIOS vs. EFI thing, from a security standpoint? > > JJ I agree. Just ask hacking team. Its less secure and imo has no benefits to qubes users if not even using secure boot. If using secure boot then its up for debate. Secure boot would be nice addition to go with aem. Although it seems its a controversial subject because people Like Richard Stallman and Joanna have been talking for a while now of the concerns regarding intel ME/amt/vpro in general as an unchecked balance which can lead to potential unknown backdoors. Richard Stallman actually says he is not against uefi in its current form, only because he considers it a failure for its original intended purpose...lol and secure boot is a reasonalbe use of it. He is against what he calls "restricted boot" which imo is not a warranted concern of mine since I have not run into a retail mobo I could not disable secure boot on or add my own keys to. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b178f9d6-e72a-4477-b1b8-f04dddaac3ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: I can't disable ipv6 on Debian Template
Also just to add qubes devs have fedora template with less listening process then debian-8 which is not default and more community based. But if you want to use use debian instead for your sysnet or firewall or w/e. You can disable all the listening processes yourself. -- 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/16724489-4f37-43d2-aa28-e6c68a48cdf9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: I can't disable ipv6 on Debian Template
On Sunday, September 25, 2016 at 9:46:13 AM UTC-4, nishi...@gmail.com wrote: > Hello, > > I am surprised that there is no way to disable ipv6 on Debian template. > > I reinstalled first the template using documentation > https://www.qubes-os.org/doc/reinstall-template/ > > Then I added "net.ipv6.conf.all.disable_ipv6 = 1" in /etc/sysctl.conf, I did > reboot the Template but it didn't change the outcome, I still had ipv6 ports > opened using "netstat -antp" > > I even added "sudo ip6tables -P INPUT DROP" in "/rw/config/rc.local", but I > still got those distant servers listening when I check using commands like > "sudo lsof -i6" or "netstat -antp" on my Debian Template. > > What is rpcbind, avahi-dae and why you got this ipv6 bound to systemd on PID > 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes. > > Regards You have to change kernel parameters a diff way I believe. try this method from whonix instructions. https://www.whonix.org/wiki/Qubes/Install to list the parameters use qvm-prefs -l debian-8 kernelopts To change them do qvm-prefs -s debian-8 kernelopts "nopat ipv6.disable=1" Then restart template and vms. -- 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/3b7dc079-35be-47c7-a5a3-816ac495d08e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: SUCCESS: GPU passthrough on Qubes 3.1 (Xen 4.6.1) / Radeon 6950 / Win 7 & Win 8.1 (TUTORIAL + HCL)
On Wednesday, June 22, 2016 at 8:26:50 AM UTC-7, Marcus at WetwareLabs wrote: > Hello all, > > I've been tinkering with GPU passthrough these couple of weeks and I thought > I should now share some of my findings. It's not so much unlike the earlier > report on GPU passthrough here > (https://groups.google.com/forum/#!searchin/qubes-users/passthrough/qubes-users/cmPRMOkxkdA/gIV68O0-CQAJ). > > I started with Nvidia GTX 980, but I had no luck with ANY of the Xen > hypervisors or Qubes versions. Please see my other thread for more > information > (https://groups.google.com/forum/#!searchin/qubes-users/passthrough/qubes-users/PuZLWxhTgM0/pWe7LXI-AgAJ). > > However after I switched to Radeon 6950, I've had success with all the Xen > versions. So I guess it's a thing with Nvidia driver initialization. On a > side note, someone should really test this with Nvidia Quadros that are > officially supported to be used in VMs. (And of course, there are the hacks > to convert older Geforces to Quadros..) > > Anyway, here's a quick and most likely incomplete list (for most users) for > getting GPU passthrough working on Win 8.1 VM. (works identically on Win7) > > Enclosed are the VM configuration file and HCL file for information about my > hardware setup (feel free to add this to HW compatibility list!) > > TUTORIAL > > Check which PCI addresses correspond to your GPU (and optionally, USB host) > with lspci.Here's mine: > ... > > > # lspci > > 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Cayman XT [Radeon HD 6970] > 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles > HDMI Audio [Radeon HD 6900 Series] > Note that you have to pass both of these devices if you have similar GPU with > dual functionality. > > Edit /etc/default/grub and add following options (change the pci address if > needed): > > GRUB_CMDLINE_LINUX=" rd.qubes.hide_pci=03:00.0,03:00.1 > modprobe=xen-pciback.passthrough=1 xen-pciback.permissive" > GRUB_CMDLINE_XEN_DEFAULT="... dom0_mem=min:1024M dom0_mem=max:4096M" > > For extra logging: > > > GRUB_CMDLINE_XEN_DEFAULT="... apic_verbosity=debug loglvl=all > guest_loglvl=all iommu=verbose" > > There are many other options available, but I didn't see any difference in > success rate. See here: > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html > http://wiki.xenproject.org/wiki/Xen_PCI_Passthrough > http://wiki.xenproject.org/wiki/XenVGAPassthrough > > Update grub: > > # grub2-mkconfig -o /boot/grub2/grub.cfg > Reboot. Check that VT-t is enabled: > > # xl dmesg > ... > (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB. > (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > Check that pci devices are available to be passed: > > # xl pci-assignable list > :03:00.0 > :03:00.1 > Create disk images: > > # dd if=/dev/zero of=win8.img bs=1M count=3 > # dd if=/dev/zero of=win8-user.img bs=1M count=3 > Install VNC server into Dom0 > > # qubes-dom0-update vnc > Modify the win8.hvm: Check that the disk images and Windows installation > CDROM image are correct, and that the IP address does not conflict with any > other VM (I haven't figured out yet how to set up dhcp) Check that 'pci = [ > ]' is commented for nowStart the VM ( -V option runs automatically VNC > client) > > # xl create win8.hvm -V > > If you happen to close the client (but VM is still running), start it again > with > > > # xl vncviewer win8 > Note that I had success starting the VM only as root. Also killing the VM > with 'xl destroy win8' would leave the qemu process lingering if not done as > root (if that occurs, you have to kill that process manually) > Install WindowsPartition the user image using 'Disk Manager'Download signed > paravirtualized drivers here (Qubes PV drivers work only in Win > 7):http://apt.univention.de/download/addons/gplpv-drivers/gplpv_Vista2008x64_signed_0.11.0.373.msi > Don't mind the name, it works on Win 8.1 as well. > For more info: > http://wiki.univention.com/index.php?title=Installing-signed-GPLPV-drivers > > Move the drivers inside user image partition (shut down VM first): > > # losetup (Check for free loop device) > # losetup -P /dev/loop10 win8-user.img (Setup loop device and scan > partition. Assuming loop10 is free) > # mount /dev/loop10p1 /mnt/removable ( Mount the first partition )- copy the > driver there and unmount. > > Reboot VM, install paravirtual drivers and reboot againCreate this script > inside sys-firewall (check that the sys-net vm ip address 10.137.1.1 is > correct though): > > fwcfg.sh: > #!/bin/bash >
Re: [qubes-users] Screen geometry for VMs
On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote: > Wow... The problem is that gui-agent have hardcoded maximum of 4 > outputs[1]. The number is totally arbitrary, can be changed to > anything. Any ideas for better value? Apparently 4 isn't large > enough... That's good to know, and that explains the weird clipping - the usable monitors are actually the ones connected to port 0-3 (i.e. the FIRST four monitors). > Another possible problem: what is your total resolution (across all > the outputs)? The max supported is 32767x32767. That's not a problem - my actual resolution is 3840x2048. I don't like hi-res (i.e. 4K) monitors :) So should I be able to recompile gui-agent with a maximum of 6 monitors, that should work, you say? But I'd really love to stick with the automatic upgrades :/ This workstation has actually been build for work, so I'd avoid too much software customization... Would that be ok to use a maximum of 16, just to say another number? It seems that the increased memory usage would still be negligible. Btw thank you Marek for your speedy response. Since my setup seems to have sparked some curiosity, here's a just-shot badly lit photo of it: http://tinypic.com/r/etd2kn/9 yes, that Ikea lamp is my version of ambi-light and I do not like to have a desk. The stand is a large-panel-TV stand from Amazon, converted to a multi-monitor stand with a couple horizontal iron bars, and my keyboard is on a stand-alone cart (was from an IKEA office chair), and the mouse is that blue 3d-printed thing on the top-right corner of the keyboard. It's an IBM trackpoint, with 3d-printed holder and cap, and it's incredibly useful in avoiding repetitive strain injuries coming from standard mice. The keyboard is a Model M from Unicomp, but they don't make any with a trackpoint where I like it most - on the top right. -- Alex -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0ae47311-7bf1-76f9-e88a-38d8a749edcd%40gmx.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
> On Tuesday, September 27, 2016 at 6:51:31 AM UTC-4, neilh...@gmail.com > wrote: >> If I think a computer has been infected, is there anything else I should >> wipe/re-install other than >> >> 1. Hard Drive / Operating System >> >> 2. BIOS This also brings up the question of BIOS vs. EFI, which has some parallels to the Ethernet vs. WiFi security discussion in that other exciting thread. EFI supposedly has more lines of code than the Linux kernel, which can't be good. In my opinion, the device drivers should manage the hardware, not the motherboard's BIOS/EFI. The BIOS should be just enough to get the base system loaded from disk, and it can do its thing. The complexity and attack surface of EFI concerns me, which is why I'm glad to stick with BIOS, until I'm forced to EFI. (Also, I'm broke, lol. Another reason I'm sticking with my BIOS-based motherboards.) (will Qubes 4.0 force that as well? Likely the newer hardware required for Qubes 4.0 will be EFI-only, so the question may be moot.) I know TPM/Anti-Evil-Maid is an EFI-only thing, and supposedly a useful (essential?) thing for boot security. But is it worth the massive amount of extra code involved? Any opinions on the BIOS vs. EFI thing, from a security standpoint? JJ -- 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/d76dee67e2aa4a7900661db546b89eba.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 2:56:27 PM UTC-4, johny...@sigaint.org wrote: > > I forget which blackhat event, they showed how you can think you are > > flashing a bios. But the malware will remain. > > That's creepy. Don't most BIOS flashing utilities do a verification? Or > perhaps the flashing utility itself is what was compromised in the > blackhat demo. > > Another reason why doing a flashrom under Tails, and then reading it back, > is a good idea of your motherboard supports it. Pretty hard for malware > to fake that (at least without some additional flash storage to do its > tricks). > > At the very least, using a slightly "unexpected" utility like flashrom > helps dodge the obvious hacks. > > (Similar to someone's post in reply to the Laptop internet sharing thread, > that using a *different* VM isolation on the laptop, KVM/Qemu or whatever, > might be a good idea. For an attacker to have to compromise Xen *and* > Qemu, makes for a busy project to say the least. It'd very likely stop > any automated virus in its tracks.) > > JJ regarding kvm/qemu, you probably need to use an hvm and its probably diffucult to set up. Probably would also run very slow. Not worth it imo. If your bios or dom0 gets compromised its already game over. -- 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/bb847c48-8f39-4c73-ac7d-59cb5feace57%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Screen geometry for VMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Sep 27, 2016 at 08:47:27PM +0200, Alex wrote: > Hi everybody, > I'm back with a brand-new workstation setup to try Qubes on. I bought a > Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm > using Qubes R3.2 fully updated as of now, with XFCE. Wow... The problem is that gui-agent have hardcoded maximum of 4 outputs[1]. The number is totally arbitrary, can be changed to anything. Any ideas for better value? Apparently 4 isn't large enough... Another possible problem: what is your total resolution (across all the outputs)? The max supported is 32767x32767. [1] https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/xf86-video-dummy/src/dummy.h#L16 - -- 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 iQEcBAEBCAAGBQJX6sY0AAoJENuP0xzK19csapIH+wTveF24xDCycE8nFMeM9Xyv L4XS/rVPNYsBT3LzNBXkAXVNDFqFOWSK6/biRayQa6G3FpkxbXtxspvNPDXMLgBB x381ZPjGF3MumL+kUIj9ouElFXmkedqVpifi6xe91DcwPzx79hCetmnIDgYfhnJS q5hFCvjVKGaLnYez2TicvgjLXYR1wHKu65MhCPTppWDWhAhqQe57T5vFiwkKe/N9 aAWkvxcW8v5+GWFLGffgnnduxEAbe7HKgLlKfoT+o3LgYGYwNB5OnNvK7RwAfuIZ eTwyIMIJbGiGP2AsOQH7DWsU9cQaK9LG4LvimuXE/TipUPWPDObfv8vSTZkmwXc= =OHC9 -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/20160927191916.GH31510%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 2:56:27 PM UTC-4, johny...@sigaint.org wrote: > > I forget which blackhat event, they showed how you can think you are > > flashing a bios. But the malware will remain. > > That's creepy. Don't most BIOS flashing utilities do a verification? Or > perhaps the flashing utility itself is what was compromised in the > blackhat demo. > > Another reason why doing a flashrom under Tails, and then reading it back, > is a good idea of your motherboard supports it. Pretty hard for malware > to fake that (at least without some additional flash storage to do its > tricks). > > At the very least, using a slightly "unexpected" utility like flashrom > helps dodge the obvious hacks. > > (Similar to someone's post in reply to the Laptop internet sharing thread, > that using a *different* VM isolation on the laptop, KVM/Qemu or whatever, > might be a good idea. For an attacker to have to compromise Xen *and* > Qemu, makes for a busy project to say the least. It'd very likely stop > any automated virus in its tracks.) > > JJ Here is interesting thread on reddit i Just found. https://www.reddit.com/r/badBIOS/comments/319qlf/spi_programmers_to_flash_bios_rootkits_bios/ -- 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/453b8817-8e0d-4f1c-9add-9271444eeaf7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Screen geometry for VMs
> I'm back with a brand-new workstation setup to try Qubes on. I bought a > Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm > using Qubes R3.2 fully updated as of now, with XFCE. Six monitors??? Wow! Can I come over and hang out at your place? JJ -- 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/c73d9f35f04b57bc1517e92679942933.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?
> I forget which blackhat event, they showed how you can think you are > flashing a bios. But the malware will remain. That's creepy. Don't most BIOS flashing utilities do a verification? Or perhaps the flashing utility itself is what was compromised in the blackhat demo. Another reason why doing a flashrom under Tails, and then reading it back, is a good idea of your motherboard supports it. Pretty hard for malware to fake that (at least without some additional flash storage to do its tricks). At the very least, using a slightly "unexpected" utility like flashrom helps dodge the obvious hacks. (Similar to someone's post in reply to the Laptop internet sharing thread, that using a *different* VM isolation on the laptop, KVM/Qemu or whatever, might be a good idea. For an attacker to have to compromise Xen *and* Qemu, makes for a busy project to say the least. It'd very likely stop any automated virus in its tracks.) JJ -- 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/ffcae9624e249cbad5d63a261173cf47.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
>> Especially if you did the sharing via a separate vpn or ssh tunnel. But >> in general, I don't think Qubes security should be considered much if >> any benefit to adjacent non-Qubes systems. >> >> Chris >> >> > The benefits far outweigh the risks, as long as you don't do most of >> your >> > critical browsing/email through unencrypted connections; in which case >> > your probably screwed anyway :). >> > >> > JJ >> > > > or just only allow https in the vm firewall settings. That's a wonderfully simple solution that never crossed my mind. (My VPN ProxyVM is only allowed to send packets to specific VPN servers on the given port, using the firewall, which is a bit of a parallel to that. Great peace of mind for stopping leaks of unencrypted data.) JJ -- 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/5068e719853d90f9b3551cca68a41026.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Screen geometry for VMs
Hi everybody, I'm back with a brand-new workstation setup to try Qubes on. I bought a Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm using Qubes R3.2 fully updated as of now, with XFCE. Long story short, dom0 is able to use all six monitors in the configuration I set up (two rows, three monitors each row) - it was not that easy, had to manually fix the numbers in ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml because the graphical display configuration tool kept being a couple of pixels off, and it was very frustrating. Anyway my problem is with AppVMs. Once they are started, it seems like their virtual screen is "clipped" with respect to that of dom0. Namely, when I try to perform any mouse action on windows in the first two monitors (top-left and top-middle), nothing happens in the appVM windows contents (i.e. they do not react to any event, hover nor click). I've had this problem before, and that was when the screen geometry changed after the VMs were started - I used to have a Qubes laptop, and changing the display placement in dom0 after VMs were started did result in clipped "virtual screens". My question is: does Qubes R3.2 support notifying screen change event to AppVM? would that be a security problem? Is there a way for me to "tell" specific AppVMs that dom0's screen geometry has changed, maybe telling the new situation too? Simpler; since my situation is fixed (i.e. I won't be adding nor moving any monitors around), can I fix this once and for all by copying the same geometry I put in my user's XFCE configuration into some global XFCE file? I noticed that VMs are started with the login-screen display geometry, but that is changed to the actual displays.xml settings once the user logs in, so maybe setting that as the default geometry could change the virtual screen seen by AppVMs... Could that work? TIA, -- Alex -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7b4f306d-06e5-e961-f7c4-ca3b9f187186%40gmx.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 2:31:33 PM UTC-4, johny...@sigaint.org wrote: > > If I think a computer has been infected, is there anything else I should > > wipe/re-install other than > > > > 1. Hard Drive / Operating System > > > > 2. BIOS > > > > Is there anything else that a hacker could possibly infect that needs to > > be wiped/re-installed..? > > Lol, don't get me started... > > - Any PCI card (esp Network/Video/Sound) that has any kind of flashable > firmware > > - Similarly, probably any PCMCIA cards > > - Any USB peripheral, especially flash drives; sadly, I don't think > there's any way to verify your HD firmware hasn't been tampered with > (write only, typically), and flash drives vary so much, it's not > particularly practical to check/clean them. Some flash drive vendors have > repair tools that can redo the BIOS (handy when the drive appears to get > pooched), but it's fairly rare to find, I think. > > - SMB/DMI Bios Tables (as shown by dmidecode) - Related to the BIOS, and I > think cleansed when you reflash your BIOS. Even so, it's good to maybe > pop your motherboard battery or short out any BIOS-reset jumper to make > sure you're starting with clean settings. > > - Basically, anything that can carry state needs to be looked at (although > your RTC probably doesn't have an attack vector :) ) > > - I've heard that rogue printers can even keep copies of what you print. > I'm not sure if this can happen from an infection, or if it needs to be a > factory/interdiction implant. Doubtful if such a thing could be cleansed. > > I feel like I'm missing something else, but I might be thinking of more > hardware-based attacks (fake chokes on video cables that broadcast, etc.) > > On-board peripherals (sound, network, video) typically have their firmware > as chunks in the main motherboard BIOS, I believe, so re-flashing a fresh > BIOS takes care of those. > > A major oddity and frustration is that so many motherboard manufacturers > only provide their BIOS's via FTP/HTTP (and don't provide hashes!), just > begging to be MITM'd with dodgy firmware during download. So careful with > any downloads. > > It's a good idea to run the BIOS (and any firmware you download) through > virustotal.com, which supposedly supports BIOSes now. You will typically > see that it's already been checked in the past by someone else, and is > clean. > > Similarly, if you have to boot DOS to run a firmware flash utility, be > careful. I've used FreeDOS successfully in the past, but the motherboards > I use thankfully support the Linux utility "flashrom" which seems to be > able to successfully burn (and read) the BIOS on a lot of motherboards and > other devices. > > (Of course, you always run the risk of bricking your system, but I think > it's generally pretty safe, and won't go ahead if it isn't capable on your > system.) > > I occasionally use FlashROM (installable with apt under Tails, and I use > it while offline) to read and compare my BIOS against the original fresh > burn. (I'll see the DMI tables at the beginning change as I make any BIOS > changes, but so far, no mods to the code. :) ) > > I'd like to see FlashROM available in dom0 for the ability to do this > under tails. But I guess that would be a super-dangerous utility to have > floating around dom0, so rebooting to Tails now and then to check my BIOS > is an acceptable inconvenience. > > Oh, and before you do reflash your BIOS, boot into Tails (or Debian, > Redhat, whatever) install FlashROM, and do a "flashrom -r" to read the > existing BIOS for posterity. Run the resulting file through VirusTotal. > It's interesting to compare with another "flashrom -r" after re-flashing > the new BIOS. > > It'd be good to catch any corrupt BIOS before you overwrite it, to know if > you've been compromised that way, and to share the particular hack with > the security community. > > Related: > http://www.businessinsider.com/nsa-says-foiled-china-cyber-plot-2013-12 > > (Hey, thanks for looking out for us, NSA!) > > Note that any contents of a .ROM file you download to burn, won't > necessarily compare exactly to the results of a "flashrom -r". But if you > "flashrom -r oldbios.rom", burn a fresh BIOS, and do another "flashrom -r > newbios.rom", you should have a good base for comparison. I do a "hexdump > -C" on each .rom file, and then diff them to see what's different. > > If you end up upgrading your ROM in the process, obviously there will be a > number of differences. The more interesting thing is if VirusTotal shows > anything, or if, down the road, you notice changes in subsequent "flashrom > -r"'s. If anything other than the SMB/DMI tables at the beginning change, > you need to assume you've been compromised (again). > > (flashrom needs a "--programmer internal" option, which I left out for > clarity above.) > > Obviously, any hard drive's boot sector should be examined as well. If > you're worried about compromise, you're
[qubes-users] Re: Anything else to wipe other than HDD and BIOS..?
On Tuesday, September 27, 2016 at 6:51:31 AM UTC-4, neilh...@gmail.com wrote: > If I think a computer has been infected, is there anything else I should > wipe/re-install other than > > 1. Hard Drive / Operating System > > 2. BIOS > > Is there anything else that a hacker could possibly infect that needs to be > wiped/re-installed..? > > Thanks any other firmware pci/dma devices attached to the system can be infected. BIOS might not even securely flash properly depending how you are doing it. For example doing it from operating system (DOS) might not be truly removing the malware. Might need a special dedicated device to flash it or ask company to send you a new bios chip to solder on. to be 100% sure you need to buy a new pc unfortunately lol. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1ac612b6-1f05-4406-9880-a86253e8a2ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anything else to wipe other than HDD and BIOS..?
> If I think a computer has been infected, is there anything else I should > wipe/re-install other than > > 1. Hard Drive / Operating System > > 2. BIOS > > Is there anything else that a hacker could possibly infect that needs to > be wiped/re-installed..? Lol, don't get me started... - Any PCI card (esp Network/Video/Sound) that has any kind of flashable firmware - Similarly, probably any PCMCIA cards - Any USB peripheral, especially flash drives; sadly, I don't think there's any way to verify your HD firmware hasn't been tampered with (write only, typically), and flash drives vary so much, it's not particularly practical to check/clean them. Some flash drive vendors have repair tools that can redo the BIOS (handy when the drive appears to get pooched), but it's fairly rare to find, I think. - SMB/DMI Bios Tables (as shown by dmidecode) - Related to the BIOS, and I think cleansed when you reflash your BIOS. Even so, it's good to maybe pop your motherboard battery or short out any BIOS-reset jumper to make sure you're starting with clean settings. - Basically, anything that can carry state needs to be looked at (although your RTC probably doesn't have an attack vector :) ) - I've heard that rogue printers can even keep copies of what you print. I'm not sure if this can happen from an infection, or if it needs to be a factory/interdiction implant. Doubtful if such a thing could be cleansed. I feel like I'm missing something else, but I might be thinking of more hardware-based attacks (fake chokes on video cables that broadcast, etc.) On-board peripherals (sound, network, video) typically have their firmware as chunks in the main motherboard BIOS, I believe, so re-flashing a fresh BIOS takes care of those. A major oddity and frustration is that so many motherboard manufacturers only provide their BIOS's via FTP/HTTP (and don't provide hashes!), just begging to be MITM'd with dodgy firmware during download. So careful with any downloads. It's a good idea to run the BIOS (and any firmware you download) through virustotal.com, which supposedly supports BIOSes now. You will typically see that it's already been checked in the past by someone else, and is clean. Similarly, if you have to boot DOS to run a firmware flash utility, be careful. I've used FreeDOS successfully in the past, but the motherboards I use thankfully support the Linux utility "flashrom" which seems to be able to successfully burn (and read) the BIOS on a lot of motherboards and other devices. (Of course, you always run the risk of bricking your system, but I think it's generally pretty safe, and won't go ahead if it isn't capable on your system.) I occasionally use FlashROM (installable with apt under Tails, and I use it while offline) to read and compare my BIOS against the original fresh burn. (I'll see the DMI tables at the beginning change as I make any BIOS changes, but so far, no mods to the code. :) ) I'd like to see FlashROM available in dom0 for the ability to do this under tails. But I guess that would be a super-dangerous utility to have floating around dom0, so rebooting to Tails now and then to check my BIOS is an acceptable inconvenience. Oh, and before you do reflash your BIOS, boot into Tails (or Debian, Redhat, whatever) install FlashROM, and do a "flashrom -r" to read the existing BIOS for posterity. Run the resulting file through VirusTotal. It's interesting to compare with another "flashrom -r" after re-flashing the new BIOS. It'd be good to catch any corrupt BIOS before you overwrite it, to know if you've been compromised that way, and to share the particular hack with the security community. Related: http://www.businessinsider.com/nsa-says-foiled-china-cyber-plot-2013-12 (Hey, thanks for looking out for us, NSA!) Note that any contents of a .ROM file you download to burn, won't necessarily compare exactly to the results of a "flashrom -r". But if you "flashrom -r oldbios.rom", burn a fresh BIOS, and do another "flashrom -r newbios.rom", you should have a good base for comparison. I do a "hexdump -C" on each .rom file, and then diff them to see what's different. If you end up upgrading your ROM in the process, obviously there will be a number of differences. The more interesting thing is if VirusTotal shows anything, or if, down the road, you notice changes in subsequent "flashrom -r"'s. If anything other than the SMB/DMI tables at the beginning change, you need to assume you've been compromised (again). (flashrom needs a "--programmer internal" option, which I left out for clarity above.) Obviously, any hard drive's boot sector should be examined as well. If you're worried about compromise, you're going to scrub your disks anyway. I usually do a regular "dd if=/dev/sda of=latest.img bs=512 count=2048", and compare against a saved baseline image that I grabbed after a fresh install. Any changes to the MBR, Grub stage 2 will be noticed with a comparison against the original. Any
Re: [qubes-users] Outdated documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-09-27 06:45, Robert Mittendorf wrote: > Hey Qubes-Team, > > https://www.qubes-os.org/doc/hvm/ > > states that "shared templates for HVM domains" are not supported. > > This is an outdated information, isn't it? > > Robert > Correct. Removed. Thanks! - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX6rSzAAoJENtN07w5UDAwac0P/129bUsSOvCbWtrMMZVq22RE jA3Tjd6ejwlsqnMKLratBZKXYM9yzu/hFmDZCoCo2TRbm7pfIAZgQhC1ALqSYway gWmZ6jPiEczA1rtUrXdxGzIYRmWPvdOyjXZQHk5c9xAmkcfzg8w0c3revJsTyf0k momWI5Vn2s4SKoP1wVGS2tmNWY0wd7mAQruDVqngE81PQLAI9Dd0oewdp6fdAW6R Vyqrqe4L8SPwQFlDlUNGeQChACQ13p38ePx6shEu5QCd4VLigYPMIuOiJPlF6MPB UROSPLu2mcadKfP0Ys8z+4yxVpujm/DU5UMZvOOK35zU1wZKtPiwL3cCKVDhM+ab xREqMUpQDxvLMBoNV1fq95JOyGjCR+j9Ip3tIrLqwoqUIfmnbPQaq9SV8YF4KXw/ QL+FHIob2F+y4baO7oo211Iwk+k9CEd8OvmrlaoB6C/nEtFrz2ttqi4RrH9DKc8n oHARgWZguWQkdECR55Co87n3tlB/iA0SQUrIbsZN1JFRlktQp1f+A8RiZOPP9s8q XAkKnCBfKXoQY7LC+hl2cktir9zc+IQ6SwKssDNA2EhFjYIZRvROQ578wmw+MMUX vQ+Il7NYcNXXQJGVZAMT7myJGq9PMwnl/psdLy+mZjHnjqtPRzn6ZuxlRI7ivOJA knGS0UjiZbmY9v/FlkXr =m/jr -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/ad264f55-0168-7ae4-25be-8198d08391ed%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On Sunday, September 25, 2016 at 7:32:34 AM UTC-4, Chris Laprise wrote: > On 09/25/2016 07:08 AM, johnyju...@sigaint.org wrote: > >> Let's say I have a Qubes machine connected to a 2nd laptop by Ethernet. > >> > >> The Qubes machine is sharing its Internet connection. > >> > >> Let's say the Qubes machine gets hit with a DMA attack. > >> > >> The 2nd laptop is not a Qubes machine, and therefore doesn't have VT-D for > >> DMA protection. > >> > >> Can the DMA attack be "carried forward" to the 2nd laptop... or is it > >> killed for good by the Qubes machine..? > > My take on it: > > > > If the Qubes machine is hit by a DMA attack, it is compromised and could > > thus tamper with the forwarded Internet connection however the attacker > > desires. (As well as scraping any credentials you might use in common on > > the Qubes box, and carrying out aggressive attacks on anything on your > > network.) > > > > So a compromised machine couldn't specifically "forward" a DMA attack per > > se, but it has full control of the Internet connection and traffic to and > > from the laptop. > > I think this should be clarified... > > Qubes users' typical idea of a DMA attack is one that's initiated as a > network-bourne attack against the NIC. Then, once malware has control of > the NIC, the actual DMA attack can take place against whatever processes > are running in the machine. > > Inside Qubes, that's not a huge deal because the NIC's DMA is contained > in sys-net and the other (downstream vms) don't have hardware NICs that > can also be attacked. The netvm can try to mess with the traffic of your > connected vms, but you might be using a proxyvm gateway (running openvpn > or whonix/tor) in which case the netvm malware is pretty helpless... it > could try to do sidechannel attacks but the topic here is DMA attacks. > > > Any unencrypted net connections could be spied upon, tampered with, > > MITM'd, injecting spyware (which may in turn use a DMA attack itself, or > > 0day exploits, or whatever) into an unencrypted mail/http connection, for > > example. > > That's why applications should use SSL/TLS just as a routine matter. In > some vms, you might even want to set 'Https Everywhere' to only allow Https. > > > I'd say it's no more risky than what a crooked ISP, a hacked Cable Modem, > > or anything else upstream in the net connection could achieve. > > > > Any strongly encrypted connection (Tor, OpenVPN, HTTPS without state-actor > > CA certificate tampering/spoofing, etc.) should be safe, other than > > potential denial-of-service which would be pretty noticeable. > > > > I would say having the Qubes box between the laptop and the Internet > > generally increases the safety of the laptop. > > Especially if you did the sharing via a separate vpn or ssh tunnel. But > in general, I don't think Qubes security should be considered much if > any benefit to adjacent non-Qubes systems. > > Chris > > > The benefits far outweigh the risks, as long as you don't do most of your > > critical browsing/email through unencrypted connections; in which case > > your probably screwed anyway :). > > > > JJ > > or just only allow https in the vm firewall settings. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/43280b8f-0548-40df-8d5d-8e46cd584d3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. > This is fine as long as you trust the USB device you're attaching to dom0. If you don't, consider using a USB qube instead: https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube > Questions: > 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message > stating no place on device and a zero byte backup file. Permissions are OK, > there's more than enough space on the HDD. > Any reasons why the backup did not succeed? > Are you sure you selected the correct device in the menu? > 2. I tried running qvm-backup from the command line, which ran fine, no > permission problems on the same HDD. However, the template VMs are not > included by default and I saw no command-line option to automatically achieve > this. Am I missing something here? > The RPM-managed TemplateVMs should normally not be backed up. Instead, you should clone them (if you can spare the drive space), make your customizations, then back up the clones. > 3. I know I can manually list all the VMs on the command line to be backed > up, but I find that a bit awkward, so I tried this: > qvm-ls --raw-list | xargs qvm-backup /mnt/test/ > > but this threw a Python exception... > > For now I resorted to typing all the VMs by hand ... not elegant. > > Any help is appreciated. > Try this: $ qvm-backup /mnt/test/ `qvm-ls --raw-list` You can also prepare a list of VMs (one VM name per line) as a file, then: $ qvm-backup /mnt/test/ `cat vm_list.txt` - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX6rLjAAoJENtN07w5UDAwuJQQAMu+Wfr56Bmf6bmJVCrZWY76 ZosTo+0ouB7jBYcoplACyirVmXjhFK3G9AFKRnpNZ3qo7m9w3rWD6cgbYwv88yfW nTJZBV88xqQqLGjqz3+OCi84/sfpOgIC8tXhzZndKcGb+5yd0FxRgZhZg4shdJ4d DoBX2hAfwzaUG9FCH7spaIFE5XPeOXNlK+ft5kuhbstWxGsFz7plf1ibrRii+Z2U DNamPVhAD6x4/cIzakb57SJ4BWcDoCuyeeG0ICpHyTjEMBq3GH0pvt4bVsSIWUC8 3LrUYAkuKrtxeSBHuJ0eAMilpkz9rld8tl58FUiMW1ZkanSYYB/GV8ENhAruFvVL bvlgJ0vsOBg1FRXGC8LUUsXiw2owUP4z7Dgtl3Q5eZ+Zb1K/OAdbnmrkXbu/PpiR E50qQig/Ugxlg9XDdWCgANfFRfhdi2btA+qfP7aSJt+0Kf60GxmQtUGbHm+Q0ECP L03ZEFG33K/3xu26CFXjWQRwlFGMAAUF5BEiFuLDJ96rhwU5blHjV/lZ1e1rEyv1 uRjdJ06slyv78uLanqIXyMqH1nXBlu/RyayrqTJW1Jdo0GX3iSoF7SR1A8zPbf3r 3d/PmRfY2/1/okIcFYc0tkqq9fTvi0M+ixVIdPmYzoVuzsiP/y5tBM+7CT5YxY+q 0KnOMeWlDzFguSEdha+e =KRMx -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/d7357dd5-7283-2368-17c0-2f88113418dc%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] System still freezes, still no resolution.
On Monday, September 26, 2016 at 4:00:38 AM UTC-4, Drew White wrote: > On Monday, 26 September 2016 15:31:19 UTC+10, Foppe de Haan wrote: > > usb input devices? if so, can you attach a ps/2 mouse/keyboard and does > > that do anything? also, maybe have a look at bios settings related to > > (sleep/wake from) usb? > > Doesn't matter. > USB or not, it doesn't respond to input. Is your issue after a wake from suspend? Desktop freezes on me on one machine if it is left asleep for too long. I figure its related to bios or what vms were running when it went to sleep. I also find its less of a problem on kde then on xfce. In my case it also seems to happen more often if i wake machine up from power button rather then a keyboard press. -- 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/cb164323-fabb-44d8-8942-5d156f7136c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
'Gabriel' via qubes-users: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. You can backup a subset of VM's from the GUI. I typically backup every VM except the USB VM (with the external HDD attached to the USB VM and mounted in a DispVM), under the assumption that if I'm ever restoring to a fresh Qubes install, there will already be a USB VM there, so backing up the USB VM isn't really needed. Cheers, -Jeremy -- 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/58032d10-22a7-7c1b-8ee1-bd95c4ba563a%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] I can't disable ipv6 on Debian Template
"An agenda against Qubes goal". Lol, that would been really arrogant because I joined Linux only 3 months ago and I have everything to learn. But if you want to talk about what Qubes provides, I have my opinion on the subject : Qubes greatest innovation is kinda making business of privacy rights, you can either consider it as a very offensive hacking tool platform, a Kali Linux best ally, a weapon which imo can do more harm than good, either a noob trap. That's obviously not the way I want the Internet to evolve, if you don't mind. As if posting here with this very friendly PRISM data collection provided by Google would make Qubes community trustworthy. What a joke. If M. Snowden would have used Qubes instead of Tails to make his revelations to everyone about global surveillance, he would probably be in jail right now. I guess vast majority of folks shocked about what his revelations showed would be really unhappy about that. So for people really considering privacy rights in an opened and a good manner way, you have Tails, and when it's time to discuss about security by default on a fresh new system, you have OpenBSD. Rest is just business and making profits under a license you currently don't own. Richard Stallman would be proud. Also when you can read on the Whonix FAQ https://www.whonix.org/wiki/FAQ#Why_aren.27t_you_using_OpenBSD.2C_it.27s_the_most_secure_OS_ever.21.21.211.21 this very arrogant statement "There is now Qubes OS, OpenBSD lacks such innovative security improvements, which claims.", you got another big joke right there. What makes the Internet still a little bit secured right now is coming directly from MIT and Unixmen that developed OpenSSH. I guess showing more respect for an OS that has been compromised like 2 times in 20 years and which policies are what the Internet world needs might help. But yeah, you can think of the Internet as a battleground, I don't really mind, it's not the way I see it. You have people concerned about building inoffensive fortresses or shields, to make sure Internet stays what it was at the very beginning (a space to provide educational content, to share ideas in a peaceful way) and you have people that use it as if it was a weapon. What a shame. So long Qubes. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f6121585-274a-462e-908c-a847c100561c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] New version of Qubes Screenshot Tool (0.5 beta)
bump -- 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/a10a143b-6819-f1c7-b270-8302022cbc8b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Blank screen after 10 minutes
On 09/25/2016 05:36 PM, Marek Marczykowski-Górecki wrote: What about disabling xscreensaver completely for 120 mins? Something like: xscreensaver-command -exit sleep 7200 xscreensaver & No settings are changed, so unexpected system reboot isn't a problem. Easy, if it's safe(?) :) Seems, I can do the tool. -- 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/9b91258a-aab2-9b22-9721-cdfb4eddca09%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] backup
Hi fellows, I started using qubes a while ago and I have a question concerning backups. What I want is a complete backup to a dedicated external USB HDD. I understand to achieve this all the VMs must be shut down. Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. Questions: 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message stating no place on device and a zero byte backup file. Permissions are OK, there's more than enough space on the HDD. Any reasons why the backup did not succeed? 2. I tried running qvm-backup from the command line, which ran fine, no permission problems on the same HDD. However, the template VMs are not included by default and I saw no command-line option to automatically achieve this. Am I missing something here? 3. I know I can manually list all the VMs on the command line to be backed up, but I find that a bit awkward, so I tried this: qvm-ls --raw-list | xargs qvm-backup /mnt/test/ but this threw a Python exception... For now I resorted to typing all the VMs by hand ... not elegant. Any help is appreciated. Best, Gabe Sent with [ProtonMail](https://protonmail.com) Secure Email. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/zCWKQXq5-iWoiqonoLuMnWRCPGbQlTqt7ynO8NCwUR_yrxmvRnC9l5fZUSX_zQsl9tUkxFJgZcJpnCOmLpecKQHH0Lhh5mpGda4bKHFwJmA%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Outdated documentation
Hey Qubes-Team, https://www.qubes-os.org/doc/hvm/ states that "shared templates for HVM domains" are not supported. This is an outdated information, isn't it? Robert -- 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/831a6112-86c2-3b4e-2bbf-6b16079ddd27%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] exit code 1 of qubes.RecieveUpdate, what does it mean? Failing to install dev packages in dom0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Sep 27, 2016 at 12:53:54PM +0200, Tobias Abenius wrote: > On 09/23/2016 03:22 PM, Marek Marczykowski-Górecki wrote: > > > > '/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates > > > /usr/lib/qubes/qfile-agent > > > /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1! > > Check /var/log/qubes/qrexec.sys-firewall.log. I'd guess it is something > > about package signature verification. > Thank you for your reply. That last lines of the file is not informative: > > Rpc allowed: sys-firewall dom0 qubes.NotifyUpdates > Rpc allowed: sys-firewall dom0 qubes.ReceiveUpdates > > What next? Ah, error messages from qrexec services are now forwarded to journald - check `journalctl -b` and search for qubes.ReceiveUpdates. - -- 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 iQEcBAEBCAAGBQJX6lO5AAoJENuP0xzK19csZ2wIAJq8IrYAYIui8MzV0kjnXt2S Pk9fVWPT3q5bdQxzS+iYJEz4hpZRXEpCJ7vQdN6lOZDV5JkPSuQ9R+q/iTQThEgY fzc278KyUQZsqQPmEOpYC6a4DW0+yZkj/eO9qj2k2/RrZEl1oLI/6/WMC6mqU5rO afPpEGqqMxzFGMKeNxYe2CKuPWe7QIu0yrR8NJii4O4ctccB5LVZXZoSQe6FCMrL mUvIHgXa3lDUZx8j5YP4sd3KhumF/uMPbF473I4umZHGzvIKkxbYNw8RDHxEFiiZ wi93dn17NB/zhzOMJESrYi9wUT+qxhI/NGhN6GG8sKFon20gGymXrZJ+ze4Ppwk= =uqQS -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/20160927111049.GG31510%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] exit code 1 of qubes.RecieveUpdate, what does it mean? Failing to install dev packages in dom0
On 09/23/2016 03:22 PM, Marek Marczykowski-Górecki wrote: '/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1! Check /var/log/qubes/qrexec.sys-firewall.log. I'd guess it is something about package signature verification. Thank you for your reply. That last lines of the file is not informative: Rpc allowed: sys-firewall dom0 qubes.NotifyUpdates Rpc allowed: sys-firewall dom0 qubes.ReceiveUpdates What next? Best, Tobias -- 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/d0e2510a-04ec-58ef-3beb-5c8ce362f84f%40tobbe.nu. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Anything else to wipe other than HDD and BIOS..?
If I think a computer has been infected, is there anything else I should wipe/re-install other than 1. Hard Drive / Operating System 2. BIOS Is there anything else that a hacker could possibly infect that needs to be wiped/re-installed..? 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/43647750-ce02-45db-b745-865ffee84df3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
