Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz@gmail.com > wrote: > >> An actual protection would be some kind of a chemical that would destroy >> the ram chips if they ever reach certain (lower than room) temperature. > > the epoxy is likely to damage them in most means of removal. I guess most people have shinier (literally, on the contacts) new hardware than I do, but I know now and then I need to re-seat my RAM chips when the system gets cranky. Epoxy would a pretty costly measure (probably destroying the motherboard as well as the RAM). I guess I'd have to get a shinier new mobo in that case. :) I think case security and case (and room) intrusion detection is a bit more "civilized." > i know of things that can do their damage when they reach a certain > temperature or higher. never heard of one set off by going below a certain > temp. While interesting, that seems like a bad idea. Unless you're UPS'd up and never need to modify your hardware, insert/remove a card, whatever, you're gonna have a bad day eventually and lose your ram/mobo. > erasing on power loss would be good too, esp if the attacker doesnt know > about it. This, I do like, possibly hooked into case intrusion. I might just look into that myself, see if there's certain RAM pins that can be safely grounded to wipe the RAM in a case of power outage. I expect it's more difficult than that, and that the RAM would have to be actively wiped, since a power-off should basically be more or less equivalent to grounding all the RAM pins, no? Now, frying the memory with a high voltage zip from a charged up cap, say, on some chip-enable line or whatever, if there is a case intrusion without the proper trick done to disable it (such as a 16-dip-switch combination lock that has to be set properly) might be kind of cool. :) You'd want some gate to isolate that line (or thew whole chip) from the motherboard, to protect it. Maybe a capsule of acid on the ram chips (and contained to only affect them) that gets popped on command. It'd be fun to burn the sticky fingers of any intruder, too. :) Getting a bit fanciful here... On that same line of thought, sending 120V to the case if it's opened while the power is on (which is the mode of action for a cold boot attack, I assume?) might be fun. You might want to remove your Underwriter's Lab logo from the PC if you rig that up, lol. Getting into "Home Alone" territory. If you keep your PC on when you're away from it (which I think is safer, and I guess is the situation when you need protection from a cold boot attack), you could do something like immediately start wiping the RAM upon case intrusion. That'd be harmless in the case of legitimate maintenance, too. Seems much cleaner. I wonder what the most straight forward method of stopping all multi-tasking and starting to wipe the ram would be. Could a dom0 bash script, watching an intrusion detection device, simply do an "xl pause" or whatever on all VM's and start writing to some /proc memory device? (That's probably not going to work, you'd need something more ring-zero-ey...? Perhaps in a device driver. When I try to use my on-board NVidia, it does a good job of locking up the computer and wiping the RAM itself, after awhile, lol.) It'd have to be reasonably fast at starting its work. And writing to 4g/8g of memory is going to take some time, in the best case. Which adds points in the favour of the more destructive high-voltage zap method. (Maybe not a sequential write, but a bit more randomized one would thwart any attacker better?) There may be some existing work done on this for xen; I might do a bit of research and report back if I find anything useful. Interesting subjects to ponder. In my case (pun intended), there's not anything sensitive or incriminating on my drive or in memory; it's more a matter of protecting privacy and attempting to stop ongoing harassment and illegal surveillance. Stealing some work designs or code or personal information would be annoying, but it wouldn't jeopardize my life, land me in jail, or have me detained for waterboarded or anything. So knowing someone was tampering is good enough for me, and what I have personally focused upon. I'd be interested in others' thoughts on leaving the PC on versus leaving it off. Lately, I've been leaving it on, but with an alternative OS (another Linux) whose sole purpose is to know if somebody's been mucking around. My actual useful drive, data, passwords, go with me. It's only slightly inconvenient, but so far it has been the quickest route towards some peace of mind until I'm 100% confident in physical security and tamper detection. Sorry for any digression. 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 e
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
>> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3
>
> I've looked at it few years ago and it was outdated/unmaintained at that
> time already. I gave up on setting this on Win 7. I bet now it's even
> harder.
Yes, weird how neglected it is. Do people not write utility software for
Windows now? Is it too locked down by MS (expensive signing) or too
insecure for anyone to bother coding?
Remote sound seems like the type of thing a lot of power users would want,
even on Windows.
>> When I assign a single USB drive to a VM, is dom0 still really in charge
>> of the USB bus, and just shuffling stuff back and forth to the VM(s)?
>
> If you assign a single USB device to VM (using qvm-usb or qvm-block),
> then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
> Only assigning the whole USB controller (PCI device) to a VM will move
> USB processing out of dom0.
So other than the potential of bugs in the stack, and faking a
keyboard/mouse, there's really nothing a USB device could do to provoke
any action (break-in attempts) in dom0?
Would a USB Wifi dongle auto-configure as a second adapter on Qubes? (I
might check that myself later.)
Mass storage devices will be noted by dom0, but nothing silly like autorun
could happen (unless you set it up manually). Device impersonation is a
threat, I suppose. Can one USB device effectively "bus master" to probe a
disk or something like that?
Any other device type that could be a threat via USB?
As long as you have a solid stack and reject HID/network, USB might not be
quite as scary as I thought.
Once you get your keyboard/mouse off of USB. That recipe for rejecting
HID in one of those links worked great,
/etc/udev/rules.d/99-disable-usb-input.rules:
ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="usb",
ATTRS{authorized}=="1", \
ENV{PARID}="$id", RUN+="/bin/sh -c 'echo 0
>/proc/bus/usb/devices/$env{PARID}/authorized'"
Any new attempts to insert HID devices are ignored.
I suppose there's a window at boot time before udev configures where a
rogue USB device could impersonate a HID device and try to hijack the
system (e.g. right at grub). But supervising any boots for any oddness is
trivial (and a good idea).
>> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev
>
> Very interesting project indeed. And it is packaged in Fedora!
N!!! Lol, I spent hours trying to get that to build. I had
checked for packages under debian-8, found none, so figured Fedora was
even less likely to have it (being more conservative).
I was even building it under a bare-bones Fedora-23 VM. I could have just
dnf'd it.
That's a great thing, presumably having undergone review from the Fedora
folks to be in the main repositories. (If Qubes can't in turn trust
Fedora and its repo, it's toast from the start.) But I assume you still
don't increase the amount of running dom0 software lightly.
Installing it only brought in libqb (102k) and itself (206k), so it's
fairly lightweight. Might see how well it agrees with dom0. :P
> But as you've noted below, if all we need can be done using udev rules,
> it's better to not introduce another complexity.
With Fedora's review (and a fairly small package), I feel a lot more
comfortable with it, perhaps as an option. Making it easier for people to
track/configure USB devices is a pretty compelling selling point.
Possibly outweighs the risk of the minimal additional of dom0 software.
> The whole idea of having separate USB VM is to not care about USB
> related compromise. It isn't fully possible with all kind of devices (like
> USB camera - compromised USB VM will be able to sniff the traffic), but
> it is surely an improvement.
Leaving any camera or microphone connected at all isn't for the highly
security conscious. :)
> It would make sense to have Disposable USB VM - I hope we'll manage to
> have it in Qubes 4.0.
That's interesting. So, for example, you could possibly configure it such
that if a certain device is inserted, a disposable VM could pop up,
attached to that USB device, that could then run an app (such as keepass).
When you're done, the DVM goes away. That's rather tidy. And safer.
I assume memory freed from a dead VM is wiped upon freeing by Xen? Or at
least wiped before allocating it elsewhere?
>> Some discussions online argue that USB white-listing isn't helpful,
>> since
>> a BADUSB could just emulate your actual keyboard. Well, it would have
>> to
>> know the device ID's first.
>
> Yes. But then, such device would be able to communicate with
> only one driver - of that keyboard. Not arbitrary chosen one of hundreds
> of them -> large reduction of attack surface.
I suppose even a brute-force search of device ID's through the relatively
few vendors is feasible (without some protection).
> Of course, if it hit unlocked system (or locked, but know the password),
> controlling keyboard means controlling the whole system. But you can
> guard against such attacks
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Sep 01, 2016 at 06:55:05AM -, johnyju...@sigaint.org wrote: > > On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: > >> I'm curious to some mentions-in-passing about Andrew's hate for USB > >> keyboards. USB-anything isn't good for security, but what in particular > >> so much worse about USB? Both USB and PS/2 can keylog, or play > >> predefined > >> scripts to try and exploit the system. One of the dangers of rogue USB > >> devices is that they can suddenly pretend to be a keyboard (which Linux > >> will accept without confirmation, something I'm not thrilled about). > > > > It is mostly not about the keyboard itself, but other devices on the > > same bus. Anything that can control the bus to which keyboard is > > connected, can control the keyboard / pretend to be a keyboard. > > I can understand pretending to be the keyboard, but seeing the keyboard's > traffic, controlling the keyboard is really possible from another device > on the bus? If so, what a fatal flaw in the design of USB. On, it's about compromising system to which such USB device is connected. > > In addition, USB is quite complex and as with all complex code there are > > bugs. > > I hear you. I've bit-banged PS/2 protocols myself, and it's not that > hard. VUSB has achieved the same with USB, but its a *huge* project (and > can barely achieve HID use). > > > If you (or someone else) plug a malicious USB device that will exploit > > some bug in one of million USB device drivers, it can do whatever it > > want with the other USB devices on the same bus. And if that USB > > controller live in dom0, it's game over even without injecting malicious > > keystrokes. > > Yikes. USB really needs to get out of dom0 all together, just as > networking has. I'd also like to see the sound card in its own VM. With > Pulse's networkability, it shouldn't be that hard. One could use the > Pulse network ability instead of virtualization of the sound card. Actually our VM audio solution is based on something like this: passing raw samples (similar to pacat + module-simple-protocol-unix) over vchan link - socket-like inter-VM connection. See here: https://github.com/QubesOS/qubes-issues/issues/1590 > That might also be the best route to getting sound working in Windows > HVM's, although some work is needed on Windows Pulse clients: > > https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3 I've looked at it few years ago and it was outdated/unmaintained at that time already. I gave up on setting this on Win 7. I bet now it's even harder. > When I assign a single USB drive to a VM, is dom0 still really in charge > of the USB bus, and just shuffling stuff back and forth to the VM(s)? If you assign a single USB device to VM (using qvm-usb or qvm-block), then yes - all the nasty USB stuff is still handled in dom0/sys-usb. Only assigning the whole USB controller (PCI device) to a VM will move USB processing out of dom0. > > PS/2 is much better, because you can't connect anything else than input > > devices there, and attack surface is much smaller. > > Agreed. It's all I use for mouse/keyboard. > > > Some mitigation would be to use separate USB controller for USB > > keyboard/mouse and have it in dedicated VM (separate form all-purposes > > sys-usb). > > Another possibility is some built-in Qubes support for building udev rules > (similar to how the firewall makes iptables rules), or perhaps adding > USBGuard to dom0 (or any USB Qube). A good comparison of the two options > is here: > > https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev Very interesting project indeed. And it is packaged in Fedora! But as you've noted below, if all we need can be done using udev rules, it's better to not introduce another complexity. > Seems like a great idea for Qubes in mitigating USB dangers, since in > practice it is so hard to avoid USB all together. And that problem is > only getting worse. > > One dodgy USB device from the dollar store, and your pwned. Or an > NSA/syndicate-implanted commercial hard drive with alternate identities > lurking. The whole idea of having separate USB VM is to not care about USB related compromise. It isn't fully possible with all kind of devices (like USB camera - compromised USB VM will be able to sniff the traffic), but it is surely an improvement. It would make sense to have Disposable USB VM - I hope we'll manage to have it in Qubes 4.0. > Some discussions online argue that USB white-listing isn't helpful, since > a BADUSB could just emulate your actual keyboard. Well, it would have to > know the device ID's first. Yes. But then, such device would be able to communicate with only one driver - of that keyboard. Not arbitrary chosen one of hundreds of them -> large reduction of attack surface. Of course, if it hit unlocked system (or locked, but know the password), controlling keyboard means controlling
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
I wrote: > Another possibility is some built-in Qubes support for building udev rules > (similar to how the firewall makes iptables rules), or perhaps adding > USBGuard to dom0 (or any USB Qube). A good comparison of the two options > is here: > > https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev After reading this comparison: https://dkopecek.github.io/usbguard//blog/2015/USBGuard-vs-UDev I though the huge difference in simplicity of rules that USBGuard brings, it was worth trying out. Not wanting to just grab a binary of a project I had just learned about, I thought I'd grab the sources and compile: https://dkopecek.github.io/usbguard/documentation/compilation.html Sounded simple enough, but wow, I delved into dependency hell, a lot due to the Qt applet (which sounds cool) that brings in Qt5 and a bunch of other things. I gave up after hunting down dependencies for an hour or two, after failing to find a few "dbus modules" that were required. It brings in way too many dependencies, and is way to hard to build, for my comfort level, especially for a dom0 app. Such a shame. (Maybe when I recover from the frustration, I'll try again without the Qt applet.) It makes learning the strange udev rules syntax a lot less intimidating after all :) There really should be some simpler system to turn declarative USB permissions into udev rules. USBGuard seemed like it, but it's far too complex internally for my tastes. Some m4, python, bash scripts, and/or make should be able to do the job without all the complexity. These tutorials give the spirit of the type of thing I'd like to see automated a bit: http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices#3.2_Locking_down_Linux_using_UDEV https://askubuntu.com/questions/531445/only-use-mass-storage-devices-on-a-selected-usb-port-how A simple lockdown: https://incenp.org/notes/2014/disable-new-usb-input-devices.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/df5ba4cbf56f02a0b0c5eb774d2a98d4.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> This is scary: > > https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649 Related, and (disturbingly) informative: https://github.com/brandonlw/Psychson 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/c2872d8b7c663d10b867f7b43b735ad3.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: >> I'm curious to some mentions-in-passing about Andrew's hate for USB >> keyboards. USB-anything isn't good for security, but what in particular >> so much worse about USB? Both USB and PS/2 can keylog, or play >> predefined >> scripts to try and exploit the system. One of the dangers of rogue USB >> devices is that they can suddenly pretend to be a keyboard (which Linux >> will accept without confirmation, something I'm not thrilled about). > > It is mostly not about the keyboard itself, but other devices on the > same bus. Anything that can control the bus to which keyboard is > connected, can control the keyboard / pretend to be a keyboard. I can understand pretending to be the keyboard, but seeing the keyboard's traffic, controlling the keyboard is really possible from another device on the bus? If so, what a fatal flaw in the design of USB. > In addition, USB is quite complex and as with all complex code there are > bugs. I hear you. I've bit-banged PS/2 protocols myself, and it's not that hard. VUSB has achieved the same with USB, but its a *huge* project (and can barely achieve HID use). > If you (or someone else) plug a malicious USB device that will exploit > some bug in one of million USB device drivers, it can do whatever it > want with the other USB devices on the same bus. And if that USB > controller live in dom0, it's game over even without injecting malicious > keystrokes. Yikes. USB really needs to get out of dom0 all together, just as networking has. I'd also like to see the sound card in its own VM. With Pulse's networkability, it shouldn't be that hard. One could use the Pulse network ability instead of virtualization of the sound card. That might also be the best route to getting sound working in Windows HVM's, although some work is needed on Windows Pulse clients: https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3 When I assign a single USB drive to a VM, is dom0 still really in charge of the USB bus, and just shuffling stuff back and forth to the VM(s)? > PS/2 is much better, because you can't connect anything else than input > devices there, and attack surface is much smaller. Agreed. It's all I use for mouse/keyboard. > Some mitigation would be to use separate USB controller for USB > keyboard/mouse and have it in dedicated VM (separate form all-purposes > sys-usb). Another possibility is some built-in Qubes support for building udev rules (similar to how the firewall makes iptables rules), or perhaps adding USBGuard to dom0 (or any USB Qube). A good comparison of the two options is here: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev Seems like a great idea for Qubes in mitigating USB dangers, since in practice it is so hard to avoid USB all together. And that problem is only getting worse. One dodgy USB device from the dollar store, and your pwned. Or an NSA/syndicate-implanted commercial hard drive with alternate identities lurking. I'm always tempted, but ultimately avoid, unusually low-priced USB devices, lol. I've been passed USB keys from some rather suspect individuals in the past; I've quarantined them, and should (carefully, on a non-critical system) take a more detailed peek someday, lol. Some discussions online argue that USB white-listing isn't helpful, since a BADUSB could just emulate your actual keyboard. Well, it would have to know the device ID's first. Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate it, the system could spot the fact that there's a second similar device but on another USB port, no? Or is USB so stupid that the system couldn't differentiate the two (or the fact that there is two)? While the USBGuard project looks admirable, I'm guessing the more attractive option would be for Qubes to add support for creating custom udev whitelists, as the less software in dom0, the better. Although USBGuard isn't a huge project (the tarball is <1M) and if you're going to otherwise have to write the code yourself, it might be better to just audit USBGuard and include it in some form. If someone else has already put in much of the required thought and effort . . . Even a pop-up notification when a new HID device is added could be useful. The fact that keyboard/mice are silently accepted is a bit scary. I might add some scripts to watch dmesg for such events, and more actively warn me. All just food for thought. I'll be adding udev whitelist rules to dom0 very shortly. Another idea I saw was restricting HID devices to *one* keyboard and *one* mouse, so if a BADUSB comes along trying to be another keyboard, it doesn't work. Or even better, alarm bells go off. I was thinking earlier that some form of a "USB Firewall" hardware device might be cool to create; one that goes into each USB port in between each device and the PC, and only passes a specific device, or only a HID device (and doesn't pe
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: > I'm curious to some mentions-in-passing about Andrew's hate for USB > keyboards. USB-anything isn't good for security, but what in particular > so much worse about USB? Both USB and PS/2 can keylog, or play predefined > scripts to try and exploit the system. One of the dangers of rogue USB > devices is that they can suddenly pretend to be a keyboard (which Linux > will accept without confirmation, something I'm not thrilled about). It is mostly not about the keyboard itself, but other devices on the same bus. Anything that can control the bus to which keyboard is connected, can control the keyboard / pretend to be a keyboard. In addition, USB is quite complex and as with all complex code there are bugs. If you (or someone else) plug a malicious USB device that will exploit some bug in one of million USB device drivers, it can do whatever it want with the other USB devices on the same bus. And if that USB controller live in dom0, it's game over even without injecting malicious keystrokes. PS/2 is much better, because you can't connect anything else than input devices there, and attack surface is much smaller. Some mitigation would be to use separate USB controller for USB keyboard/mouse and have it in dedicated VM (separate form all-purposes sys-usb). This will guard you from potentially malicious devices *you* plug into the system, but not from someone else plugging it instead of keyboard (so into that keyboard-only USB controller). To plug that hole, that USB-keyboard VM should be configured to reject any non-keyboard device before allowing any driver to talk to it. This will still left you vulnerable for bug in USB stack itself, but the attack surface is much, much smaller than all the USB devices drivers (some unmanaged for years). - -- 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 iQEcBAEBCAAGBQJXx5GcAAoJENuP0xzK19cstXgH/2+qnvTd7y00TSaUuAqjgUUI waSjgeZnXfuGn8WMIRaGn4sIAqG4VgL1JP8sStWGHzAktOnqU/BHmaMAgipVvDpy 60a0SumEE1kZ8RUbIzINuTlZVmXw/7Dt1NCA0FOJbkjn4UeiuRvCkKceedJXrV9a m3HoCGTu1qgZB9B4m+TvPtgeqUrUj/bvsLkgPJbVKiOWevIJ7M57cabDk/6P3p0q QMHT6yPqcEXrA3SKAay/LDTvwP6C67jXjkCsvQYPX1TNrCZzEkvYyA3P4ycblBlM Pq3MmSlPTLkiHorupOERDZi7mON2lss23aaj0AXvClgO03V8ArPjDnnmxHEWW9A= =za1M -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/20160901022532.GE24732%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> Lately, I've been leaving it on, but with an alternative OS > (another Linux) whose sole purpose is to know if somebody's been mucking > around. My actual useful drive, data, passwords, go with me. My keyboard also goes with me, which is the main inconvenience currently. I think most common keyloggers require someone to pick up the payload in person while you're out (with some magical password combination that gets the keyboard to spew what it's been seeing). If the keyboard's with me, they will never get the chance. Unless that sucker is broadcasting... Which, ummm, I guess they all kind of are in a SIGINT kind of way: https://www.sigmobile.org/mobicom/2015/papers/p90-aliA.pdf I'm sure there are fake/trojan keyboards that actively broadcast on wifi/bluetooth without your knowledge. RF detection/quieting can help with that risk. One of my current side-projects is a strongly encrypted keyboard. Just uses a PS/2 connector, but encrypts the channel with xxtea to a small driver/xinput stub/decoder on the Linux side. So even SIGINT style monitoring wouldn't pick up anything useful. (The sound/vibration methods of decoding typing can be mitigated a bit with damping feet/neoprene base, and some other quieting techniques.) A shorter-term personal project is to hack the existing keyboard's controller to be socketed or on a daughter board. Taking that with me would be easier than the entire keyboard, and just leave some useless (and stateless) contact switches and wire behind. :) Plus a clear (or missing) top case to spot any other unauthorized changes. I'm curious to some mentions-in-passing about Andrew's hate for USB keyboards. USB-anything isn't good for security, but what in particular so much worse about USB? Both USB and PS/2 can keylog, or play predefined scripts to try and exploit the system. One of the dangers of rogue USB devices is that they can suddenly pretend to be a keyboard (which Linux will accept without confirmation, something I'm not thrilled about). But a keyboard is already a keyboard, it doesn't need to pretend. :) Is it that USB devices can spy on the whole bus? (Is that true? I think I read it somewhere.) (I do personally prefer PS/2, as it's simpler, less hackable, and something I can more easily interface with for my own encrypted keyboard project.) Related, I don't think mouse tracking can be turned into anything useful nor exploitable, as long as the mouse stays a mouse and doesn't go rogue and suddenly show up as a keyboard and start typing an exploit. And I'll digress one step further: it might be worth "hardening" the xfce4 GUI so that no dom0 window or menu can be fired up (by default) from the keyboard. That way, if a keyboard did go rogue in the GUI, and I don't keep existing dom0 windows about, it can't open a dom0 window. (I know, I know; if the keyboard/GUI is compromised, you can probably say good-bye to dom0 and your computer overall, regardless. Some a bit of extra protection wouldn't hurt.) Enough rambling. 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/6d88a750534949022af26fe18747bd4d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
