[qubes-users] JeOS?
I've converted all my VM's to debian-8, and I'm continuing the never-ending process to trim down the service vm's to the bare minimum underlying template. No sense having cups, pulseaudio, libreoffice, etc, lurking around in a dedicated packet-flinger VM. Especially with the dozens of processes that might just wake up and phone home unexpectedly (like going to MS for a samba name resolution, or whatever). (I was thinking that a highly restrictive apparmor process might be an interesting way to use a common fully-loaded template both for work AppVMs, and (using the restrictive apparmor configuration) the net/firewall VM's. But I don't want to add more complexity, and more trust in apparmor.) In this process, I stumbled across a new acronym to me, a JeOS: https://en.wikipedia.org/wiki/Just_enough_operating_system They looks like they might be well-suited to being a great virtual device for the various service vms. They're also typically tuned to run in VM's. I'm going to give a couple of them a try, maybe CoreOS and the Ubuntu one. CoreOS is gentoo based, so the Ubuntu one might be a bit closer to debian-8. Will report back any fun and excitement that results. -j -- 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/10bd300c7647cf73eb292d5ede21b064.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] OpenVPN and debian-8
I've finished my conversion of all VM's to debian-8 (and isolating USB, the sound card, etc.). (Next is dom0, and maybe the replacing the hypervisor, but that's another story. :) ) The last hiccup was getting OpenVPN working in debian-8 in a ProxyVM. It would connect, but then get stupid and hangup. Turns out the problem is that OpenVPN 2.3.4 included with Debian-8, will fail to add a default static route to the VPN provider ("route add w.x.y.z gw 10.137.2.1 eth0" kinda thing) if the netmask of the WAN interface is 255.255.255.255. (There's some bug post out there related to this.) Without the route, all traffic, including traffic intended to the VPN provider, gets stuff into the tun0 VPN pipe, which wedges it. If you're quick, you can add the route at the right time to save the connection. But the right solution is fixing the netmask. If you change the wan IP netmask to 255.255.255.0, then when OpenVPN connects, the static route gets added, and the VPN connection stays up. However, the default seems to get changed back on next AppVM boot. I think the qubes Vm startup code is grabbing the netmask from qubesdb (qubesdb-read /qubes-netmask), and I think dom0 is setting that statically in the code. (I don't see it in qvm-prefs, qubesdb, xenstore, and haven't had time to dig further.) I can see why Qubes would choose 255.255.255.255, since VM link adapters can't access others on their subnet directly, but have to bounce through their netvm (a good thing, security-wise). However, using 255.255.255.0 should be harmless, since you can still only directly access 10.137.*.1 anyway; and it would avoid messing up Debian's OpenVPN connections. (Admittedly working around an OpenVPN but, but an easy and harmless fix.) fedora23 uses OpenVM 2.3.13 which doesn't seem to suffer from this problem. I tried grabbing an OpenVM from backports, but there wasn't anything newer. Cheers, -d -- 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/8d42cf40f8974d4b57c871890262a7a5.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Updates, security
While updates are signed, so even if they come over the wire in cleartext, the fact that they often are sent in the clear (even from debian.net) allows a snooper to know what packages your scanning for metadata or installing. It reveals a lot about the state of your system. Updating over Tor or a VPN helps a bit. Updating to debian's hidden service is even more ideal, no https in between with state-actor/CA-forgeable certificates possible, etc.. However, Qubes updates aren't available via Tor. I do notice, however, that the qubes repository will allow changing the "http" to "https" in the qubes entry /etc/apt/sources.list.d/. (You'd have to install "apt-transport-https" too.) Do the Qubes folks have a problem with this? It'd put extra load on the servers, so I thought I'd ask. I might suggest it would make a good default, if the load wouldn't be unacceptable. Cheers, -d -- 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/617051ede5374543bb82e5f406e1cee9.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Nvidia drivers in dom0 still works? (need to get a GTX 1070 off the ground)
TomL Wrote: > I believe that Nvidia binary drivers do not work under Xen. I spent a > while trying unsuccessfully before reading some documentation to that > effect which I considered reliable at the time, but can't immediately > recall. If you find credible evidence that there's some workaround, I'd > love to see it (and get my own Nvidia card working under Xen in Qubes!). > Unfortunately, I currently believe that it is impossible. Sorry I can't give you direct advice, as I haven't tried it on Qubes yet (don't want to upset my working configuration, nor increase attack surface using proprietary drivers), but... I have installed the nvidia drivers (304 version) on Xen/Debian and it worked fine. Same version of Xen, so it should be possible to get the nvidia drivers working, and I have heard of others having success on Qubes. In installing the "alternative" drivers, if you install the wrong one (some older cards need the 304 version, not the newer 340 version, I think), and try to recover, the configuration can get messy. I still don't fully understand why mesa (free version of glx) adds another layer of alternative redirection on top of things, nor necessarily how it all is supposed to work. (There's the alternatives system, then mesa also redirects things somehow, so it's hard to know what drivers are active at times.) Oh yeah, when I did successfully install the nvidia drivers, once a day or so, when running an accelerated program, things would freeze and crash. Even though the default nouveau drivers are slower, they do seem to be a more reliable. On a side note, one of Qubes strengths is the fast vchan-based gui/guid system. Using shared memory, it updates the screen a lot faster than, say, VNC (the typical way of using Xen), allowing playing videos and such, even under nouveau. 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/29f2e2fe42b37cb89f0340a7e8139941.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes-manager refuses to launch
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, Dec 14, 2016 at 06:44:35AM -0800, Andrew David Wong wrote: >> On 2016-12-14 06:31, harh...@gmail.com wrote: >> > I did that already, so... >> > >> > That's the point - I can't run any command, cause vm-manager (and >> > the process itself) seems to do not run, "dnf remove" reports of >> > not-existing packets (cant match the arguments >> > "qubes-template-fedora-24" and so on.. It is a record within *file >> > where this VM mentioned and vm-manager checks it..) >> > >> > #. Yes, I have a Backup, but wish to repair this state... if it >> > is impossible -> then ok, I'll do backup# >> > >> >> I understand. I'm afraid I don't know how to fix the broken state your >> system is currently in, but maybe someone else does. My message was >> mainly about how to avoid this situation from recurring in the future. > > At every system startup backup of qubes.xml is created in > /var/lib/qubes/backup - you can restore it from there, then remove > template using correct tools. I have had cases when it appears that QubesManager appears like it will not start, but the reason is because it sees another one running so holds off (but sticks around). The other instance is windowless and usually wedged somehow (typically on libvirt--I'm not a big fan of that layer). As root, do a "ps ax | grep qubes-manager" to find the running process (a python process). kill (or kill -9 if needed) that process #. All of them, if there's more than one. Then re-run qubes-manager with "qubes-manager". If libvirtd is being stupid, a "sudo systemctl restart libvirtd". That often wakes up a non-responsive system for me. (If that's the problem, kill qubes-manager, restart libvirtd, then run qubes-manager.) -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/8230d4fa65d9b187c916b1a2a268e8da.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Swappiness, Qubes, Microkernels
> On Tuesday, 29 November 2016 09:44:17 UTC+11, Patrick Schleizer wrote: >> >> Would setting >> >> /etc/sysctl.d/swaplow.conf >> vm.swappiness=0 >> >> in Qubes by default make sense? >> >> If not effective at all, why is it not required? Why do you thik it is not effective? I've played around with swappiness a lot. It has the intended effect when I play with it, both in the vm's and in dom0. (I wrote a handy little dom0 memory monitor utility that shows more details on all VM's, that I'll hopefully post before long.) > Question you have to ask yourself. : Do you have enough RAM to not need > swap? > > Personally, I have no swap space. I generally agree that is smart, especially in the VM's. Although it's nice to have in case you get one process get memory-hungry; it's nice not to have things randomly killed. vm.swappiness *does* have an affect. With swappiness=0 swapping will only happen when it really needs to; when cache/buffers have been taken back and used, and there's just no more ram to allocate. With higher swappiness values, infrequently-used data will be swapped out to disk, even when it isn't necessary. The higher the number, the more aggressively this happens. With a high number, only pages in active use stay in memory. Sounds good, but you shouldn't have a lot of inactive stuff running in your VM's anyway. With higher swappiness values, since the swapping isn't really necessary, the result will be extra free ram in a VM, which Linux immediately starts using for cache/buffers. On bare hardware, this makes sense. Unused memory is simply wasted, might as well cache some data and code there until we need it. It can't hurt. *However*, inside a VM, it's stupid and wasteful to swap stuff out so you can have more buffers/cache. In fact, it's stupid and wasteful to even have buffers/cache inside a VM at all. Any cached data will also be cached in dom0, doing the .img reads. And since the templates root.img file (for example) is shared between multiple domU's, having that cached in dom0 gives you a noticable performance boost. Having a virtual disks's contents *also* cached inside the VM, is redundant, wastes memory and CPU, and makes the whole memory management thing more awkward. Having a block from root.img cached in dom0, as well as every domU that uses that template, is nuts. Qubes' memory manager deals with things as follows: for each VM, it allocats what the VM indicates it is using, plus a "fudge factor" of 1.3x (also known as the cache-margin-factor in /etc/qubes/qmmeman.conf, but I think it's hard-coded elsewhere, ugh). There's also a fudgey extra amount reserved for dom0, configurable in the Qubes manager. Adding more memory to this is a roundabout away of cranking up dom0's cache, if you wish. The memory manager, also takes any leftover memory on top of of the VM's usage (+fudge factor) and divvies that memory up amongst all the VM's. That's not exactly optimal. Giving that extra memory to VM's that don't really need it doesn't hurt anything memory-allocation-wise; if another VM suddenly needs memory, VM's will give up the part they don't need. It'd result in a bit of extra unnecessarily memory shuffling and CPU usage during memory reallocations. I do notice the odd extra pause as memory gets shuffled. However, when qmemman bestows that extra memory on a Linux VM, Linux in the VM will start using all of it for buffers/cache, which is redundant. The memory would be better used in dom0 caching, or for another VM doing something useful. I've cranked my cache-margin-factor down to 1.1, and it helps performance for me. The cache-margin-factor also acts as a bit of a pre-allocated margin for memory growth, without having to request a qubes memory manager reshuffle. (I'm not super-thrilled with the somewhat implicit allocations of memory to different key system purposes. It's like controlling the system via a bunch of loose rubber bands. :) ) On a Virtual machine system, swapping makes very little sense. It's a major performance killer, especially inside a VM. About the main reason I keep it around is that if something does suddenly take up memory, I'd rather critical processes not be killed. But if it's ever in use, you need to look into it. (I have a dom0 utility which reports on VM's swap space among other stuff. Will post it at some point.) There's an argument that swapping lets unused stuff migrate to disk and not take memory (like X server data in sys-net, or whatever). But unless you're intentionally running very bloated AppVM's that start a bunch of unnecessary stuff (not a great idea), swapping out unused stuff buys you very little. I've turned to using small fixed-size VM's for most service VM's (with my own no-gui service flag, to avoid loading qubes-gui-agent and the X server). Same for pulseaudio, and other services that really don't need to be everywhere. That keeps the servicevm's from grabbing/releasing memory which only gets used as a
Re: [qubes-users] swappiness, caches
> Interesting that the Wiki page for swappiness (this kernel parameter is > officially more famous than I am) recommends setting it to at least 1. > > https://en.wikipedia.org/wiki/Swappiness I'm going to stick with vm.swappiness=0 for a few days just to see if any reliability problems or app failures do pop up, out of curiosity. I think a setting of 1 (or at least <10) is probably best for the long run, letting some very infrequently used stuff creep off to swap. -- 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/87ef6832599ed40108b3708ea2ee3580.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] swappiness, caches
> Interesting, sounds reasonable. > > Running with absolutely 0 swap however can lead to unexpected problems > from my experience: Interesting that the Wiki page for swappiness (this kernel parameter is officially more famous and I am) recommends setting it to at least 1. https://en.wikipedia.org/wiki/Swappiness More on the vm.swapiness parameter. It's a bit more subtle than I thought. Some references: 1) http://askubuntu.com/questions/103915/how-do-i-configure-swappiness This page describes it as being how prone Linux is to start swapping out processes. At 0, nothing will be swapped until memory is fully exhausted; at 100, swapping out of processes will begin almost immediately. It indicates the default setting of 60 means swapping will start when memory is around "half" full. So a setting of zero doesn't prevent swapping, it just puts it off until there is no memory available. This is the old-school Unix behaviour I'm used to, and probably best for VM. 2) http://unix.stackexchange.com/questions/88693/why-is-swappiness-set-to-60-by-default This page talks about it in relation to choosing pages with backing store (programs, libraries, cached/mem-mapped data files, already-swapped data) vs. "anonymous" pages of allocated memory. Cached files have a weight of 200-vm.swappiness, and anonymous pages a weight of vm.swapiness. That may be saying the same thing as #1 but in a different; possibly more prescise way, since a setting of 100 gives a 50/50 weight for new page acquisition betreen swap and cache. 3) http://www.cloudibee.com/linux-performance-tuning-vm-swappiness/ This one talks about it as a balance between "swapping and freeing cache," which is the same, I think. - Any anonymous page is going to need to be written to swap before being given to the VM needing memory. (As well as a read when the page is used in the future.) And writes are usually more expensive than reads to start with. A cached file/program/library doesn't need to be written, the page can be discarded and re-used immediately since it can be retrieved from the backing file/program/library when needed in the future. Having a swap/anon page swapped and retrieved has a cost of 1w+1r Having a file/prog page discarded and later retrieved has a cost of 1r. So swapping has a r/w cost of at least 2x that of stealing from the file-backed cache. (Writes are usually a bit more costly than reads, as well.) Obviously the nature of your machine (server/desktop) affects things. That 60 default setting means file-backed cached pages have a weight of 200-60, or 140, while the anonymous/to-be-swapped pages have a weight of 60, a 70%/30% balance in favour of resuing file-backed cached pages versus swapping something out to get free pages. Not a bad compromise for running on bare hardware, or a server; but not appropriate/necessary for a VM. With vm.swappiness set to 0 and the same swap space as before, swap can get used when needed; and as much as before, but not until memory is exhausted. And when the free memory is exhausted, that also implies that all of the cache has also been re-allocated as assigned memory as well. Since the VM's really shouldn't be caching in the first place (double-caching in both dom0 and the VM has to be slower than just one level of cache). I'm still looking around for options to disable file caching, but having vm.swappiness low at least gives any running program priority over the memory being used as cache. The qmemman load balancer won't consider the memory used for a VM's cache as part of it's "required" memory (but it does include swapped out stuff, giving it reasonable chance of getting back into memory without thrashing), so with low vm.swapiness a VM will not be given extra memory to maintain any significant level of cache, unless there's free memory around to be doled out between VM's overall. I can't help but think the original intent was for vm.swappiness=0 behaviour. Once vm.swappiness is >0, then some level swapping will occur resulting in free pages for the VM, and Linux will then go and use these pages for additional (and unnecessary) cache space; an all-around waste of disk-access, CPU time, memory. Running with vm.swappiness=0 seems to work in practice so far. I'm still amazed at the difference in memory/performance I'm seeing. Zero swap on a system that used to have 40M-ish swapped on all VM's and in dom0. And smaller VM's, allowing more to be started. I'm surprised that this hasn't been a default, or at least some similar tuning done by default. In the source code, the 350M "dom0 memory boost" is mentioned as being specifically to give dom0 free memory (that will inherently be used as cache) beyond its actual needs (used memory+used swap). So there is intent to let dom0 do the file caching. But not a similar effort to prevent unnecessary caching in the VM's. Also, it's worth verifying the benefitting from a low vm.swappiness in dom0 itself. Swapping can just
[qubes-users] swappiness, caches
It always seemed a bit "off" to me that there should be any swap usage or significant buffers/caches inside VM's. dom0 already caches the virtual .img files, so having the kernel inside each VM also buffering/caching files and metadata is really just a waste of CPU and disk space. More importantly, swap activity is a major performance killer on bare hardware; even more so on a virtual machine. There's a case to let some stuff swap out (unused x-servers in sys-net/sys-firewall, etc.) but the default is way too aggressive for good performance, IMHO. The kernel has a "vm.swappiness" (0 to 100) parameter that controls the balance between grabbing a new free page from the cache or swapping a page out to re-use. The default is 60, which leans towards swapping instead of cache use. Not ideal. In dom0 and all my VM's, I tried changing the swappiness factor to see what the effect would be: # echo 0 >/proc/sys/vm/swappiness or $ sudo sysctl -w vm.swappiness=0 To empty existing swap space, I did a "swapoff -av && swapon -av" Performance is noticeably better, with no swapping happening in any of the VM's, nor in dom0. And memory usage reported by the Vm's seems to be smaller; a heavy browsing session used to crank a VM up to 1.5G; now it seems to be more like 800M. So I can run more VM's, get more done. (I'm not sure why this is, but firefox seems to be less of a memory pig with this change. Maybe with the former aggressive swapping out, Firefox thought free memory was a bit cheaper than it is, and was more aggressive in its own use, or more lax in freeing things up. With a more realistic picture of the memory situation, by changing vm.swappiness to 0, it doesn't seem to be quite the pig it was.) You can set the parameter permanently by adding "vm.swappiness=0" to /etc/sysctl.conf in dom0 and your templates. Poking around 'net, I see a few comments where 0 swappiness is best for guest VM's. I wonder if a little higher might not be bad, for the case of an unused X server or whatever, being able to swap out. I might play a bit with different settings in different VM's. It would be nice to disable caching in the VM's, but that seems to be a difficult thing to do in Linux. So far I've found that the system is pretty good about keeping the VM size to the minimum/startup size, and giving up buffers/cache when needed. (buffers/cache aren't included in the 'memory-used' calculation when mem-balancing between VM's, which keeps the buffers/cache under control a bit, I think. Excessive cache use is not given weight and rewarded by additional memory in the balancing. Any real memory needs from an existing or new VM would effectively take priority over buffer space, in the memory balancing allocations.) Real quick and dirty way of checking your swap usage across VM's (I might add this info to the VM manager for fun, since it's pretty critical performance information; will submit any changes): $ sudo xenstore-ls -f /local/domain | awk '/meminfo/ { print $12-$14, $1 }' The # reported in the path is the domid, which you can see with "qvm-ls -i" I'd be interested in hearing others' thoughts on this. Related reading: https://www.xenproject.org/directory/directory/research/118-geiger-monitoring-the-buffer-cache-in-a-virtual-machine-envrionement.html http://www.sersc.org/journals/IJCA/vol6_no1/12.pdf 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/7cc1093b43c2e02d8712b9d67d6341fe.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Persistant routes on Qubes are not persistant?!
> Hello, > > I need to add some static routes since I'm using a network with different > GWs. For that reason I've tried to add some static routes through the > NetworkManager which maps all the configuration into a file called > qubes-uplink-eth0 . Strangely and since this file is within the private > disk image, one would expect that the changes are be preserved after a > reboot, unfortunately this has not been the case. Everytime there's a > reboot the file gets overwritten somehow. > Does anyone know if there's a way to preserve static routes on Qubes or is > this simply a limitation? That seems quite odd. Is the symlink for /etc/NetworKManager/system-connections -> /rw/config/NM-system-connections in place? Is /rw/config/NM-system-connections indeed a valid directory, writable by root, etc.? Is /rw properly mounted to /dev/xvdb? If you go into /etc/system do you see a file for each network adapter (i.e. "Wired Connection 1")? Is that file rw by root only? When you modify settings in the network-manager taskbar icon, does the network's config file change accordingly? (It's text-based, easy to view.) I use a couple of different static network configurations through NetworkManager, and they stick around just fine. What template are you using? 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/cd66f141fc4026811b40a87101e9118d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Maybe a provocative question
>> Now, about 4.7. Note that the page for only lists individual names, >> does >> not list any company affiliations or employers at all. An odd >> change/omission? > > could there be a simpler explanation? Certainly. Maybe some intern generating the stats page was too lazy to summarize it by company. Maybe they stopped tracking company affiliation. Maybe it's just an oversight. Given the state of computer/network/software security these days and the NSA's reputation, I thought it was worth pointing out. :) >> Xen is a much bigger and faster-moving target than I ever expected for a >> hypervisor. > > indeed, same here. Wiki on Microkernels is consistent with my understanding: > In terms of the source code size, as a general rule microkernels tend to be smaller than monolithic kernels, usually sizing at under 10,000 lines of code. Xen's Wiki page states: > Xen Project is a hypervisor using a microkernel design It's a bit disingenuous to call Xen a Microkernel, at 150,000+ lines of code. I hope to dig through the sources a bit tonight, and see how much of that is truly the core kernel/security bits, and how much of that is qemu drivers and stuff. Maybe there is a lean, well-reviewed core that we can all trust, with a lot of supporting drivers and such. Although the fact that those acknowledgement pages are careful to point out "Microkernel core" vs. auxiliary stuff. >> Is it possible to have a secure environment, where you don't fully trust >> the hardware/software? > > no, especially assuming s#fully## ;-p Not with existing hardware/software/operating systems, but can we get there? Is there even a path forward? :) Sadly, there doesn't seem to be any viable Xen alternatives. (I guess one could always create alternatives from forks of Xen or the various other hypervisors/kernels out there; although securing/improving/auditing Xen is probably less work.) >> And unless you've designed the hardware and >> software yourself (or they're both open and heavily and transparently >> reviewed), and your never let either out of your sight and protection, >> how >> can you ever fully trust hardware/software? > > you can't. > > and yeah, that's sad. luckily the real world is mostly not *that* black > and white. True, security isn't an on/off binary thing, it's more of a probability to be combined with your risk profile. Qubes certainly increases your odds at having some security by a fair bit. Probably minor in comparison to all the holes, bugs, bad design choices, and vulnerabilities in PC hardware (and software bugs/backdoors), but every little bit helps. > long story short: I'd argue that *noone* should fully trust computers. > however, this doesn't make them completly useless ;-) Very good point. I've overly-trusted computers, and have been hacked so badly in the past few years that computers have basically become useless to me. But I'm also a pretty low-valued target, lol, so I'm trying to rebuild my confidence in my setup for work (and personal) sanity and dignity. It's awfully hard not to rely upon computers on a daily basis for work, personal, communications, media purposes. Stumbled across this, rather interesting: https://en.wikipedia.org/wiki/Exokernel 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/31ab8b2a2629b9c5dfb22e8b0eaa4824.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Maybe a provocative question
>> 1) XEN is developed by people working for a company based in >> the U.S. Some fun stats for Xen 4.6 changesets, as used by Cubes: Lines of Code: ~150,000 This is from https://wiki.xenproject.org/wiki/Xen_Project_4.6_Acknowledgements and related pages (and similar pages with 4.6 replaced by 4.x): Lines of code added/removed: Vers People Empl Added Rempved NSA-Add NSA-Rem 4.4 81 29 38048 25989 121 4.5 10239 80906 141593 67142645 4.6 96 30 124035 90299 459 193 4.7 10236 106606 37160 ? ? Now, about 4.7. Note that the page for only lists individual names, does not list any company affiliations or employers at all. An odd change/omission? So the NSA barely contributed for 4.4, contributed a significant amount for 4.5, a bit for 4.6, and then either stopped contributing, or are doing so in a non-transparent way through individuals for 4.7. :( I can't say that's confidence-inspiring. Xen's change from 4.6 to 4.7 to not listing employers almost has a slight "warrant canary" feel to it. :S The source is open, I guess, but still, smart people can sneak in subtle backdoor bugs. As we have seen. Also, out of those 100 individuals, what are the odds that the NSA could sneak in a few apparently unaffiliated "representatives" to submit some subtle changes. Now, I'm sure a good many of the people at NSA just want a stable, reliable, professional operating system to use for their work, and contribute back to Linux in turn to make it better. It'd be refreshing and inspiring to see them fixing our critical tech tools rather than hopelessly busting them. Go America. But given their history of sneaking in back doors through subtle code bugs, it does make one a bit, err, cautious. Xen is a much bigger and faster-moving target than I ever expected for a hypervisor. After discovering I was being victimized by some keylogging and some other covert surveillance hw/sw, I spend a fair bit of time about how to use a computer with confidence, assuming that you can't necessarily trust the hardware nor software. Is it possible to have a secure environment, where you don't fully trust the hardware/software? And unless you've designed the hardware and software yourself (or they're both open and heavily and transparently reviewed), and your never let either out of your sight and protection, how can you ever fully trust hardware/software? (For example, things such as a password safe on a memory key can help partially thwart even a hardware keylogger, since online/etc. passwords are never typed. Can this type of small success be achieved for a whole system? It's daunting.) Related: http://invisiblethingslab.com/resources/bh08/part2-full.pdf 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/6fc41c35e0c90896e50fc5892626c230.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN
> Ok, so I tried to enable the updates proxy in the sys-firewall > consequently forcing all updates to go through the VPN, I followed the > instructions outlined here - > https://www.qubes-os.org/doc/software-update-vm/#updates-proxy > However, as soon as I try to run the updates on one of the vmtemplate I > get the error "No route to host". All the templatevm has a default route > to the sys-net (10.137.1.1), notwithstanding the update should be > targeting the sys-firewall. Should I change the default GW of the > templatevm ?! I found that using an UpdateVM other than sys-net results in failures because the iptables rule to accept connections on local port 8082 is never added to any VM, other than than the default NetVM. Updates failed for me (packets to port 8082 being dropped on the update VM) until I manually added the rule myself as the first filter rule: "-A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT" Or you could just call /usr/lib/qubes/iptables-updates-proxy, which is what happens in sys-net -- 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/9091424ebc3fdf63cf1e757d83fcb21c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re:Persistant routes on Qubes are not persistant?!
>> Does anyone knows how to set static routes persistently into the >> sys-firewall? NetworkManager lets you add static routes for a network card. You might be able to get what you want by adding and checking off the 'network-manager' service for the VM (and restarting), then configuring the virtual interface's routes from the new additional NetworkManager Icon that should show up. You might be able to disable the service afterwards if you don't want the extra taskbar icon. I think the settings should stick around even if the NetworkManager GUI/icon isn't running. 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/86aa4b922926306dd6f0b5fec9c0c28c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: philosofy on qubes and other environment
> Andrew: > This kind of security-first posture is what has made Qubes famous. I agree that Qubes separation is probably the most secure basis for a reasonably usable PC-based platform today. It's all I'll use. (I worry about 4.0 not working on my hardware, tho. And upgrading hardware brings its own security risks.) That being said, there are a few things that stuck out like sore thumbs as being terribly insecure in the default install, which surprised me: - (There are some outstanding tickets on this one): All the daemons started by systemd, some of which phone home (at the very least, leaking your IP address) to Microsoft (resolving SMB names, even when you don't use SMB) or RedHat (default network connectivity check for NetworkManger). exim4, cupsd, ntpd (on by default in debian-8) don't need to be running, and can potentially leak information (and increase the attack surface). pulseaudio and the speaker daemon can potentially leak information from a VM through audio channels, and aren't needed in most cases. The default templates should be very much stripped of having any software run by default, or unexpectedly. The package (such exim, cups) can be included in the template, sure, but not on by default. - Fairly loose default iptables/firewall setup (particularly for outbound connections). No inherent DNS leakage protection. (whonix or a VPN can solve this.) Fairly limited firewall configuration. - No apparmor by default. When I tried to install it in a VM, I got errors about a missing kernel module, and haven't explored it further. Yes, VM separation keeps rogue processes at bay, but it'd still be nice if a compromised Firefox just didn't have the option of going through ~/Documents and uploading the contents to some .ru site. :) Apparmor and its profiles would add this extra layer of protection. Wow, being able to run *two* or more apps in a VM without worry of them spying on each other's data or connect to the net in ways they shouldn't! :) Keeping every useful work file on separate or non-networked machines to avoid rogue applications is too much of a PITA for most people. Or at least for me. - Unencrypted /boot partition. This one is a huge hole and could be fixed. I've converted my /boot to luks filesystem successfully, grub supports it. Adding a Grub password doesn't hurt, either. (As well as a BIOS password, but I'm digressing.) - Some of the things trumpeted in the earlier design documents and press coverage just aren't there. Sound cards, video cards, storage devices, USB, all (by default) live in dom0, not safely tucked in VMs. (Not sure why my network card's Linux module seems to load in dom0 as well as sys-net, but I'm assuming that's not an issue, and the network card is fully in sys-net.) Individual VM's disks aren't encrypted with their own luks filesystem and keys, which is mentioned in a few articles or papers I read. Not sure how important this one is, but where it is listed as a feature in some reviews, I thought I'd mention it for clarity. It might be useful if someone compromised root, that they wouldn't necessarily have access to the data on your VM's. But that's a lot more password juggling and layered encryption with associated CPU cost, so I dunno. (Qubes VM Manager would end up being a bit of a password vault in itself, ugh.) I'm only pointing these out in a constructive way, I still love the system, and just want to suggest ways to make it even better for those who don't spend the time or have the knowledge to tweak up these security risks. 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/658ef4d3ad89a3b9db896d1ff6fa27a0.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Error converting vmdk disk to raw
> I'm having same issue, I know there is enough space because df -h shows > 198G available and qemu-img-xen info image.vmdk shows that the virtual > disk size is 8G I've had cases with the qemu tools where it reported a write error because it had trouble reading one of the input files (corrupted, I think it was, or maybe a usage error). Put a "strace -o /tmp/log.txt" before your command, and go look at the system calls that resulted in it giving that error message. You might see a read error, or more specifics on the nature of the write failure. 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/188acf2835438040b31c2bfdd6b70c65.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Loaded ethernet device modules in dom0, sound
(Accidentally posted this to the tail of another thead; I assumed a subject change would create a new thread. Whoops. Reposting.) Why is it that the linux module for my ethernet device is loaded in dom0? There's obviously no networking, /proc/net/dev and ifconfig only show localhost. The module is also loaded in, and provides the device to sys-net, of course. Seemed odd to even have networking device Linux modules (existing) in dom0 at all. It's slightly uncomfortable to see, lol. Is there a reason for this? Also, where audio has reportedly been used for exfiltration of data by even air-gapped machines, it's always a good idea to disable audio in VM's that don't need them (net, firewall). It's also a waste of memory/CPU (on startup at least), to load pulseaudio and its dependencies. The System Tools -> Pulse Volume Control (and the other Pulse menu items) give you finer control over per-VM audio device access. Similarly, turning off input audio device access for most VM's is probably a good idea too. Is there perhaps a way using the VM's services tab to disable the pulseaudio server on a per-VM basis? Also, what's the PC Speaker driver in the VM's? Can it arbitrarily play tones on the sound card in dom0? Again, slight risk of data exfiltration on air-gapped machines, if so. I leave my speaker disconnected, but again, it's still using a bit of memory/CPU to load an unnecessary driver. I don't need beeps from sys-net/sys-firewall. Are there any thoughts of moving sound cards out of dom0? Where the VM's much forward their audio to dom0 and its sound card, can this instead be directed to a separate VM which is assigned the PCI sound card? Thanks. 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/e63f92bbc5fc49ae6bbb484ba0cbdec0.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Low memory, starting machines & assigning devices
Hi, Qubers: Wonder if someone could tell me if this is normal/expected behaviour. (3.2rc3): If I have a few AppVM's running, at some point, the manager will refuse to start any more VM's, complaining about low memory. Similarly, assigning devices to running VM's will fail. (Most annoying.) However, if I close a few apps in the VM's (a big Firefox or two will typically do it), then I'm able to fire up a new VM & assign devices to the running ones, and am THEN able to relaunch the memory-hungry app/apps in the existing running VM's with no problem. (Typically at this point, swap is used a bit in dom0 and sometimes the VM's, but things still work. Swap being required to hold the new situation may be the distinguishing factor...?) The fact app-close -> start-another-vm -> app-restart works while simply starting the start-another-vm fails, seems a bit odd to me. In fact, I've modified my habits when using Qubes to fire up all the AppVM's I might need, right at boot time, so I won't have trouble starting them later when apps are running. That just doesn't seem right, and having to restart apps can cause bottlenecks in one's workflow. Thoughts? Anything further I can check to help track down the reason for this? Anything I can do memwriter/mem-balancing wise to help things? Thanks. 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/2a7f939668c64b529ba119152914ceb7.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Loaded ethernet device modules in dom0, sound
Why is it that the linux module for my ethernet device is loaded in dom0? There's obviously no networking, /proc/net/dev and ifconfig only show localhost. The module is also loaded in, and provides the device to sys-net, of course. Seemed odd to even have networking device Linux modules (existing) in dom0 at all. It's slightly uncomfortable to see, lol. Is there a reason for this? Also, where audio has reportedly been used for exfiltration of data by even air-gapped machines, it's always a good idea to disable audio in VM's that don't need them (net, firewall). It's also a waste of memory/CPU (on startup at leas), to load pulseaudio and its dependencies. The System Tools -> Pulse Volume Control (and the other Pulse menu items) give you finer control over per-VM audio device access. Similarly, turning off input audio device access for most VM's is probably a good idea too. Also, what's the PC Speaker driver in the VM's? Can it arbitrarily play tones on the sound card in dom0? Again, slight risk of data exfiltration on air-gapped machines, if so. I leave my speaker disconnected, but again, it's still using a bit of memory/CPU to load an unnecessary driver. I don't need beeps from sys-net/sys-firewall. Are there any thoughts of moving sound cards out of dom0? Where the VM's much forward their audio to dom0 and it's sound card, can this instead be directed to a separate VM which is assigned the PCI sound card? 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/9d649acd83630ac192261f426c4345b3.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 3.2rc3 install on btrfs
Finally got around to doing a fresh install of Qubes 3.2rc3 on a btrfs root. It's quite wonderful, being able to clone a template or an AppVM instantly, taking no additional disk space except for changes. However, after the initial install, I had sys-net, sys-firewall and had to create them manually. Wasn't a particularly big deal, but could stump or turn off a newbie. Also, none of the appmenu shortcuts from the debian, fedora, whonix templates showed up, until I manually forced it from dom0. I didn't see anything obvious in the anaconda or qubes logs. Any suggestions of where I might look for what went wrong? At what point in the install should sys-net/sys-firewall and the syncing of appmenu shortcuts have taken place? Thanks 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/80d97edfe2c936e05e93d693bb4b322b.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB VM
> Hi JJ, > > Did some more testing, you were right, I only have 3. Hey, that's still pretty handy for separation. In Qubes VM Manager, for a chosen VM, you *should* be able to pick a given PCI USB device and assign it. Only having one USB bus myself, also used for root, I haven't tried this. I have a USB PCI card I've been tempted to use for similar reasons. But once again, it was given to me out of the blue, which doesn't put it in my "trusted hardware" chain. Not that *any* use bus or device should ever be trusted, the main motivation for us stuffing them in a VM. :) > 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. Agreed, it should work, from my understanding. You reboot after assigning things? There's some protection about PCI devices not being allowed to go back to dom0 for reassignment after use, to protect against potentially compromised devices then touching dom0 (to DMA-attack away): https://www.qubes-os.org/doc/user-faq/#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0 Not sure if that's relevant or not. I'm over my head with this, and just guessing, so I probably shouldn't be giving advice, lol. > 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. Makes sense to me. (Again, getting those darn keyboard/mice off of USB and onto PS/2 certainly wouldn't hurt figuring things out.) > So why does it have the error? dmesg have any hints? (Or is that where the error messages your are seeing are coming from in the first 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/0d5958c755d11fdad9df1c519e23c032.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
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
> 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] 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. A bit late to the party (as they say) in this discussion, but why is it so important to suspend/restore in the first place? I'm generally not one to rationalize a bug by saying "well, just don't do that," or "don't use that feature"; but the whole suspend/restore thing does seem to add a layer of complexity to the whole security mess, with a lot of CPU/BIOS/motherboard dependencies and such. It's never worked well for me, from the days of the first laptop that promised to suspend/restore, up until my last Macbook. :) Maybe I've just lost one too many sessions from a failed suspend/restore, that I've been turned off of the feature. Or maybe I just don't leave the house enough. I like to leverage all the hardware/software features I can, but suspend/restore never seemed worth the trouble in most cases. Suspend/restore doesn't quite reach the 26x increase in complexity I perceived in the Wifi vs. Ethernet comparison, but it's probably at least 2x or 3x the complexity and dependency upon a variety of processor/mobo features. For a laptop on the go, okay, I can see the argument. But I don't think most Qubes users are on laptops, given the hardware requirements. (Very much moreso with 4.0. :P) Correct me if I'm wrong. Why do you need to suspend? A good, strong, password for your user account, making sure you have physical security (or at least awareness if it's been breached), and/or shutting down when you need to, works fine for me. (At last I hope, lol.) It would be nice to see "xl save" and "xl restore" (which basically hibernate a VM) smoothly integrated into Qubes, so the VM Manager supported it, or at least was aware of it. Which would reduce the need for a true hardware suspend/restore (if you can restore a VM fully after a full reboot). But if you need to keep your current state, why not just keep the machine on? (And securely locked/monitored?) I'm hardly flush with cash, but the electricity cost of keeping a PC on 24/7 isn't exactly breaking the bank. And the alternative of shutting it down (and taking the disks with me) when I leave, isn't terribly inconvenient, w.r.t. the risks, either. Apologies if I completely missed the point, as I so often do. And maybe I'm wrong and most Qubes users are running around with high powered, compatible laptops. I'm just looking to find out the motivations for such a feature that brings additional complexity. 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/674a707e5014ac6d0121137f1d9616bb.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] Re: I can't disable ipv6 on Debian Template
> 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. I guess I realize that Tor and other networking systems require accurate time, I'm just wondering, protocol-wise, *why*? TCP/IP doesn't care. Is the time rolled into some security hash to prevent replay attacks or something? (If so, that'd be easy to fake.) Or is it for timeout purposes, to give up on a sluggish route (in the case of Tor) and choose another one (or something to that effect)? If so, do you really need second accuracy for that? Just curious as to why there's a need for all this time syncing. 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/0fde654b3f2726fa60a9fe07b470246e.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
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] 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 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] 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.
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
Re: [qubes-users] Restored, and it's missing so much...
> Hmmm, you would probably also need to re-export the app shortcuts to dom0. > This *may* be the best way to do it, but the Qubes devs may have a better > suggestion. Open a terminal in the newly restored VM and run: > > "/usr/lib/qubes/qrexec-client-vm dom0 qubes.SyncAppMenus /bin/sh > /etc/qubes-rpc/qubes.GetAppmenus" Whoops, scratch that. As always, the Qubes' devs have already taken care of that, and have a better, more official way. From dom0: "qvm-sync-appmenus " (And, of course, the appmenus come from the VM's templateVM, not from the AppVM, which I neglected to mention. So you only need to do that if you're restoring a TemplateVM, not an AppVM.) 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/256780391417c64d27352f0d917561b3.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Restored, and it's missing so much...
> I just copied my standalone VM that was working, to back it up. > > Then I restored the .img files, which is the HDD, and now it's telling me > I don't have the dependancies to run the application that I was running > before I copied the img files. > > Why is this broken? > Why will backup/restore not let this work properly? By backup/restore I assume you don't mean Qubes backup/restore feature, but you copying .img files around manually, correct? What exactly is "telling you you don't have the dependencies to run the application?" Which application? (Do you mean when you try to use the VM's start menu shortcuts?) There's more to an AppVM than just the files in the directory. (I think most other info about the AppVM's lives in /var/lib/qubes/qubes.xml.) Obviously this isn't a "supported" method, but here's what I've done in the past to restore some VM's when my Qubes install got trashed (due to filesystem corruption of running on an external USB drive, and being a bit sloppy about the fsck repair): For each AppVM, create a new, empty AppVM with the same settings as the VM you wish to restore. Then (making sure the VM isn't running), replace the .IMG files of the new VM with the ones from the old VM to be restored. Then add any shortcuts you have had before. Worked like a charm. Hmmm, you would probably also need to re-export the app shortcuts to dom0. This *may* be the best way to do it, but the Qubes devs may have a better suggestion. Open a terminal in the newly restored VM and run: "/usr/lib/qubes/qrexec-client-vm dom0 qubes.SyncAppMenus /bin/sh /etc/qubes-rpc/qubes.GetAppmenus" (Borrowed from /usr/lib/qubes/qubes-trigger-sync-appmenus.sh, but that looks like it might only do that if changes have been flagged. I'm guessing a bit here.) Or just install any new package with apt-get, and the menus should sync. Then re-add your shortcuts in Qubes VM Manager. It would be convenient if qubes.xml were "deconstructed" a bit into separate human readable config files stashed in each VM's directory; but that might not be great for performance. Most other things about a VM are fairly accessible and intuitive, except for qubes.xml. (Also, when copying around .IMG files, make sure you use "cp --sparse=always" to preserve the sparseness, otherwise the new destination will take up the full listed size of the file, and not just the allocated blocks, as well as taking a lot longer. "ls -ls" will show the actual allocated block count of your files.) 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/3de9d0f3b16a3cef77a62d286887d739.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Snapshots - Use of CoW
> On Monday, 26 September 2016 12:11:56 UTC+10, johny...@sigaint.org wrote: >> AppVM's are designed to toss changes, other than /home, /rw, /usr/local. >> It's a good thing; if one gets compromised, it's a temporary compromise. >> :) >> >> If you want permanent changes, update your template. >> >> But it sounds like you might want a "standalone VM": > > Hi JJ, I know it's meant to, but if I'm testing something, I want to > install pre-requisites for things, then it may have to restart, then I > want to take a snapshot, then perform the next step, then do another > snapshot, and revert if I need to. Fair enough. That's something I also would find useful, and is why I'm switching to btrfs root soon. >> Also, using BTRFS as a root (or VM host) filesystem should allow you to >> snapshot/rollback the standalone VM to your heart's content (and clone >> it >> instantly). BTRFS is all about the copy-on-write. > > I'm not going to use that on an SSD, that creates way too many writes. As > far as I've read and know, correct me if I'm wrong, BTRFS is a journaling > file system, meaning it writes the changes that it's going to make to the > journal, and then writes the changes to the disk. This means it writes > everything twice. > On an SSD that isn't good, it decreases the life of the drive by over 50%. >From the BTRFS Faq: "There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd. " "Mount -o ssd_spread is more strict about finding a large unused region of the disk for new allocations, which tends to fragment the free space more over time. Mount -o ssd_spread is often faster on the less expensive SSD devices. The default for autodetected SSD devices is mount -o ssd. " Doesn't sound too bad to me. Are SSD's really that prone to wearing out quickly? Ignoring spare files, if you consider that a reflink copy of, say, a 2G file (such as a VM .img file) takes almost no disk activity on BTRFS (just a metadata cloning due to the COW nature), while ext4 churns away reading/writing the full 2G of data, I'd say that BTRFS could *save* you a whole bunch of wear on your SSD. snapshotting and reverting under BTFS is near immediate, versus copying of multiple large files; seems like a no-brainer in favor of BTRFS. >From another page: "Btrfs is SSD-aware and exploits TRIM/Discard to allow the file system to report unused blocks to the storage device for reuse. On SSDs, Btrfs avoids unnecessary seek optimization and aggressively sends writes in clusters, even if they are from unrelated files. This results in larger write operations and faster write throughput, albeit at the expense of more seeks later." And: https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html And: https://www.linux.com/learn/weekend-project-get-started-btrfs which comments: "the system uses a copy-on-write strategy that writes changed data to disk first, then updates the references in the tree. This crash-proofs the filesystem, but without the overhead of maintaining a journal." (That article was six years ago, not sure if things have changed, but on a quick search I couldn't find any reference to BTRFS using journaling.) In fact, the wiki page on journaling filesystems: https://en.wikipedia.org/wiki/Journaling_file_system#Alternatives considers BTFS and COW-based filesystems as *alternatives* to journaling filesystems: "Full copy-on-write file systems (such as ZFS and Btrfs) avoid in-place changes to file data by writing out the data in newly allocated blocks, followed by updated metadata that would point to the new data and disown the old, followed by metadata pointing to that, and so on up to the superblock, or the root of the file system hierarchy. This has the same correctness-preserving properties as a journal, without the write-twice overhead." So your fears may be unfounded, and you might be missing out on a tech that provides exactly what you need. :) > This is why I use EXT2 Filesystem, even in the templates. (The templates > were originally EXT3/4 if memory serves, as an LVM. Flying without a journal (especially wrt metadata) is a bit bold in this day and age. :) > Well, I can't use Qubes 4.0, because you are FORCING it to REQUIRE > technology in the CPU that my Multi-CPU system doesn't have. That's a thorn in my side as well, but possibly the price of progress. 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/3f782b239892ed875d93497ab3d1.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] I can't disable ipv6 on Debian Template
> Really ? No one to find also suspicious a wild init/1 tcp6 port listening > on your templateVM, right out of the box ? This got to be real. ... > I am answering you on my phone just because it seems my old Qubes deleted > partition doesn't like very much my USB key to runs over it, for some > reason. And this is pissing me off. ... > So let me rephrase : how do you completely remove Qubes OS from your hard > drive so that eventually it might still accept another OS install ? Fuck > this shit. ... > Btw on any decent OS you can clear your own partitions on installation > window and refresh your own disk without installing the OS. On Qubes you > can't. You are supposed to run the install to do so. And it seems the > install fucks your hardware next -.- ... Ummm, I think I'm tending to agree with Unman's suspicions: > and I wonder if it's a troll anyway, when I look at some of the > later comments. I deem thee a troll. An angry, foul-mouthed troll. Or someone who has an agenda against Qubes' goals. Either that, or you're in way over your head technology-wise and don't have the patience to work through it, even with a community trying to help you. I might suggest you go install Windows (or buy a tablet) and take out your anger elsewhere. 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/4144e1e93b958945a74aedbb99685c7f.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> Wow. Not even 4 GB of compiled drivers for the WiFi. You are saying it's 4 > GB of raw plaintext source code..? > > WOW > > That's INSANELY complex. Apologies, I spoke a bit hastily. What was seeing was 4 million Git objects, not 4G of data (although it may be). And that included all branches and all the history of the repo, so it's not a fair measure. (In my defense, back in my day we used "rcs" and we got along just fine. Then we switched to "sccs." Then "cvs." Then "svn." Then "git." One needs a version control system just to keep track of the version control system that is currently in vogue.) I just checked out the master branch and it clocked in at 917 meg. Still not exactly lightweight. No single directly was above a Megabyte. There is just lots and lots and lots of directories. :) Plus, the source tree contains filesystem implementations, tools, etc., etc.. Within the master branch, drivers/net/wireless clocks in at 34 meg (getting a bit more reasonable, lol). Some stats: the total line count of all the .c and .h files under drivers/net/wireless is just over a million lines of code. There were 1310 .c/.h files, which averages out to 770 LOC per .c/.h file. They represent device support for 15 different vendors (and no doubt supporting more brands of similar devices, with OEM rebranding and such). Somewhere in the neighbor of under 250 different device variations supported (although that is a rather clumsy measure based upon defines in Makefiles; I'm getting tired, lol). An example of the biggest files and their lines-of-code: 28721 ./broadcom/brcm80211/brcmsmac/phy/phy_n.c 12061 ./intel/ipw2x00/ipw2200.c 10630 ./broadcom/brcm80211/brcmsmac/phy/phytbl_n.c 10318 ./broadcom/b43/radio_2056.c 8646 ./intel/ipw2x00/ipw2100.c 8231 ./ath/ath10k/wmi.c 8224 ./cisco/airo.c 8139 ./broadcom/brcm80211/brcmsmac/main.c 8066 ./ath/ath10k/mac.c 8027 ./ralink/rt2x00/rt2800lib.c 7018 ./broadcom/brcm80211/brcmfmac/cfg80211.c 6873 ./intel/iwlegacy/4965-mac.c 6726 ./broadcom/b43/phy_n.c 6652 ./ath/ath10k/wmi.h 6575 ./ti/wlcore/main.c 6348 ./marvell/mwl8k.c 6334 ./realtek/rtl8xxxu/rtl8xxxu_core.c 5872 ./broadcom/b43/main.c 5594 ./intel/iwlegacy/common.c 5511 ./ath/ath9k/ar9003_eeprom.c 5247 ./broadcom/brcm80211/brcmsmac/phy/phy_lcn.c 4843 ./realtek/rtlwifi/rtl8821ae/phy.c 4706 ./ath/wcn36xx/hal.h 4572 ./realtek/rtlwifi/rtl8821ae/table.c 4549 ./atmel/atmel.c 4337 ./marvell/mwifiex/cfg80211.c 4305 ./broadcom/brcm80211/brcmfmac/sdio.c 4230 ./intel/iwlwifi/mvm/mac80211.c 4170 ./ath/ath6kl/wmi.c 4143 ./realtek/rtlwifi/rtl8821ae/hw.c 4097 ./intel/iwlwifi/mvm/rs.c 4062 ./broadcom/b43legacy/main.c 4046 ./intersil/hostap/hostap_ioctl.c 4036 ./ath/ath6kl/cfg80211.c 4008 ./intel/iwlwifi/dvm/commands.h 3965 ./ath/ath5k/phy.c 3959 ./intel/iwlegacy/3945-mac.c 3878 ./broadcom/b43/tables_nphy.c 3861 ./realtek/rtlwifi/btcoexist/halbtc8821a2ant.c 3819 ./realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 3774 ./rndis_wlan.c 3626 ./realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 3594 ./realtek/rtlwifi/rtl8192de/phy.c 3576 ./ath/ath10k/wmi-tlv.c 3370 ./intel/iwlegacy/commands.h 3180 ./ath/ath9k/ar9002_initvals.h 2456 ./broadcom/b43/tables_lpphy.c Some of the bigger files seem to be tables used for radio communication, possibly DSP-like tables to drive things (and nary a comment to be seen), and (thankfully) not so much binary chunks of proprietary code. Others are large in order to interface with (and/or implement?) complex modem command sets. And probably many other reasons. But that's a quick sampling of the fun. Similar to my hasty comments on the code size, my complaining about how the code was structured turns out not to be specific to the wireless, but is a common approach for kernel configuration and drivers in general. But it's safe to say the complexity is an order of magnitude greater than for ethernet. > A bit like how people have said phone basebands are incredibly complex, > not to mention, closed source. I've come to think of basebands (in phones, for example) as like ISP's, a bit beyond your control, and as things that should be compartmentalized hardware-wise and treated as potentially hostile. Sadly, I think many phones today aren't implemented in that spirit. One horrific example of getting things completely backwards (allowing the baseband to freely probe around and modify the phone's memory, ostensibly in the name of support, I suppose :S) is the "Samsung backdoor": http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor Replicant, a stripped-down non-proprietary fork of Android, tries to isolate and not play well with that baseband feature, effectively treating it as potentially hostile. Sad that it's necessary. "Our free software replacement for the incriminated binary is Samsung-RIL which relies on libsamsung-ipc: both are used in Replicant.
Re: [qubes-users] I can't disable ipv6 on Debian Template
> What does "systemctl list-sockets" show? Any services that systemd is > providing a listener for should be listed here. If you do spot a network socket service in that listing, you can stop the current service with "systemctl stop blah.socket", and disable it in the future (next reboot or VM restart) with "systemctl disable blah.socket". There's always the potential that it could be re-enabled in the future by installing another package dependent upon that service. (That's bitten me a couple of times.) To block that from potentially happening, use "systemctl mask blah.socket" and the service will stay off regardless of new dependencies. ("systemctl unmask" undoes the blocking. Go figure.) Oh yeah, to have those commands truly "stick," you should run them from the template, not the AppVM. Slight digression (from JJ, no way?!?!?): There's a few config things like this (e.g. /etc/fstab) that I really think should be (by default) symlinks to /rw/config, so they could be tweaked on an per-appVM basis. (At risk of a compromised VM being able to have more lasting hack-related effects after a restart.) It's easy enough to do in the template/appvm yourself, of course. e.g.: # cp /etc/fstab /rw/config/fstab && ln -s /rw/config/fstab /etc/fstab in the TemplateVM. You could similarly do that with any systemctl config files that you need different on a per-appVM basis. 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/ad4e21c34c3cab74a369f046abeb277b.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] I can't disable ipv6 on Debian Template
> Thank you guys for your help, but unfortunately I don't think there is a > way to get rid of this process listening on tcp6 on init (systemd... d > standing here for distant...). It is listed as 1 on PID, I don't think you > can't remove it, it is a main process. So I am not interested in using > Qubes anymore because I disapprove those bad policies on respect of > privacy. systemd listens on sockets on behalf of other services (and fires them up when a connection arrives, similar to "inetd" in days of old). What does "systemctl list-sockets" show? Any services that systemd is providing a listener for should be listed here. The configuration files that control such behavior could be shown with: > sudo find /usr/lib/systemd /etc/systemd -name '*.socket' This may also reveal useful information, but the above is probably sufficient: "sudo lsof -i -p 1" 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/d78f57a37c459a66ba5cd74b4154a8c2.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> Please read if you haven't already: > > http://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf > > 2 big takeaways: > > 2. The Physical Gateway needs to be secure not only from attacks from the > Internet but also attacks from the client appVM. Haven't read the paper yet (will definitely do it), but that's a very intriguing point. > 1. A typical networking stack presents a huge attack surface. In response to the original poster (and for my own curiosity), I was going to take a look at the Wireless drivers for the athlon 5k cards (no CPU on board). Google landed me at the Linux wireless driver site, so I went to grab a Git clone of the latest wireless driver source. Four gigabytes! Yeeeouch. So I ^C'd that, and will just go digging through the drivers in the kernel source tree instead when I get a chance. (Maybe a lot of that is firmware blobs or something, I don't know; I'll take a look in more detail when I get a chance. But regardless, the attack surface must be big.) The WiFi stuff is hard to navigate, a lot of shared common code, endless configuration files with definitions that enable/disable certain chunks of code for different chipsets and cards and features, and so forth. I had trouble even finding the relevant any relevant .c file, so much of it was configuration macros. Most of the code seemed to live in many, many different .h files instead. My head hurt, so I went to bed, lol. Needless to say, none of that increased my confidence in WiFi. Ethernet is far simpler, and thus, IMO, safer. (When I do take a look at the code, probably tonight, I'll post a comparison on lines-of-code between a typical WiFi driver and Ethernet driver. I wouldn't be surprised to see a 10:1 ratio, if it's even possible to find enough separated code to do a comparison.) As a quick binary module comparison, and not necessarily a fair one (as the WiFi stuff no doubt drags in other modules): Ethernet driver for a 3com card: /net/ethernet/3com$ size 3c59x.ko textdata bss dec hex filename 415112968 49 44528adf0 3c59x.ko Ethernet driver for an ath5k card: /net/wireless/ath/ath5k$ size ath5k.ko text data bss dec hex filename 1535451529 8 155082 25dca ath5k.ko ath5k.ko has a number of undefined symbols relating to ieee80211 (WPA2), so just *one* of the modules it would depend upon is this: /net/mac80211# size mac80211.ko textdata bss dec hex filename 529986 53348 64 583398 8e6e6 mac80211.ko Oh, and also this, just for WPA: /net/wireless# size *.ko textdata bss dec hex filename 380654 713953656 455705 6f419 cfg80211.ko 36881088 0477612a8 lib80211_crypt_ccmp.ko 66961168 078641eb8 lib80211_crypt_tkip.ko 2166 968 03134 c3e lib80211_crypt_wep.ko 2132 992 43128 c38 lib80211.ko (Other than net/netfilter, net/wireless is the largest sub directory in the net driver module hierarchhy.) The Wireless drives no doubt bring in many other modules for the other encyrptions and features. (The Ethernet stuff likely brings in other stuff as well, but probably the same core ethernet dependencies are also required by the wireless stuff) >From that very quick comparison, it's a minimum of 26x (!) more code just for the ath5k+WPA2 support, versus the driver for a 3com ethernet card. 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/6008c7066cc61d8632f3473c35f3e146.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> And yes, by all means, I will use Whonix's system rather than my own > custom script. I agree that Whonix is a key component. A NetVM that ensures *all* your traffic goes through Tor, with no leakage, as well as doing secure DNS lookups for you, is a big security plus. They've also put a fair bit of work into the iptables (i.e. firewall) configuration of the sys-whonix Network VM. Something I had expected of Qubes, and a bit more on par with what Tails does. And Whonix is more of an open sourced "configuration" rather than a code base. It just ties other established pieces together solidly, and configures them well. And you're free to check it out and put together yourself, no coding required. In System, Global Settings, it's good to make sys-whonix your Update VM as well, reducing MITM risk during the update process. As well as making it your Clock VM, to avoid clock synchronization leaks. (apt-get-transport tor is slightly preferable, since it goes directly to Debian's hidden service, encrypted of course, for updates. But hopefully package signing would reduce any risk for dodgy exit nodes and the like when using sys-whonix for updates.) It's worth noting that using whonix does increase the number of trusted parties from two (Fedora + Qubes devs) to four (Fedora + Qubes + Debian + Whonix devs). More repositories/updates for potential threats or bugs. But where all are open source, that's probably not a big additional security risk. The benefit far outweighs the risks, IMO. 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/9b6ce2e7b0a256e05bad31d067da1cbf.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> Well, entr0py, you are correct. > > It does indeed come down, to either Xen, or my networking stack. > > Let me ask... what is the security like for Ethernet..? Anything going over a wire is going to have a far shorter RF leakage range than WiFi. Unless your threat actor is in the house or next door, ethernet is hard to beat for security (and simplicity). WiFi protocols are (obviously) over the air, which is inherently more vulnerable. Plus they're more complex, and complexity is no friend of security. WiFi (protocols and hardware itself) is a pretty juicy target for NSA and state actors, so you know a lot of effort is being put into that. Ethernet is pretty well-established and boring as compared to WiFi. https://en.wikipedia.org/wiki/Wireless_security That being said, there is an argument that since WiFi is encrypted by default (usually), and Ethernet isn't, WiFi may be considered more secure in that aspect. But you can certainly (as discussed before) make sure everything going over the ethernet cable is encrypted. But WiFi has had a pretty bad track record of security (WEP, WPA, WPS all considered crackable), so I'd stick with wired. If you're paranoid, make sure your cable runs are short and RF-shielded. WPA2 (a.k.a 802.11i) is considered secure for the long run; but given the complexity, and the aggressiveness of state actors and crooks to put backdoors and bugs into the protocols and hardware, I'd stick with ethernet. Broadcasting and security don't mix, even with encryption. If someone sneaks onto your ethernet, they'll have to it by tapping into an existing wire, picking up RF leakage, or plugging into your cable modem. Pretty noticeable and containable. If someone sneaks onto your WiFi network somehow, you likely won't notice. A few points about WiFi routers: - Often the admin pages are just http, not https. So anyone on your network (legitimately, or not) can snag the cable modem credentials and later reconfigure you modem to redirect traffic to themselves, or whatever. - Make sure your admin password is long, random, and unique. Only administer it or change the password when WiFi is off and you're the only one connected on ethernet. - Turn off SSID broadcast. Users can type in the network name (something non-guessable, not just "linksys" or "dlink",lol). - While Mac address spoofing is easy, it still can't hurt to turn on Mac authentication, so only listed Mac addresses are permitted on the network. If they can't otherwise snoop on the network, they won't know *which* Mac addresses to spoof, so it could help a bit. - I also turn off DHCP serving (for both WiFi and ethernet). It's not that inconvenient to manually type in the address, gateway, DNS. I use an unusual IP address range as well. None of those necessarily add significantly to security, but they sure don't hurt, especially for the less sophisticated threat. And don't use your ISP's DNS. It's trivial for a small-time privately-owned provider (or the NSA tapping into the same) to hijack DNS and send you to a spoofed site. Google's 8.8.8.8/8.8.4.4 is quite popular, if you trust google inherently. (I don't.) Open DNS's 8.26.56.26 is also popular, but it does redirect to ads for unrecognized sites, which isn't particularly cool. I prefer using my commercial VPN provider's DNS server. If I can't trust the VPN provider, my security is toast anyway, so I might as well trust their DNS too. :) To me, a good commercial VPN provider is one of the few "stakes in the ground" you have to place and trust. (Also, I connect to my VPN provider by IP address, which I verify several different ways, rather than by DNS lookup.) Also, if you run whonix or Tor, it can do the DNS resolution for you over Tor, which is great for security and preventing DNS leakage. If you do serve up DHCP from your cable modem, put in your preferred DNS server there, so any clients automatically use it. But in general, don't use WiFi if you're concerned at all about security. :) > Let's say I connected to my home router via Ethernet, and also served out > the Tor connection to a 2nd laptop, over Ethernet. > > In this setup, there is no WiFi at all. > > Would that make things more secure..? I would say yes, unless there's someone nearby who can pick up leaking RF from your ethernet connection, a fairly rare and manageable threat. I turn on WiFi when friends, family, my kids, are over, or for casual browsing (with a VPN layer on top). But never for anything work related or personal. Otherwise it's off. (Some modems have a button to do that; but make sure it's not a WPS configuration button, because that's insecure.) Interestingly, I noticed my FM radio, tuned to around 100 Mhz (go figure) picks up Ethernet noise. It's a good ghetto way to see how leaky your cables might be. For my wiring, moving a foot or so away from the cable, and you don't hear anything. (I have one VOIP phone which just screams RF noise in the 100 mhz range.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> OK, so the main takeaway from your answer: > > "The card doesn't have a host CPU and so it doesn't require a firmware > source" > > that seems like the most interesting > > the driver would still need to be bug-free though > > who knows whether any of these have even been audited I think the wireless drivers are fairly well reviewed, and from a quick glace, there seems to be a lot of code sharing/reuse between drivers. I plan to look a bit closer at the ath5k driver when I get a chance to see the nature of that hardware. A couple of other points: - This may go without saying, but any USB-based networking device, and all security bets are off (right Andrew? :) ). While PCI is an electrical specification and hardware protocol, USB is a far more (overly) complex protocol that out of necessity requires a USB controller, which is, of course, a CPU in its own right. Which, if compromised, could suddenly pretend to be a keyboard and send you to a malware site to load up, when you're not looking. :) - More importantly, by separating out your laptop from Qubes, I think you might be *increasing* your risk, not decreasing it: I believe one of the common threat models is, for example, a state actor backdoor placed in your NIC that is activated by a special sequence of data that could be present in a web page you're coaxed to (or faked with a MITM tampering), or in an email sent to you, or whatever. When your NIC sees the magic string "GiveMeYourStuff", it starts DMA'ing around and sending off the contents of memory, including any keys, disk cache, data, whatever. Not good. The NIC in sys-net sees that magic string, and it sends away sys-net's memory. No big deal. That's boring, stock stuff that's mostly the same on any Qubes setup. There's nothing of use there. Of course, it could tamper with the net connection content as well, but with Tor (in another VM), that won't buy the attacker anything but seeing encrypted traffic. The VM isolation has done its job. And, in fact, since sys-net is *only* seeing encrypted Tor traffic, it shouldn't be possible for it ever see that "GiveMeYourStuff" magic string that was on a web site or email, but its triply-encrypted Tor version. (Now, if someone unilaterally blasts a packet with that magic string right to your IP address, your sys-net compromised-NIC is going to see it and do its thing, regardless of other tor traffic going on. This occurs at the hardware level, before iptables gets to do its thing, too, so no help there. Thus, you really do need that sys-net isolation.) Now, the more interesting part: your laptop. It's connected to the Qubes box via ethernet and internet sharing, also has a NSA/orgcrime backdoor'd NIC installed at the cooperative manufacturer's factory, or through mail interdiction. You go to read your Google Groups but the page is intercepted/redirected to the attacker's page. Or you're sent an email with the magic string in it. Or you read my sneakily malicious post that includes the magic words "GiveMeYourStuff." While that string arrives in sys-net and sys-tor on Qubes encrypted, once it passes through tor and is decrypted, it is passed cleartext over the crossover ethernet cable to your laptop's NIC. It sees "GiveMeYourStuff" at the hardware level, in the clear, and takes its cue to DMA through your Laptop's memory, phoning home (conveniently over your Tor connection, which doesn't hurt the attacker, since it comes out of the Tor exit node to be sent to the attacker's site decrypted). By separating out your Laptop from Qubes, you're failing to protect your laptop's NIC (and thus your whole non-VM'd laptop). The *content* you send and receive from your laptop will be encrypted in transit, which is good. But any attacks on your laptop NIC from dodgy sites or phishing or magic email are still as much present as if your laptop were directly on the Internet. In effect, it *is* directly on the Internet, just with a path between sys-tor->guard->relay->relay->exit-node->Internet Site encrypted during transport. It provides you privacy, and protection against MITM in the Tor Network, but it doesn't provide protection from the Internet at large. All NIC's, including the Laptop, need to be isolated in a sys-net VM of some sort. Now, unless your laptop has one of those CPU-less NIC's (unlikely) or you manage to find a NIC for your laptop that isn't USB (challenging) and that doesn't have a CPU or other processor on it (such as those listed on that Wiki page), you probably avoid that threat. That's a lot of "if's." Running Tor or TorBrowserBundle on the laptop itself could mitigate that risk, since the laptop's NIC would only be seeing encrypted traffic, and not open to that threat model. Your setup seems to be premised upon the tethered connection providing the Tor functionality. Unless you somehow isolate your laptop NIC or get one with no CPU/processor, you're better off keeping Tor/Tbb on the laptop, not the Qubes gateway m
Re: [qubes-users] Snapshots - Use of CoW
> Hi folks, > > Any chance that there will be added in the feature for snapshots? > even CoW snapshots would be good, then a consolidation option once done. > > I have one issue where I want to do something, but I have to 7z the VM > before I can do anything to it in-case it breaks. > > I know that there are CoW options there, but how do I access them? > You already use the technology since 2.0, but I have not seen it go > anything beyond that for the dispvm and the like. > > the AppVMs, they have CoW for them, but it's not persistant on the CoW > file, that file is destroyed after the VM is shut down. > > I tried changing it to not be destroyed on shutdown when it used a CoW > file, but Qubes just tell me to get stuffed and destroys it once the guest > is shut down. > > How can I fix this please? AppVM's are designed to toss changes, other than /home, /rw, /usr/local. It's a good thing; if one gets compromised, it's a temporary compromise. :) If you want permanent changes, update your template. But it sounds like you might want a "standalone VM": https://www.qubes-os.org/doc/software-update-vm/ Also, using BTRFS as a root (or VM host) filesystem should allow you to snapshot/rollback the standalone VM to your heart's content (and clone it instantly). BTRFS is all about the copy-on-write. 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/580fa3f46fe08c86d235378638dd584c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> Yeah... and surely this is exactly what can happen, no..? > > We had 2 Xen exploits in the last 1 year. I expect those exploits have caused a lot more scrutiny of the code, so hopefully such exploits won't be heard of again. Qubes devs are moving away from PVM which should avoid the threat of such exploits as well, from my understanding. > Surely a compromised sys-net can just run a Xen exploit, and can then > breach into any other VM, including dom0. > > This is the whole reason why I decided to use 2 laptops.. because Xen is > not secure. Well, if you're going with that assumption, then you best get Tor off Xen/Qubes all together, so your Qubes box is only seeing encrypted traffic. But then, do you trust your laptop more so? And if so, why are you using Qubes at all? You're going to end up with a string of four or five PC's before you're done, and probably no more secure. I jest, but only somewhat. :) You have to start trust somewhere, and I think Qubes/Xen is one of the most promising and secure systems available (even Snowden seems to agree). Xen has had two significant bugs. How many times have devices/systems been compromised by the NSA or other state actors and crooks? I'm guessing the number has several more digits than the number "2." > So, I think the solution is to simply use a WiFi and Ethernet that do NOT > have any bugs in the first place. And I'd like a government, police force, courts, business, and social world with zero corruption and zero crooks. The government can backdoor everything it wants in such a perfect world. I think such expectations are about as realistic as finding a completely safe NIC. It's not just bugs you need to worry about, but gear that is intentionally compromised by NSA or organized crime at the factory, or in transit, both of which are realities. And if the NSA puts a backdoor in place, with the best of intentions, that doesn't mean that crooks (or spurned LOVINT users), inside or outside of the NSA, can't abuse it. Frankly, I'm coming to the opinion that NSA and other state actors have broken the tech world so badly that I no longer want to be part of it. I just can't promise security to potential clients any more, nor can I guarantee my own security 100%. I might switch to an industry where you don't need to leverage trade secrets and proprietary code. It's hard/impossible to build any tech business while completely hacked. If I were a welder, for example, I could care less about surveillance/hacking. I've recently switched from web programming to more simple hardware-based development projects to keep my sanity going forward. And some of the gadgets are designed to address such security issues, like an open-source strongly encrypted keyboard with corresponding Linux driver. But I might just end up switching industries all together. People who fight the hacking too much, sometimes meet with untimely and unfortunate ends. :S A tradesman can't work and do his job well if someone has busted all his tools. And that's where we are/will-be with computers and networking/Internet today. /endrant > As far as I can tell, networking firmware in Linux is actually implemented > in Linux, and not installed on the actual device itself. I wouldn't say that's true. There's device drivers that live on Linux, and there's Firmware that lives on the card (and can be uploaded from Linux, with some cards). Even with a card that can receive firmware, what exactly is on the card receiving the firmware update? A CPU running some bootloader, potentially compromised by the NSA or orgcrime. So there's no guarantees there. And who's to say there isn't some secondary circuitry splitting off the signal and sending it to an attacker's server, outside the domain of the firmware. > Therefore, so long as the driver was open source, then surely it can be > audited for any DMA bugs. If the driver *and* firmware were open source, which is even more rare. And again, unless the firmware is flashed with a JTAG or some other direct-write method, there has to be some cpu+bootloader to receive the firmware from the Linux driver, which is free to muck with the firmware (or quietly ignore it) if the bootloader were compromised. The newer the hardware (esp. with U.S. based companies), the more likely I would say that state-sponsored compromise would be present. The oldest, dumbest cards might be the safest. But a more interesting point below: > Here is a comparison of open source wireless drivers > > https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers That's a great resource. The one thing that caught my eye were the devices with the [3] footnotes: "The card doesn't have a host CPU and so it doesn't require a firmware source" That's what I'm talkin' 'bout. :) To me, that seems like the most promising route. Not to say that such cards don't have *some* CPU or other backdoor. But it might be possible to verify if this is/isn't the case.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> If your Tor is running in another appVM, such as whonix-gw does, the worst > a sys-net compromise could do is redirect the *encrypted* Tor traffic from > whonix-gw, which isn't terribly useful for the attacker. Oh, I should mention, as you asked in your original question, that yes, a compromised sys-net could absolutely and trivially reveal your IP, regardless of whether Tor is running in sys-net or another AppVM. All the attacker has to do is fling a single packet to their server (bypassing Tor), and they have your address. "ping" would do the trick. But if Tor is in a separate AppVM, any data going into sys-net is triply-encrypted, and the content is safe from an attacker who has compromised sys-net. (If Tor is running in sys-net, the traffic coming in from the VM isn't Tor-encrypted, obviously, and far more visible, HTTPS notwithstanding.) 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/b4db5a08cca0cef35d47c814c9121326.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> OK, but I have already built the script. I have it running in Net VM. It > works. > > I am NOT asking you to make an alternative system. > > I am simply asking whether an attack on the WiFi/Ethernet in the Net VM > could also end up messing up my Tor script. > > Look at the question again: > > http://imgur.com/a/CTbLk As mentioned, if sys-net is compromised by a NIC attack, anything running in it is vulnerable, including the ability to modify/replace tor or tweak the iptables to redirect all traffic intended for tor, unencrypted (other than HTTPS encryption), to the attacker's server. It's MITM-vulnerable for non-HTTPS connections. And given that HTTPS isn't secure against state actors or anyone corrupt with CA abilities, losing the Tor layer, even with HTTPS, could be disastrous. Not great. If your Tor is running in another appVM, such as whonix-gw does, the worst a sys-net compromise could do is redirect the *encrypted* Tor traffic from whonix-gw, which isn't terribly useful for the attacker. Tor traffic is encrypted three layers deep (one might say, like an onion :) ), with three separate public keys, for three different Tor relays. Unless the attacker has the private keys for those three relays (which are randomly chosen by Tor in its vm), there's not a lot they can do with the traffic, other than be aware of it, block/DDOS it, or correlate traffic if they control enough entry/exit nodes. (Now, if the compromised sys-net can somehow otherwise breach other AppVM's or dom0, you're screwed. But that's a given anyway, and hopefully impossible after the latest patch against a recent and real such vulnerability :) And if it were possible, it would be a different attack vector all together, since sys-whonix [for example] has no PCI devices to be susceptible to a DMA attack.) This discussion brought to mind another potential attack vector, in the case of a compromised sys-net: If sys-net were compromised due to a NIC attack of some form, it could present any fraudulent windows it wants (e.g. password prompts) in dom0. So make sure your sys-net has a unique and noticeable color assigned to it, and pay heed to your window border colors. (I guess that's the main point of the window border coloring, is to clue in the user to attacks of this nature.) It could also replace/redirect the update server in sys-net, but package signing should catch and prevent harm from that. Digressing a bit, but related: if you ever see failed fetches during "apt-get update," especially for security package lists, I'd recommend you interrupt and run again. Apparently upstream blocking of security updates is one way attackers can leverage known vulnerabilities. (And the fact you're need to update a security package list is a huge "tell" that you suffer from that vulnerability.) More than once I've seen package lists update fine, but certain security package list updates fail. It could just be a transient error on the server, but given that it's a known attack vector, it can't help be cautious. I'd highly recommend using apt-transport-tor, which gets packages direct from debian, through an encrypted connection: https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/ 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/4f610b3190edc47beeb97e4a7664a132.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] I can't disable ipv6 on Debian Template
> nishiwak...@gmail.com: >> 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" Did you try this: https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux In /etc/sysconfig/network: NETWORKING_IPV6=no IPV6_AUTOCONF=no -- 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/409aa096350a6e082e11e79198ec.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> I'm pretty sure that can be done fairly simply, out-of-the-box via > NetworkManager, not requiring a script: Oh, and another good tip, is to make another NetworkManager show up in a secondary VM (other than just from sys-net), you can manually add "network-manager" (and check it) as a service in the Qubes VM Manager (under the services tab). That's how you get a VPN ProxyVM configured and running, for example: https://www.qubes-os.org/doc/vpn/ Works great! I was using OpenVPN from the command-line and with config files, until I realized NetworkManager would do it all for me in a more integrated fashion. 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/6f3796d4647939c594dfe348b1676721.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> In terms of "hotspot" terminology, what it does is, quote from author of > the script: > > "it bridges the two interfaces but uses NAT to achieve it" Ah, so it sets up some iptable nat rules (and maybe tweaks torrc to allow it to listen on a non-local interface; although iptables could do that redirection, too.) I'd generally call that "tethering" or "internet connection sharing." "HotSpot" implies public shared WiFi to me. I'm pretty sure that can be done fairly simply, out-of-the-box via NetworkManager, not requiring a script: https://wiki.archlinux.org/index.php/NetworkManager#Sharing_internet_connection_over_Ethernet Although if you're tunneling into another VM, it might not be that straight forward. Some good info and examples on such tunneling here: https://www.qubes-os.org/doc/qubes-firewall/ And redirecting into Tor might not be doable solely from the NetworkManager, not sure. Although if you install Qubes-whonix, whose gateway (sys-whonix) redirects *all* traffic over Tor, you could probably get everything running just with GUI configuration, no scripting required. (Less maintenance, more reliability.) https://www.whonix.org/wiki/Qubes 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/aa8cdd60b636376a3622e33a0db75ad8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> OK, it's the original poster here. > The consensus so far is that anything I run inside sys-net should be > vulnerable, and that it is advised not to run programs in sys-net. > > So, in this case, how am I supposed to run my Ethernet Tor hotspot..? I think you're going to have be more specific about what "ethernet tor hostpot" means. Hotspots are typically publicly accessible WiFi internet access points. ("Ethernet" to me implies wired, so hotspot makes a bit less sense.) > I had somebody write me a script that lets Qubes connect by WiFi to my > home router, and then serve out an Ethernet hotspot that runs everything > through Tor. > The program works fine, but yes, it does run within sys-net. "serve out an ethernet hotspot" and "runs everything through tor" are confusing phrases to me. Are you running a Tor Relay? Or a Wifi hotspot that sends things through Tor? Again, if you're more specific about what you're doing, you'll get better responses. If you are running a network-facing service, such as a WiFi hotspot or a gateway into your system for yourself, sys-net would indeed be a reasonable place locate such a service. At the very least, if you're handling incoming connections, you'll need some port forwarding in sys-net to another VM that provides the service. If you are running a WiFi hotspot that forwards things through the Tor network, I'd run tor in another VM and forward the requests from sys-net with iptables. Tor isn't exactly a monster, but it's certainly a hacking target for NSA and organized crooks, so I'd lean towards having it out of sys-net. Frankly, if you're just looking for a good personal VPN style thing, I'd take a closer look at that streisand link I posted earlier, and leave your personal home Qubes system out of it. $5/mo for a server to run streisand to eliminate incoming connections on your home system, is well worth it. Unless I completely misunderstand what you're trying to achieve, which is entirely possible. 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/1eeeb93551d30e346fd18edf451df272.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] I can't disable ipv6 on Debian Template
> 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. I agree that IPV6 shouldn't be used; IPV4 works, and is simpler, and thus potentially less vulnerable (less attack surface, yadda, yaada.) While IPV6 isn't necessarily new, it still seems a bit "mysterious" to me. It's certainly more complex, and complexity is no friend of security. Why not just disable IPV6 ("ignore") in the Network Manager (in sys-net, displayed on the taskbar in dom0, next to the Qubes Manager icon)? If sys-net/NetworkManager has ipv6 disabled, no VM is going to get any IPV6 packets through. > What is rpcbind, avahi-dae I also agree that avahi shouldn't be enabled. It is one of the first things I disable in Qubes. It's a zeroconf/Bounjour thing. Not needed, and more attack surface. rpcbind is a portmapper thing, useful for NFS, and I'm not sure what else, really. Another thing I also disable. (Probably like you, for security reasons, I don't like seeing anything listening when I do a netstat.) Also, this: http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/ I should note that due to a lot of hacking/harassment, I'm a bit more paranoid than your typical user. While it's probably innocent, seeing things like this enabled by default in a system always make me a bit less trusting of such a system; has an NSA-tampering feeling to it. :) (Similar to audio/pulseaudio enabled in sys-net/sys-firewall, the apparmor extra-profiles not being included in Tails for some bizarre reason, and the like.) exim4, I believe, was also enabled by default in fedora-23/debian-8, which makes little sense. If you want a mail server, set up a mail server, don't have them running in every VM by default. (As I mentioned in another post, I think there's an outstanding ticket to eliminate unnecessary systemctl services in the debian and fedora templates.) > and why you got this ipv6 bound to systemd on > PID 1 ? Looks suspicious, I thought Ipv6 was disabled by default on Qubes. I've seem people diss systemd as being unnecessary complex and obscure, and thus a bit of a risk for security. However, the dependency management it provides is very powerful imho, and well worth it. (I can't help but think the same startup dependency results couldn't have been achieved with the "make" utility. Probably not quite as elegantly, but without adding another new utility.) You say you see ipv6 bound to systemd? Is it listening on a specific port or anything? 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/dd0a71c1168b8a19068ad1fd4e942a44.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
Chris wrote: > 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. This is one of my favorite implicit features of Qubes: Setting up multiple layers of network protection is so much easier than on a non VM'd system. When I used to use Tails, I set things up to use VPN-over-Tor, so any dodgy Tor exit node only sees encrypted VPN traffic, and my nosy ISP doesn't know if I'm use a VPN, or which provider. I've also done Tor-Over-VPN, and VPN->Tor->VPN setups. :) It was a nightmare to set up. And that can lead to mistakes. On Qubes, it's a simple matter of layering another ProxyVM above sys-firewall. Add the NetworkManager service in the VM Manager settings, and you can configure OpenVPN, and you're good to go. Any additional layers are just as easy. (Qubes-whonix is a good example of such a configuration.) Memory can be a problem for limited systems (such as mine) and multiple ProxyVM layers, but (at a slightly greater risk of the effects of a compromise) could do your VPN configuration right in sys-firewall/sys-net if you wished, to avoid additional VM's. For example, with sys-net -> sys-firewall -> sys-whonix -> sys-vpn -> AppVM (and hey, throw a Tor Browser on top of that if you want to go nuts) any attacker has quite a few challenges ahead of them. :) I generally go with sys-net->sys-firewall->sys-vpn, and Torbrowser when I need to get to a .onion site. It's rewarding to fire up iptraf-ng in sys-net, and see nothing but encrypted packets to your VPN provider, while your AppVM's think they're just on the regular net. :) (Standard disclaimer, of course, that your VPN provider will see any unencrypted traffic you send through it. As Chris mentioned, https-anywhere can with that risk.) 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/57abd72601b36ae3f1206f134fa5b74c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
Chris wrote: > 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. I'm curious as to why you would say this. Any additional firewall between a Laptop and the network is a plus for security, and with Qubes isolating the NIC in a virtual machine, its safer from compromise than a typical firewall. Now, some firewalls, such as shorewall running on a Linux box, might have slicker and more advanced/flexible firewall configuration than Qubes, the network card isolation is a huge boost to security in my eyes. And there's nothing stopping you from running shorewall or another firewall in your sys-firewall, to get the combined benefits of both approaches. While I like the simplicity of Qubes' firewall config, I'd actually like to see more powerful firewall/iptables configuration, as well as having it locked down to a greater degree by default (such as with Tails' iptables configuration). Similarly, I'd like to see apparmor installed and configured tightly with Qubes by default. (Again, Tails is a good example of including apparmor support by default, although they inexplicably exclude the "extra" profiles, which include chromium and some other useful/critical profiles, IMO. Maybe its for performance reasons, but it still seems crazy [almost suspicious, lol] not to include them.) Qubes NIC isolation + iptables + apparmor can make a system incredibly secure against breaches. While Qubes' isn't designed as a firewall for other computers/devices, it strikes me as having the potential to be a safer firewall base than the alternatives. 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/598dca948a53984b3391d5b33cb580b8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why are Ethernet and WiFi in sys-net..?
> Simple question: Why are Ethernet and WiFi in sys-net..? > > Is it > > (A) Just for easy access to the same network for all App VMs..? > > (B) Because this is isolating Ethernet and WiFi from the rest of the > system, to stop DMA attacks..? Primarily (B). Any DMA attack or other network hardware compromise is confined to the net VM, and not your more critical work VM's (or dom0). > It's not clear to me whether the VT-D protection is occurring because you > are putting these devices in sys-net. > > Or whether the VT-D is implemented regardless of which VM the > Wifi/Ethernet are in. I'm not quite clear what you're getting at here. The network device(s) could live in any VM, and thus be isolated from the rest of the system. But by Qubes convention, the devices are put in sys-net, which is sys-firewall's NetVM, which in turn is typically the NetVM for other AppVM's. > I ask this because I want to run some programs in sys-net, and wonder > whether a DMA attack could screw up these programs. It absolutely could. I'd generally recommend against running anything in sys-net unless its very specifically needed, raw net-related, or low-risk. Things like wireshark, iptraf are useful to have in sys-net, for example. Any program running in sys-net doesn't benefit from the firewall rules protection at all, either. Just as with dom0, the fewer programs running (and thus the smaller attack surface) in sys-net (and sys-firewall), the better. Which is why I'd like to see unnecessary things like pulseaudio, exim, (and possibly even the X server) not included in sys-net by default. I think there's a Qubes ticket to that effect. Digressing a bit, but here's an interesting, leaner replacement for sys-firewall: http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ What's the nature of the program(s) you want to run in sys-net? Is there any reason they couldn't be run in another AppVM instead? 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/2b6bd00d61406084ca4dc4b21243f71d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
> 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.) That's also assuming the DMA attack isn't confined to a non-net/non-firewall/non-dom0 VM. A single compromised AppVM that isn't involved in the shared network connection shouldn't affect the laptop (but could scrape info and tamper with anything you do in that VM, which might have cascading effects with any credentials used elsewhere). But if dom0 or sys-net/sys-firewall (or whonix-gw or any other netvm/proxyvm) is affected by the DMA attack, the rest of what I said should apply. 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/6978265996a4e9a7ec09b8eac062a91a.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] InputAttach in dom0
(Apologies if this is a duplicate; I could have sworn I already submitted it, but I don't see any sign of it on the list or my outbox. Weird.) USB is generally considered evil/risky as compared to the simpler/safer PS/2 protocol; in that spirit, it might be handy to have "inputattach" in dom0, to allow connecting older/safer serial devices (mice) to Qubes. It's a fairly simple, useful, and mature utility, which shouldn't pose any risk to dom0. Thanks. 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/b1a12a43f0e7eaf293b766600fb19d77.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
> 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. 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. 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. 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 -- 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/bfbc4f1250a9ae5f80d3cc221b6d6ba8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] New version of Qubes Screenshot Tool (0.5 beta)
> Hello, > > New version of Qubes Screenshot tool available. > > https://github.com/evadogstar/qvm-screenshot-tool > > > If you do not know what is it: a tool to easy make screenshots and > upload them to the AppVM and to the web ( imgurl service ). > > Changelog: > - Now, it's possible to re-open imgurl uploaded dialog again, if it was > closed. I found that it's very useful at the daily use to get uploaded > url again. > - "Ksnapshot" removed from the menu if it's not available at the system > (because of Qubes XFCE migration and KDE not available now by default) Hey, I just noticed that the screenshot utility supposedly supports imgur. How does it do that from dom0? Similar to qubes-dom0-update, and use the firewall or other VM to do the networking? When I tried it, I just got an error that it couldn't transfer to imgur. Is this not supported in dom0, or is there something misconfigured at my end? (I don't have dispvm's enabled, for memory conservation reasons; would that be relevant?) 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/61b10ca2233832607b73eb993e3f5f2a.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Dear qubes-users
> Mr. Harrison: >> Dear qubes-users, >> >> I am long time qubes follower and user. I apologize in advance if anyone >> feels this request is spam. >> >> I am looking for two invite codes needed to sign up to anonymous >> riseup.net email service. I agree that asking random strangers for Riseup invites is inappropriate, especially on a mailing list. But just FYI, I received my riseup account by mailing the administrators, explaining the ongoing harassment/hacking/spying situation that necessitated better email security, and they gave me an account without referrals. sigaint is another option that doesn't require referrals, but does require Tor to access as it's only available as hidden service (a good thing, probably): http://sigaintevyh2rzvw.onion (Sigaint was asking for donations recently, saying they only had a month or so of operating funds left; so there's a chance they could suddenly disappear, but for now, it's not a bad option.) 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/c8a80ea67d6ce794f734603c90432606.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] BTRFS?
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Thu, Sep 22, 2016 at 03:56:57PM -0700, Connor Page wrote: >> In fact, I think the right question is "Will Qubes 4 be compatible with >> btrfs root if vm storage is expected to reside on a LVM thin pool?" > > This is a good question. The new storage handling is flexible enough to > allow writing a module to handle btrfs even better than in Qubes 3.x. > But it is unlikely that we'll manage to write such module for 4.0. If > someone would contribute such module, then yes - it will be supported. > Otherwise, probably somehow around 4.1 or later. 4.0 will be less flexible in this respect? LVM thin volumes sound interesting (just read up on them today) and handy for allocation, but they'll be mandatory for VM storage?? (Again, as mentioned in my earlier post, btrfs seems like it would meet the same needs and then some.) Why is it that so many things I hear about 4.0 are concerning to me? I realize one must make sacrifices and architectural choices in the name of progress. But so far what I know of 4.0 is that it won't run on any of my PCs, it won't (initially at least) support btrfs root, and the "decomposition" sounds like it's going to spread configuration stuff in various places rather than in one spot, the Qubes Manager (well, and the menu), where they're generally very easy to find. (There was something else that didn't sit well with me, but it escapes my feeble mind at the moment. Might have been something to do with hardware or processor requirements.) I know there are some incredibly talented people working on Qubes, and a great community surrounding it, so my fears are probably largely unfounded; but I'm a bit afraid to invest in fully settling into and committing to a system (which has been great so far), if the next major release won't work for me. Once 4.0 comes out, what happens to 3.2? Will it be supported for awhile, moved forward at all, or just marked as deprecated/EOL'd and more or less abandoned? 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/429588c1db7fa0d2df95a73160c305e5.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: BTRFS?
> Has the Qubes team ever considered the use of btrfs? I do see Qubes does indeed support btrfs as a root fs during install. Cool. 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/76638b8a5a6b3d4643e2480bc0b76fcb.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] BTRFS?
Has the Qubes team ever considered the use of btrfs? https://en.wikipedia.org/wiki/Btrfs It's been the default root FS for Suse since 2012: https://www.linux.com/news/suse-linux-says-btrfs-ready-rock While reading about its features (and using it) it seems like it would be especially well-suited as a base for Qubes, giving unlimited snapshots, nested overlays/unions (seeds), rollbacks, subvolumes, sparse files, plus easy adding/removing of disks, raid, space balancing, and greater reliability (with the raid and checksum of metadata/data). A win/win situation. It would make the template implementation a lot simpler, faster, and more flexible. Instead of .img files, you'd just have subvolumes (and use of seeds/unions). It seems like a more elegant, flexible, and extensible solution. Even doing things like multi-level templates would be possible (although for root, I think package management would be problematic with more than one level). Cloning a given template or an appvm would be instant and require zero disk space (due to the innate copy-on-write nature of btrfs) rather than taking many minutes and doubling the disk usage. The only space used by a cloned template/vm would be what was eventually modified. Booyeah. If used as a rootfs, even without any further template integration, the deduplication feature should automatically bring the same disk savings. It also offers self-healing, online checking/shrinking/growth, "deduplication" of blocks with the same content, ..., the list goes on. The related btrfs support utility "Snapper" also seems like it would fit in very nicely with Qubes: https://wiki.archlinux.org/index.php/Snapper Suse automatically creates a snapshot whenever packages are installed, so it's easy to rollback any undesired changes. Again, that would be a great feature for templates. You can even convert an ext4 system to btrfs, and keep both available, since btrfs keeps the data blocks in a compatible way and puts it metadata in other unused space. It makes the existing ext4 metadata a separate btrfs subvolume, you can later delete if you choose--very slick. (Or similarly, you can revert to ext4-only as easily.) I'm starting to use BTRFS for all my non-root/non-user devices, and I'm loving it. The private.img/volatile.img structure seems primitive by comparison. :) I realize the ext* code is probably considered more mature, stable, and safe for dom0, but btrfs seems to have been put through its paces quite well over the years (and I'm sure ext4 itself has been having a lot of code changes over the years, possibly making it no more secure than btrfs?) (I haven't checked if the Qubes install allows it as an option for root. Even if it does allow its basic use, going further and leveraging the seed/subvolume/snapshot for templates/appvms is the more exciting part to me.) I realize such a change would be non-trivial, but it does seem like a natural way for Qubes to evolve. Thoughts? 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/a7878e26a6480acbc6add8e18a73c303.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: NVIDIA GeForce
> On Wednesday, 21 September 2016 02:25:15 UTC+10, johny...@sigaint.org > wrote: >> > On Sunday, September 11, 2016 at 11:11:28 PM UTC-4, Drew White wrote: >> >> On Friday, 9 September 2016 18:58:51 UTC+10, Thomas Ernst wrote: >> >> > Hi all, >> >> > >> >> > Does Qubes support NVIDIA GeForce graphics cards? The reason for >> >> asking is that I am planing to buy a Lenovo ThinkPad T460p Laptop, >> >> which has a NVIDIA GeForce 940MX 2 GB graphics card. >> >> > >> >> > Best, >> >> > >> >> > Thomas >> >> >> >> I have a GeForce GTX630 and a Quadro 600 in my machine, and both work >> >> well with no issues. >> >> >> >> The Thinkpads work well with Qubes. >> >> the T530 is very nice and works well. >> >> So the Pro T460 should also be quite acceptable. >> >> >> >> As long as you have 4 or more threads, you can use qubes easily. >> > >> > I have gtx 650 ti. works great. I would research how the card >> perform >> > with open source linux drivers in general before buying. >> >> I have a GeForce6100SM-M2. It's on-board nVidia card crashes (diagonal >> stripes) after a bit of usage (almost seems to happen when memory gets >> low). >> >> I've tried all the BIOS settings, etc., with no luck. (The same thing >> occurs under Tails, FYI.) >> >> With a PCI GeForce7300 GT inserted (and the on-board video disabled), >> things work just fine. >> >> (Note that in 3.1, and 3.2 up until rc2? I think, there was a bug where >> the VM's would get screen corruption. rc2 and beyond have fixed this >> problem.) >> >> Cheers. >> >> JJ > > I only got screen corruption AFTER upgrading to 3.2, then I did a full > update of Dom0 to get rid of that because there was a fix that came out > for it. > However it didn't happen often. I never found out the reason why it > happened, because I saw there was a fix for it. > 3.1 didn't EVER have the screen corruption for me. > And I was using Dual Monitors and dual Quadro600's The screen corruption problem I was seeing was in 3.2 (rc1 I think), and the fix was in the VM's (Debian-8/Redhat-23) not dom0. (It was something to do with accessing freed/reallocated memory once swapping started, if I remember correctly.) 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/9a30f6877dcb0bd489005ee6bdd19a8d.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Failed device allocation
> Quite frequently, under Debian-8, when I go to assign a device, it quietly > appears to work (Qubes Manager shows it assigned), but the device never > shows up, and the VM's dmesg shows things like this: A bit more info: I repeatedly failed to add a device to one VM. I close another VM, freeing up some memory. Then adding the device to the first VM works fine. So it does appear to be a memory allocation problem (as the stack traces indicate). I can start new programs, and do other things in that same VM that increase its memory usage, so it's not starved (some VM swap is in use). However, in lower memory conditions, devices won't assign. 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/aa85e9c770f36a6c1418d9aae8b713ce.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Failed device allocation
Quite frequently, under Debian-8, when I go to assign a device, it quietly appears to work (Qubes Manager shows it assigned), but the device never shows up, and the VM's dmesg shows things like this: [Tue Sep 20 13:17:09 2016] xenwatch: page allocation failure: order:5, mode:0x240c0c0 [Tue Sep 20 13:17:09 2016] CPU: 0 PID: 16 Comm: xenwatch Tainted: G O4.4.14-11.pvops.qubes.x86_64 #1 [Tue Sep 20 13:17:09 2016] 023a 37654cb4 880004b6b928 813b06f3 [Tue Sep 20 13:17:09 2016] 0240c0c0 880004b6b9b8 811a58fa [Tue Sep 20 13:17:09 2016] 00010040 04b6b950 37654cb4 0005 [Tue Sep 20 13:17:09 2016] Call Trace: [Tue Sep 20 13:17:09 2016] [] dump_stack+0x63/0x90 [Tue Sep 20 13:17:09 2016] [] warn_alloc_failed+0xfa/0x160 [Tue Sep 20 13:17:09 2016] [] __alloc_pages_nodemask+0x349/0xb40 [Tue Sep 20 13:17:09 2016] [] alloc_pages_current+0x8c/0x110 [Tue Sep 20 13:17:09 2016] [] alloc_kmem_pages+0x19/0x90 [Tue Sep 20 13:17:09 2016] [] kmalloc_order_trace+0x2e/0xe0 [Tue Sep 20 13:17:09 2016] [] ? xenbus_read_otherend_details+0x62/0xd0 [Tue Sep 20 13:17:09 2016] [] blkfront_probe+0x8e/0x236 [xen_blkfront] [Tue Sep 20 13:17:09 2016] [] xenbus_dev_probe+0x89/0x160 [Tue Sep 20 13:17:09 2016] [] xenbus_frontend_dev_probe+0x48/0x50 [Tue Sep 20 13:17:09 2016] [] driver_probe_device+0x222/0x490 [Tue Sep 20 13:17:09 2016] [] __device_attach_driver+0x71/0xa0 [Tue Sep 20 13:17:09 2016] [] ? __driver_attach+0x90/0x90 [Tue Sep 20 13:17:09 2016] [] bus_for_each_drv+0x67/0xb0 [Tue Sep 20 13:17:09 2016] [] __device_attach+0xdc/0x170 [Tue Sep 20 13:17:09 2016] [] device_initial_probe+0x13/0x20 [Tue Sep 20 13:17:09 2016] [] bus_probe_device+0x92/0xa0 [Tue Sep 20 13:17:09 2016] [] device_add+0x40b/0x680 [Tue Sep 20 13:17:09 2016] [] device_register+0x1a/0x20 [Tue Sep 20 13:17:09 2016] [] xenbus_probe_node+0x172/0x190 [Tue Sep 20 13:17:09 2016] [] xenbus_dev_changed+0x1c9/0x1d0 [Tue Sep 20 13:17:09 2016] [] ? register_xenbus_watch+0xf0/0xf0 [Tue Sep 20 13:17:09 2016] [] frontend_changed+0x25/0x50 [Tue Sep 20 13:17:09 2016] [] xenwatch_thread+0x91/0x140 [Tue Sep 20 13:17:09 2016] [] ? wake_atomic_t_function+0x70/0x70 [Tue Sep 20 13:17:09 2016] [] kthread+0xd8/0xf0 [Tue Sep 20 13:17:09 2016] [] ? kthread_create_on_node+0x190/0x190 [Tue Sep 20 13:17:09 2016] [] ret_from_fork+0x3f/0x70 [Tue Sep 20 13:17:09 2016] [] ? kthread_create_on_node+0x190/0x190 [Tue Sep 20 13:17:09 2016] Mem-Info: [Tue Sep 20 13:17:09 2016] active_anon:7391 inactive_anon:8741 isolated_anon:0 active_file:11006 inactive_file:10713 isolated_file:0 unevictable:2407 dirty:0 writeback:0 unstable:0 slab_reclaimable:4436 slab_unreclaimable:2617 mapped:4353 shmem:444 pagetables:1547 bounce:0 free:504 free_pcp:0 free_cma:0 [Tue Sep 20 13:17:09 2016] Node 0 DMA free:480kB min:268kB low:332kB high:400kB active_anon:736kB inactive_anon:824kB active_file:1312kB inactive_file:1116kB unevictable:16kB isolated(anon):0kB isolated(file):0kB present:15996kB managed:15912kB mlocked:16kB dirty:0kB writeback:0kB mapped:988kB shmem:20kB slab_reclaimable:2700kB slab_unreclaimable:1632kB kernel_stack:224kB pagetables:304kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [Tue Sep 20 13:17:09 2016] lowmem_reserve[]: 0 38 38 38 [Tue Sep 20 13:17:09 2016] Node 0 DMA32 free:1536kB min:668kB low:832kB high:1000kB active_anon:28828kB inactive_anon:34140kB active_file:42712kB inactive_file:41736kB unevictable:9612kB isolated(anon):0kB isolated(file):0kB present:1028096kB managed:216048kB mlocked:9612kB dirty:0kB writeback:0kB mapped:16424kB shmem:1756kB slab_reclaimable:15044kB slab_unreclaimable:8836kB kernel_stack:2032kB pagetables:5884kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no [Tue Sep 20 13:17:09 2016] lowmem_reserve[]: 0 0 0 0 [Tue Sep 20 13:17:09 2016] Node 0 DMA: 68*4kB (UE) 18*8kB (UME) 4*16kB (UM) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 480kB [Tue Sep 20 13:17:09 2016] Node 0 DMA32: 67*4kB (ME) 33*8kB (ME) 17*16kB (ME) 17*32kB (UME) 3*64kB (UE) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1540kB [Tue Sep 20 13:17:09 2016] 23086 total pagecache pages [Tue Sep 20 13:17:09 2016] 924 pages in swap cache [Tue Sep 20 13:17:09 2016] Swap cache stats: add 9783, delete 8859, find 3262/4914 [Tue Sep 20 13:17:09 2016] Free swap = 1024996kB [Tue Sep 20 13:17:09 2016] Total swap = 1048572kB [Tue Sep 20 13:17:09 2016] 261023 pages RAM [Tue Sep 20 13:17:09 2016] 0 pages HighMem/MovableOnly [Tue Sep 20 13:17:09 2016] 203033 pages reserved [Tue Sep 20 13:17:09 2016] 0 pages hwpoisoned [Tue Sep 20 13:17:09 2016] vbd vbd-51856: 12 allocating info structure [Tue Sep 20 13:17:09 2016] vbd vbd-51856: 12 xenbus_dev_probe on device/vbd/51856 [Tue Sep 20 13:17:09 2016] vbd: probe of vbd-
Re: [qubes-users] Re: Booting Cubes, Migration
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2016-09-19 13:36, johnyju...@sigaint.org wrote: >>> I've finally got Qubes set up in a way I'm comfortable working every >>> day. >>> >>> Now I wanted to move that same installation to another drive for its >>> permanent home. >> >> Oh, I also meant to ask this: >> >> Does all of the Template/VM state live in /var/lib/qubes? Obviously the >> machines' disks do, and it appears that the metadata associated with >> them >> lives in /var/lib/qubes/qubes.xml (not human readable, tho'). >> >> Is this correct? If I do a fresh install of Qubes, and (with no VM's >> running) bring over my whole /var/lib/qubes directory from another >> installation, reboot, would I be good to go? Or are there other subtle >> things in dom0's root drive that would be out of kilter? >> > > I'm not sure whether this would work (never tried it). If possible, I'd > recommend using the built-in backup/restore system instead. This is the > recommended way to migrate to a fresh installation. > > https://www.qubes-os.org/doc/backup-restore/ Understood. I just find the backup/restore painfully slow as compared to a quick (and incremental, as I work) rsync. And I did try to do the backup/restore thing, but my destination drive had some partitions on it I wanted to preserve (as mentioned), and I just couldn't get the layout I wanted (partition->luks->lvm->swap/root, plus a sda1 bios boot). I guess I'll move those three existing encrypted partitions (1.5T, ugh) to another drive (external USB, blah), do a fresh stock install of Qubes, then copy those partitions back. See ya in a week or two. :P I'll probably toy around with (and study up on) grub/dracut/luks/crypttab/initrd a bit more first, though, since I'm so close. A little more debugging might do the trick. I have a perfect image of the old encrypted swap/root and bios boot partitions on the new drive. So it's just a matter of the right grub/dracut magic. So close, to avoid a couple of days of copying. If I do find the magic tweak to make systemd roll along further, I will follow up here. 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/8380b617dfdff766d79a0ba3cc25488b.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: NVIDIA GeForce
> On Sunday, September 11, 2016 at 11:11:28 PM UTC-4, Drew White wrote: >> On Friday, 9 September 2016 18:58:51 UTC+10, Thomas Ernst wrote: >> > Hi all, >> > >> > Does Qubes support NVIDIA GeForce graphics cards? The reason for >> asking is that I am planing to buy a Lenovo ThinkPad T460p Laptop, >> which has a NVIDIA GeForce 940MX 2 GB graphics card. >> > >> > Best, >> > >> > Thomas >> >> I have a GeForce GTX630 and a Quadro 600 in my machine, and both work >> well with no issues. >> >> The Thinkpads work well with Qubes. >> the T530 is very nice and works well. >> So the Pro T460 should also be quite acceptable. >> >> As long as you have 4 or more threads, you can use qubes easily. > > I have gtx 650 ti. works great. I would research how the card perform > with open source linux drivers in general before buying. I have a GeForce6100SM-M2. It's on-board nVidia card crashes (diagonal stripes) after a bit of usage (almost seems to happen when memory gets low). I've tried all the BIOS settings, etc., with no luck. (The same thing occurs under Tails, FYI.) With a PCI GeForce7300 GT inserted (and the on-board video disabled), things work just fine. (Note that in 3.1, and 3.2 up until rc2? I think, there was a bug where the VM's would get screen corruption. rc2 and beyond have fixed this problem.) 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/0a18031fd71f38c8919da886087ef75a.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Booting Cubes, Migration
> Anaconda is notorious for messing up specific requests for volume > layout. You would stand a much better chance of getting help in a fedora > or redhat forum... they have many more people experienced with this. Cool, thanks. I guess it is a more general grub/luks/lvm issue, and not necessarily Qubes-specific. > As for copying all of /var/lib/qubes, I'm not sure its a 100% clean way > to do it transferring old qubes.xml directly would be a concern (but > I may be wrong). Qubes does make it possible to copy a vm's folder into > /vm-templates or /appvms, then run qvm-add-template or qvm-add-appvm to > add vms one-by-one into the current system. Interesting. In the past, I have had success in moving a single VM by creating a new VM with the same settings as the old one, then replacing the files in the vm's directory. (Sort of the reverse order of what you mentioned.) Now, if I can only get the booting working . . . :) 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/6b7c4e837761ed4ab91e0070d33f8c07.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] USB hotplug messing up other USB devices?
Qubes 3.2rc3-testing (and earlier), AMD Athlon X2, GeForce motherboard, NVidia MCP61 USB controller: I'm currently running Qubes from an external USB drive. (Moving to internal drive as soon as I figure out how to smoothly migrate it.) For now, it works great in general. In the meantime, I've noticed the odd corruption where the root drive flips into R/O mode (and the system obviously becomes useless). A reboot, fsck, reboot gets me back on track, usually with just a journal recovery, sometimes with the odd recovered inode/count of some recently created files. (No major file corruption yet, thankfully.) I believe one thing that seems to kick in this problem, is plugging/unplugging *other* USB devices (on same USB bus). It seems to sometime upset existing USB drives. Has anyone else experienced this? The next time it happens, I'll post some logs. I think it's fairly reproducable. I'm scanning through some old USB drives tomorrow, so I'm sure it will re-occur, and I'll post some more details. Thanks. 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/709e74ac4195b0c9a175d71b17c4dce4.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Booting Cubes, Migration
> I've finally got Qubes set up in a way I'm comfortable working every day. > > Now I wanted to move that same installation to another drive for its > permanent home. Oh, I also meant to ask this: Does all of the Template/VM state live in /var/lib/qubes? Obviously the machines' disks do, and it appears that the metadata associated with them lives in /var/lib/qubes/qubes.xml (not human readable, tho'). Is this correct? If I do a fresh install of Qubes, and (with no VM's running) bring over my whole /var/lib/qubes directory from another installation, reboot, would I be good to go? Or are there other subtle things in dom0's root drive that would be out of kilter? (It'd be nice to see the VM's and their state not being tied to anything beyond /var/lib/qubes. Seems a lot cleaner that way.) Thanks. 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/8eab0f3d61be02c5d52b065607832d5b.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Booting Cubes, Migration
I've finally got Qubes set up in a way I'm comfortable working every day. Now I wanted to move that same installation to another drive for its permanent home. The current drive has a standard bios /boot partition (sda1), and an encrypted extended partition (#5) containing lvm with swap and /. The destination drive has a few existing partitions on it, #2 - Extended partition containing #5/#6/#7 which are a few encrypted partitions containing some data I'd like to keep. The destination drive has a 500M empty space at the start ready for partition #1 (/boot) and 550G at the end, ready for partition #8, a future encrypted partition, which will contain a physical volume/volume group containing the logical volumes for swap and /. 1) First attempt to migrate, I created the new /boot partition by hand, rsync'd from the old. Similarly, I created the new encrypted partition, added the pv,vg,lvm's for swap/root, and rsync'd all the data from the old root to the new root. I tweaked up the UUID's in /boot/grub2/grub.cfg, /etc/crypttab, /etc/fstab, and (I think) in the initrd. However, that failed to boot. It got as far as dropping into the dracut shell, and when I manually set up the qubes_dom0/root to be /dev/root and exited, systemd went a little ways, but then went into some loop where it kept saying target paths were ready, but did nothing further. Argh. 2) Second attempt was a raw DD of both /boot and the whole encrypted lvm partition. (The destination partitions, luckily, were bigger.) I then unplugged the original drive (since there'd be conflicting UUID's now), rebooted, and same deal... The boot wouldn't mount the crypted drive, and went into some loop. Third attempt, I figured I'd do it the more official way, and do a fresh install of Qubes, and then restore a backup from my old setup. But with 3.2rc3, I couldn't get the installer to do what I wanted. Occasionally I'd get a weird pop-up error about "e not being defined yet" or something like that. :S I tried and tried to coax it into creating a biosboot partition in /dev/sda1, and making a /dev/sda8 as an encrypted, lvm-containing partition, to no avail. The closest I came, when it described the steps it was about to take (nice feature!), it said it was going to create a partition in /dev/sda8, put an LVM in that, and then create two Luks partitions, one for swap and one for root. That's not what I had before, and not what I wanted. I wanted the encryption outside the LVM, which I thought was the standard way of doing things. If I choose "automatically partition the drive", will it preserve my existing #5/#6/#7 extended partitions and just add new partitions as needed? I don't want to nuke everything by mistake. Any suggestions? Also, on my first attempt to set it up, for the heck of it, I made the /boot partition encrypted. http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ That part seemed to work fine; asked for passphrase right away, decrypted /boot, loaded xen/vmlinux/initrd and started things rolling. But the same systemd failure happened as described above. So I went back to non-encrypted /boot. I do think encrypted /boot might be a good default or optional feature for Qubes. Why leave more attack surface than necessary, and the /boot partition is a pretty big glaring one. (Why would an attacker care if root is encrypted, or bother with it, if they have free reign to tamper with an un-encrypted /boot with all it's kernel-ey and initrd goodness. It's like locking your front door, but leaving your basement door wide open.) Thanks. 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/4a13a2407f863a5b6a6a6f0ee6d225e4.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Can DMA attacks work against Ethernet... or just WiFi/wireless...?
> Am Montag, 12. September 2016 01:29:14 UTC+2 schrieb neilh...@gmail.com: >> Qubes uses VT-D to protect against DMA attacks on things such as WiFi >> chip. >> >> But are there any proven DMA attacks against wired networking, i.e. >> Ethernet..? >> >> Hackers can exploit a buffer overflow on the network card's firmware, >> and use that to take control of the network card, and issue a DMA attack >> to take control of the entire host computer. I've often wondered this. I figured that most modern operating systems didn't use any device BIOS, but used their own (e.g. Linux) drivers instead. But if any internal firmware of a network card, say, is compromised through some buffer overflow or whatever, it can just go ahead and initiate DMA operations at will? In my (ancient) experience with DMA, a driver would typically set things up to be transferred via DMA when the data is available, or whatever, indicating where the transfer should occur, and so forth. (I guess that memory address is likely given to the device to use when the time comes, and not necessarily needed by the OS for the transfer?) But if you're not running any (potentially compromised) BIOS ROM or compromised driver, is it possible for a rogue Net card to just start writing to memory at will without any OS support/setup? (I guess a rogue netcard firmware is free to modify any network payload, which is powerful as well; but short of that, can it actually compromise a system or a VM?) 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/aba0eb068d23a08756ce30c7070aea16.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 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?
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?
> 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.
Re: [qubes-users] Qubes 3.2 rc3 has been released!
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Details here: > https://www.qubes-os.org/news/2016/08/31/qubes-OS-3-2-rc3-has-been-released/ > > As usual, you can download new image from: > https://www.qubes-os.org/downloads/ > > Users of R3.2 rc1 or rc2 can just install updates, no need for full > reinstall. > For older releases check above page for upgrade instructions. Congrats on another milestone. For those of us tracking testing, we're automatically swept along with our updates (just as users of rc1/rc2), correct? Sorry if that's a stupid question. JJ > > - -- > 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 > > iQEcBAEBCAAGBQJXxzpPAAoJENuP0xzK19cszD4H/j4jPpG9aEaa6xx+FoDN+7cI > 4P3PU3GtvDO+k97O9at/4Gsq5ziUgyFcJxD+3KId7gTsDML5w7ge93Zyvc5lRms/ > cu+skFnrLpeOKSv+aeRTzeeZQ6EbEePLqXLpgMcLIN93hKiPqN6UPPUJ0ya5Ijhg > qol6fbEwLYdyazq378QcEmgqAE9C3iEmVpthLl3qw+vITJHIutHtxJgzV7kYR6q+ > euF0dVjijY/qeu0R/Jds6WYlB9WCdzuDRfRGO5BYEc3PtjvrCLW0g02SGyplQwDk > nFqnrB69czNPMgs6Gsb5arIKco4tm6a9VOUyT+XCgPX5Vbw+4FSH7pw7EsRK4bk= > =Uo8f > -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/20160831201304.GH9166%40mail-itl. > For more options, visit https://groups.google.com/d/optout. > -- 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/b13db8d9e8da36a50ab07b75782f0184.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Adding individual partitions from Manager
While qvm-block is a wonderfully handy tool for adding individual partitions to a VM, the Qubes VM Manager can only add entire devices from its GUI. I think that it's a pretty strong argument Qubes' spirit of "protecting the user from him/herself" to make sure this feature (maybe in a nested menu or something) is added at some point. Keeping a VM from pooching a partition table and a whole drive, and at the very worst messing with a single partition, is a pretty significant protection of the user from himself, as well as prevention of escalation of any VM compromise. If a compromised VM can tamper with the partition table (to hide away its payload, trash partitions), or worse, modify the boot sector of a drive, it's a *way* worse end result that's possible that messing with an individual partition. (Although they have boot sectors of their own.) e.g. on a typical Linux drive, mounting /dev/sdx5 with the data to play around with, while preventing /dev/sdx1 (the /boot partition) or /dev/sdx (the boot sector/paritition) from being corrupted is a major win for security (and stupidity) in my books. I know 4.0 is going to rework (deconstruct?) this stuff a lot, but it'd be nice to make sure some equivalent feature is in 4.0, in not sooner. Also, is there a limit to the # of devices you can add to a VM? I seemed to hit the wall at /dev/xvdl, which the Qubes VM Manager and qvm-block seemed to think had been assigned to my VM, but the VM never saw it, and there was some strange error in dmesg. (I neglected to save it, sorry.) Granted, I was doing way more in that one VM that I should have been (things just got out of hand, lol) and I restarted things and split up the tasks, and all is well. Just curious if there is a hard limit. 3 is a fairly low limit for devices (xvdi/xvdj/xvdk), although there were a lot of partitions about (one had 7 partitions, another had 5). Thanks. 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/d0c8e8cd831a1dc106bc771febeea5a5.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-run only available from dom0?
> On 2016-08-30 01:16, johnyju...@sigaint.org wrote: >> Say someone compromises the dom0 encrypted drive password, and >> then goes shuffling through the private.img file of the AppVM's to >> get at Firefox's passwords...? The VM itself wouldn't have to be >> running corrupt code for that, and keeping the passwords out of >> Firefox prevents that attack. >> >> (Firefox's master password could also help prevent such attack, I >> guess. Is strong crypto used for that? It's still a single point >> of failure, but so is the keepass master password. At least with >> keyfiles and physically taking the device with me, that keepass >> single point of failure is mitigated.) >> > > Qubes is designed with the assumption that if dom0 is compromised, the > whole system is compromised. So, from a "standard" Qubes perspective, > it doesn't really make sense to talk about protecting Firefox > passwords when dom0 is assumed to be compromised. If your threat model > differs significantly from this assumption, then you may need to > specify it in more detail. Understood. I think most of my security violations in the past were done remotely, and with dom0 having no networking, that risk is quite low. There have been occasions where I suspected physical access and a keylogger/camera, however. Notwithstanding "dom0 is compromised and you're screwed," there is one threat model where Firefox passwords are less safe, possibly: With a hardware keylogger or an over-the-shoulder-camera, one can glom the root disk password (and any Firefox master password). Then when you're out (or via a network card management mode, BIOS trojan, whatever) get into the system, go through the .img files to find the Firefox passwords. All of your online passwords are revealed at that point. If the passwords only existed in keepass on a removable USB drive, then they're safely with you. Even if that keylogger grabbed your keepass password, it's no good to any attacker. And the passwords have never been typed, so any keylogger/camera doesn't have them. Yes, an attacker who gets into the system could at that point plant trojans, but if you have in place other intrusion detection mechanisms (not necessarily just on the computer) you can be aware of that fact, and redo the system from a backup. Your computer may be toast, but your email and online world is still safe. I guess if you never typed your Firefox master password, but used keepass for it, too, and assuming Firefox's password storage is strongly encrypted, then your passwords are still pretty safe in case of a dom0 violation. Whenever you start stacking "if's" like that, though, I start feeling less secure. :) I do know the passwords can't be stolen if they're not on the system and have never been typed, short of the system already having been compromised. I don't know enough about Firefox's master password encryption to trust it 100%. Faulty assumptions have cost me dearly in the past, so I try to make as few as possible these days. > P.S. - Please keep the list CCed (unless there's a special need for > privacy, in which case, use PGP). I definitely will share the results with the group. There's won't be anything in the setup whose revelation would reduce my own security. :) But I appreciate the sensitivity. > I've noticed that you keep CCing > "qubes-users@goog" instead of "qubes-users@googlegroups.com". Apologies. I'll be more careful cleaning up the To/Cc on mailing list replies in the future. sigaint was truncating the field, and I neglected to notice (until the bounce). Hey, at least I'm not still top posting. :) 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/31e6bb44f35bf1ca07a10ddc3c8bb34f.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HVM, USB Drives, .img files, VM recovery
Is there any way to boot an HVM from an external USB drive? I would have thought that simply setting the "additional drive" on a new HVM to a USB device in another HVM (or dom0) would have allowed it to boot from that drive. I have a USB drive that contains a Linux system (partition table, /boot, /) that I wouldn't mind booting under Qubes on occasion. I tried creating an HVM and setting the additional drive to be that whole drive, but upon startup it just complains that there is no bootable drive. Hitting F12 for the boot menu doesn't let you be more specific than CDROM/Hard disk, so you can't specifically choose which hard disk. (Also, hitting F12 for the boot menu on time takes Ninja-like skills; is there any way to make that easier?) I can't see the utility of "additional drive" as an "hd" if you can't boot from it. I feel like I'm missing something obvious. I also tried removing the existing references to the root/volatile/private .img files via qvm-prefs (hoping to encourage booting from the "additional drive") but it wouldn't let me. (I was going to make a suggestion that qemu-img be available in dom0 for some unsupported recovery-style operations, but I see it is there under /usr/lib/xen/bin. Good to know, for emergencies/recovery, and it does make sense not to have it on the path or in an obvious spot, to avoid encouraging unsupported and potentially dangerous actions. Good enough.) Also, just FYI, I was able to recover some template/app VM's from /lost+found in a toasted Qubes installation (due to that root USB issue I was having) by simply creating similar VMs in a new Qubes installation, and copying the .img files to the appropriate /var/lib/qubes/ directory. I'm doing backups now to avoid such needs in the future. :) Thanks. 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/f614bbbee1007c13fbbd1f131d1a132c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: OSX
> Hey, does anyone have any luck with getting any form of OSX to fire up > under Qubes? > > After several other failures, I was able to get some iPC ISO build to get > to a certain point in an HVM, but the mouse didn't work, so I couldn't do > much, and I couldn't figure out how to get it to any kind of command line > (single user or otherwise). > > Not looking for the full OSX experience, just want to fsck_hfs some legacy > drives that are too cranky for Linux. Get a successful fsck done, and > turn off Journaling so Linux is a bit friendlier with them, until I can > copy/retire them. > > Anyone? I was able to get what I needed done with a single-user boot of an osx86 build. I might make it a bit of a fun side-project to play with osx86 under Qubes, though, and will obviously report back here any results. 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/736822dbddcf9d60992435684c1dd153.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Manager Suggestions
> But I'll Joanna's page a more detailed read when I'm a bit more refreshed. Sorry, not just "Joanna's" page; on a quick scan, I see you contributed to it significantly as well. I very much look forward to giving it a proper read and review tomorrow. Cheers, and thanks, Andrew. :) 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/ff7eefd239a9541aaed1d8a4be7b927e.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Manager Suggestions
> Thanks for the suggestions. Our goal for Qubes 4.0 is to "decmopose" > the current Qubes Manager by integrating its functions more seamlessly > into the desktop environment: > > https://github.com/QubesOS/qubes-issues/issues/2132 > > We hope that this approach will take care of the kinds of issues that > you and others have pointed out regarding the current Qubes Manager. Hm. That's interesting. I'm not 100% sure I comprehend what "decomposition" means here. I'm not sure splitting stuff out into different parts of the window manager makes things less confusing, or more confusing. And potentially harder to maintain. I hate trying to hunt around and find things when they could all be in one place. In the past when I've seen stuff like that, it means a lot more work finding stuff. I like what Qubes does, and I think the Qubes VM Manager sums it the state of things pretty nicely, currently. I really don't have a problem with it and the way it's tied to main Qubes menu. But I'll Joanna's page a more detailed read when I'm a bit more refreshed. Thanks. :) 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/441974ba840cb5033821e153a452e3ea.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?
> On Saturday, August 27, 2016 at 1:50:22 PM UTC-7, johny...@sigaint.org > wrote: >> BTW, keepassx rocks. I'm working on some scripts to make it a little >> less >> painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts >> with the standard konsole paste shortcuts). > > I have no problem with the special cut/paste. Doesn't mean I don't screw > it up on occasion, but I do like the assurance of having to do the step > > Actually you betray yourself with the correct solution above; Speaking of "betraying yourself," that's why I am working on a few scripts. More than once, I've thought I've copied they URL (from sigaint, for example) and gone to paste it, but I copied/pasted the password instead into the URL bar. D'oh! Even if I didn't load the page, with SIGINT stuff, I don't like having my password show up on the screen. Some scripts to let keepassx in a non-network VM interact with a networked VM's browser could avoid such betraying-yourself screwups. A few Qubes features are described as not protecting you from others, but protecting you from yourself. This falls into that category, IMO. > the Qubes > shortcut to copy/paste between VM's is Ctrl-Shift-C/V which conflicts. I, > like you, map that to Ctrl-Alt-C/V so no conflict. I've wondered why that > isn't the default since the other is such an obvious conflict. Agreed. It's way too obvious a conflict. There's just not enough key combos on the damn keyboard it seems sometimes. :) >> Using keepassx on Tails is so much more streamlined, without the extra >> level of copying/pasting. It'd almost be nice if there were some >> explicit >> dom0 support for it somehow. > > Yeah but Tails suffers from the same thing other OS's do which is one big > system. So if it was theoretically compromised your streamlined copy/paste > is exactly what you don't want. I'm a bit torn on that issue. Calling it "one big system" when Qubes is arguably more complex, I'm not sure is correct. I guess it depends upon your perceived threats. There have been times when things got "weird" on Qubes, and retreating to a Tails DVD-rom felt safer. But the Xen-on-top (with IOMMU protection against DMA attacks, etc.) ultimately should be safer. So confusing at times. > Nothing you don't know, but I don't want the inter-VM copy/paste to change > a bit. It's a small burden for a huge benefit. It also has an additional > benefit of each VM having it's own Paste buffer, which ends up being very > convenient. I hear ya. Right now, I *trust* the inter-VM copy/paste mechanism. I don't want features introduced that make it more complex/less trustworthy. And I think the tools are there with qrexec and the permissions system implemented to do what I want it to do, without changing the core. So yeah. :) If it's working, don't break it. >> Agreed. I keep my keepass database on one removable device, with a >> keyfile on a separate removable device plus a password. Some cowardly >> creep/crook wants to tamper with my system while I'm out, they're not >> going to get very far. > > I'd argue that your actually less secure with that scheme. Johanna made > some comments to that effect, what you are doing is a kind of air-gapping, > but you have a large attack surface through USB. Trust me, every time I hear those three letters, U.S.B., I think "security compromise." Why they ever let programmable firmware and stuff into the mix totally escapes me. If WW3 every happens, I swear it will be triggered by some USB security screwup. :) I actually load most of my keys off of 3.5" diskettes. :) Sometimes retro feels more secure, less hackable. > If an Evil Maid controls > your system it does you no good to bring in your passwords on a USB. No TPM here, just BIOS, so I don't think anti-evil-maid is something that applies to me. I could be wrong, need to research it more personally. I have a couple of personal anti-tampering approaches I use myself in lieu of that, which I might suggest as additions to Qubes at some point; but I won't talk about them just yet. > So, > if you're really concerned with that you should be implementing > Anti-Evil-Maid on your system as the only defense - not keeping passwords > separate. I'll read up on that more. Can't afford a maid, but I think there are other evil actors about. :) >> Since moving to that approach, I've noticed a lot more "noise" from the >> ones I suspect of being involved in my harassment. Ironically, probably >> a >> good sign. > > OH, OK then you have a situation with a probably not too computer > sophisticated opponent. Never mind then. The biggest mistake I've made (repeatedly) is underestimating the opponent. I have been totally naive throughout a lot of the grief. (In reality, I think there's a mix: one or more sophisticated opponents; and mostly likely expensive hired help. And one or more obviously not-to-sophisticated actors, that make obvious screw-ups now and then. Which makes things all m
[qubes-users] Qubes VM Manager Suggestions
These are fairly minor cosmetic issues, and if I ever get some of my current struggles under control, I'll submit patches instead of suggestions. :) I think the Qubes folks work on the VM Manager (and install process, which is amazing) has made major strides in making the system more accessible to all. Which is, in turn, key to making a secure work/personal computing environment available to the oppressed, or those who are simply security conscious. In that spirit, here are a few minor things I'd like to see tweaked in the VM Manager: 1) Column resizing. I like to toss my windows into one of four "quadrants" on the screen. xfce shortcuts make that pretty easy to do. But it'd be nice to see the whole VM Manager, not truncated, with the fields I want to see, each given the column size they deserve. 2) Current CPU % takes up wa to much space for a simple two-digti number. You don't need a bar graph to go along with it. 3) The CPU graph itself could easily add the current CPU % to it (centered, perhaps), without compromising the display. 4) Custom ordering. I like to stack my VM's in the order I want them. (Maybe even nested. :P) Currently, I use my own coloring scheme to achieve that, and sort by color. But it'd be nice if there were better support for arranging the multitud of VM's. (Just FYI, if you sort by color, the order is red-orange-yellow-green-gray-blue-purple-black. I usually sort by color, and use red for system stuff; orange for dicey stuff with no firewall protection; green for stuff that's nicely protected by Tor or a VPN; blue for stuff that has *no* network and is just a lot safer; black for templates; grey/purple for VM's I either no longer trust or no longer use). 5) It'd also be nice to be able to hide certain VM's (or certain colors, perhaps) no longer of interest, but that you want to keep around for reference. (Like the "internal" flag, but separate). The color mechanism is a great cue to the level of security you've flagged certain VM's to be, so that might be a good way to hide/show certain classes of VM's. 6) It'd be handy to have the application list for a VM (as you see on the main Qubes menu) be accessible when you right-click on a VM. Right-click on WorkVM, choose Firefox, kinda thing. (There's a "run command", but having the configured app list show up would be a lot handier.) 7) Are there any thoughts to support "hibernation" in VM's? (Not just a pause, but something that could survive a reboot?) "xl save/restore" does it, and I've had a bit of success with that, but I think it freaked out the VM Manager on a couple of occasions. :P Especially when memory is tight, it'd be nice to be able to hibernate a less-critical VM or two, and fire up something more important. I think I've read that disposable VM's use that save/restore feature, although not having explored that feature thoroughly yet (and that fact it takes up precious memory), I have that disabled for now. I think that's it for now. Sorry for the brain dump. :) 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/3e6cf6fc76a5c53d70e3dd6d2c52cbf2.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] OSX
Hey, does anyone have any luck with getting any form of OSX to fire up under Qubes? After several other failures, I was able to get some iPC ISO build to get to a certain point in an HVM, but the mouse didn't work, so I couldn't do much, and I couldn't figure out how to get it to any kind of command line (single user or otherwise). Not looking for the full OSX experience, just want to fsck_hfs some legacy drives that are too cranky for Linux. Get a successful fsck done, and turn off Journaling so Linux is a bit friendlier with them, until I can copy/retire them. Anyone? 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/9a1f0c7e6499db733ffcb5cbb5641e33.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?
> On 08/27/2016 07:36 PM, Cube wrote: >> On Saturday, August 27, 2016 at 9:31:31 AM UTC-7, Alex wrote: >>> On 08/27/2016 05:59 PM, Cube wrote: For specific services (say, the >>> mentioned Amazon) I keep a keepassx database on the specific AppVM >>> in which the service is expected to be used - the Amazon account I >>> use to buy work stuff is saved in the keepassx database in the Work >>> appVM, the personal one is saved in the personal appVM. BTW, keepassx rocks. I'm working on some scripts to make it a little less painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts with the standard konsole paste shortcuts). Using keepassx on Tails is so much more streamlined, without the extra level of copying/pasting. It'd almost be nice if there were some explicit dom0 support for it somehow. While it'd be more convenient to put keepassx in the same VM as your main browser, keeping keepassx in a network-less vm makes so much more sense. (Some day, true feature-by-feature access isolation for apps will be possible, kind of like what Android "promised." Cough, cough... Stupid Google. But for now, the VM isolation is the way to go.) And to digress further, does anyone have opinions on Keepass2? It looks "shinier," but I'm not sure needing to haul in all of Mono *adds* to one's peace of mind...? > I see, this may be a personal preference. Me being obsessed with > architectural research, I like to explain this with "isolation". Actual > benefits may be that I can share the personal keepassx database with > another device with simple tools, say - the laptop I use to only watch > cat videos on youtube when I'm done at the workstation. You have a dedicated cat-video laptop, too? Awesome. :) One thing in my paranoia-induced-retreat-to-Fedora made me notice, is how conservative Fedora is with regards to playing videos and such. I realize some of the factors are licensing issues, but having to go to a non-Fedora-approved, non-Fedora-Reviewed, repository (Fusion) to simply view mp4 videos with mp3 audio didn't sit well with me. And half the "howto's" about adding that repository involved a --nogpgcheck flag, which isn't cool with me, either. :) I guess there are signing keys around, and people say "yeah, sure, you can trust rpmfusion, it's been around forever" but it just doesn't seem as provably trustworthy as the core repo. It'd be a great vector for attack. (Which gets one looking at how debian can play mp4/mp3 videos/audio by default, by trusting nonfree/contrib repos by default... H.) I've settled on the compromise of having all those non-free/contrib/non-reviewed stuff in AppVM's with no network connectivity. Any exploits can have their fun nuking my downloaded cat videos. For work + personal browson and email, I stick to core Fedora AppVM's with no third party non-certified add-ons. Feels right. :) >>> And there are some types of password I keep in a >>> non-internet-connected AppVM, together with some OTP generator >>> scripts. I'd really like to see some default OTP stuff for the major distros and Qubes. I'll probably hook in otpw or oath myself for fun, but it'd be nice to see some of these more powerful authentication systems supported "out of the box." >>> They are meant to be used for targets that may be >>> sensitive to large scale attacks These days, I think anyone is subject to attacks on a mass scale, for anyone who is willing to pay to get access to the hacks. Many a time I've been led to believe that things are simply hacked by default, and up for sale if the price is right, to anyone with enough money or craziness to invest in it. Just my cynical point of view. :) >>> (say, home banking credentials, >>> amazon AWS otp generators, etc.) where attackers may have the >>> financial power to aggressively attack the target AppVM - so my >>> line of defense here is to be sure not to have the sensitive >>> information available on the filesystem at all. Agreed. I keep my keepass database on one removable device, with a keyfile on a separate removable device plus a password. Some cowardly creep/crook wants to tamper with my system while I'm out, they're not going to get very far. Since moving to that approach, I've noticed a lot more "noise" from the ones I suspect of being involved in my harassment. Ironically, probably a good sign. (It's funny when you change a password on a certain site, and suddenly several people contact you that you haven't heard from in ages. Similarly, after cleanly changing a password without any errors, and then seeing several "sorry you're having trouble logging into your account" messages is another pretty good indicator that someone's actively messing with you.) >> Well they're in the AppVM though so are on the filesystem, aren't >> they? What you buy is network isolation, effectively air gapping, but >> even better. > It depends on the point of view; yes, they are on the same dom0 > filesystem, but they are on differe
Re: [qubes-users] Qubes VM compromised? - Follow up
>> Whether using an "isolating proxy" (multiple machines) or not, using a >> white-listing proxy like Corridor can help ensure all of your traffic >> passes through Tor (Entry Guard, at least). >> > > That's right. Also, using Firefox with those extensions is *not* the same > as > using Tor Browser: Understood. I do take a few more precautions (with iptables, bridges, etc.) but Torbrowser certainly does take care of a lot of important things for you. > https://www.torproject.org/projects/torbrowser/design/ Wow, that's a great resource, thanks! I think I still prefer to "roll my own" versus using TBB. (And that link is great for tips on doing that.) There are four (probably reasonable and legitimate) things about TBB (and tails) that are red flags to my overly-paranoid mind: 1) Not a problem in Tails (being a bit "read-only), but the normal Torbrowser Bundle is very stubborn about doing an update check every time it starts. I understand the reasoning behind it, keeping up with 0days as they're discovered, and at least one exploit in the past would have been avoided by anybody who stayed updated. Sure, notify me, but forcing that "phone home" on every start is a bit too much like MS-style tracking to me. I could be wrong (I often am), but even turning off the update check in settings didn't seem to work for me. Although I might have screwed up somehow or it might have been an artifact of non-persistence in an AppVM. Having that update check/download on by default, I don't like. Finding the actual tor browser binary to launch is a major pain. It almost seems intentionally hidden. :) 2) JavaScript on by default. I understand the convenience for the general public, but TBB isn't really for the general public but the security-conscious. And the security-conscious shouldn't turn on JS unless necessary. (And with Qubes, one can keep their JS-dependant sites to a separate VM, whoohoo!) In Tails, having JS on plus automatically loading Tails home page (which could be subverted by someone with CA ability) is a bit of a risk, IMO. To avoid having a JS-enabled load of the Tails home page, you have to start it without networking, disable things, then enable networking. Blah. 3) Default search engine set to Disconnect.me. And disconnect.me seems to do nothing but redirect your search to duckduckgo. Why are they even in the loop then? Supposedly they financially support the tor project. So a company founded by a former NSA person paid money to be able to capture all the searches that are eventually done by DDG in TBB/Tails. Oky... Whenever I do launch Torbrowser, the first two things I do is disable global javascript, and change the default search provider. 4) It's not really fair to include this one, as I have nothing to back it up with, but I remember something in the past that made me a bit uneasy about Torbutton. I'll follow up if I can remember/find my concern. Interested in hearing others opinions on those points. 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/d21ff94ceb2ed97c456bc3e127f1318a.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM compromised? - Follow up
> Am 25.08.2016 um 21:33 schrieb johnyju...@sigaint.org: > >> While it's a bit slower, I prefer booting from DVD, a read-only medium. > > There are verifyably hardware-controlled (physical switch) unwritable > USB storage devices. A bit expensive but you can get one. I might look into that, it would be a lot more convenient (and faster) than DVD. In case anyone's not aware, the slider on "secure" digital media cards is just an advisory for the software to not write to the SD card, and not enforced by hardware, so very easy for malware to bypass. 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/5d85ce7a951b0b438891c9f46aaa3f5b.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-block by UUID?
Most standard Linux utilities that refer to block devices, allow you to specify by uuid as well (mount, cryptsetup are two examples). The documentation for qvm-block is sparse, but probably because it's a striaght-forward utility. There's no support in qvm-block to assign a device to a VM by UUID, is there? Could be handy for some of the automation I'd like to put in place on firing up the system. One can always lsblk|grep|sed|cut|whatever in a sh script, and then use the resulting block device for qvm-block, but it'd be a lot cleaner and less error-prone if one could say "qvm-block -a Florp UUID=kasdjflaksjdfaklsdf" or "qvm-block -a FLorp --uid asdfkasjdlfkajsd" Just a suggestion. (And for any other qvm-* that refer to block devices, perhaps.) 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/2554d22727f99f1b2ce2d7444cc2b901.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM compromised?
> On 08/23/2016 07:25 PM, Chris Laprise wrote: >> What threat model does this fit? If a skilled attacker tricks you into >> thinking you created an account at sigaint, but you later cannot use >> it... what is the advantage of that? The possible gain seems to be >> little or nothing. > > Well, (s)he has changed all its passwords. Tricking someone into > changing all passwords has been done before. Indeed. Psyhchological harassment can often by the goal, not necessarily theft of credentials. (There's nothing left to take, in my case, lol.) And when I said I had a psycho ex, I truly meant that she has truly shown all the signs of being a textbook psychopath or sociopath, and invested heavily in having me harassed online. (I don't think she's a genius hacker herself, lol.) When you're dealing with a psycho/socio-path, logical and rationality doesn't always factor into things, which can be hard to get your head around at times. Sheer destruction can be the goal (in her case, a stated goal). That being said, I can believe that the recent password weirdness was probably PayPal anti-fraud mechanisms being careful (or confused) with Tor. (I'd say it could also be someone trying to grab all credentials from a dodgy exit node, but the fact I saw the SSL lock/certificate and the real PayPal URL makes me doubtful, unless the browser was compromised and lying.) Part of the leverage of psychological harassment is that you start seeing unrelated screwups as part of the harassment. It's good to be careful to try and separate the two. Not always easy. 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/72e45af0b5117271fbbff0ae7e40d5c8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM compromised? - Follow up
> I am too paranoid for using tails other than the reccomended method (two > usb drives updating each other - I have two pairs of three). No aware of the two drive method. Is that just updating to the next version from the previous version, onto another USB drive? While it's a bit slower, I prefer booting from DVD, a read-only medium. (A bit of a pain to update, having to boot to a USB stick to write the newer version, but it has to be done infrequently.) There's peace of mind in a true read-only medium, that you keep with you. > I just use Whonix within Qubes and I like it. I'm glad it comes out of > the box since 3.1 I've retreated to only using Fedora. Setting up Tor and Firefox (with noscript, ssl observatory, adblocker) to use it as a proxy is essentially the same effect as Whonix (or tbb). Even if tor/firefox are on the same vm rather than separated, you're behind sys-net and sys-firewall, so your real world address isn't going to leak. Another two VM's on top of that (whonix-gw and whonix-ws) is a bit of overkill IMO, and a memory pig. (I've wondered if it might be more natural to have tor running in sys-firewall; it is kind of a fire-wall-ish thing. But having the firewall separate is a nice additional barrier in case of compromise.) > Also, I would never use tor for banking, unless the banking wouldn't > involve my real world name - understand that one how you want. Yeah, exit nodes are too scary. Okay to keep reduce cyberstalkers, but for financial transactions, it seems a bit risky unless you got a solid HTTPS connection (and trust the govt and crooks not to abuse CA's; I guess that's not something seen in the wild much. For a high value target, maybe; for someone being harassed by an ex, less likely.) 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/9a51f2eb8dd6a8744cf6411ed09cae47.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.