> 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... Hmmmm.) 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 different filesystems from the AppVM's point > of view. May as well be on another machine, or another universe, if Xen > isolation keeps. That reminds me: one thing I think I read in some Qubes architecture docs or online reviews, was the mention that each AppVM's filesystem was individually encrypted with its own key, which is clearly not currently the case. Are there any plans to support this in the Qubes VM Manager? Currently, I just keep personal communications, documents, etc., in a separate, encrypted, mountable device that I can assign to a VM as needed. But having individual keys for each VM would go further towards one stated goal of disallowing each VM or dom0 from being able to snoop on each other. Right now, the overall dom0 filesystem is encrypted, which is cool, but nothing beyond that, unless you do it yourself. Yeah, more passwords are a pain, but if you choose to do so in the name of security, it'd be nice if the Manager supported it. Also, does anyone see any potential security holes with the (fairly convenient) "Additional Drive" feature of HVM's? I guess that can only be configured from dom0 (and it's canon that if that's compromised, you're screwed), but it strikes me as something that should be looked at pretty carefully. Sorry if I'm rambling off-topic a bit here, but these are a few security concerns I've thought about since starting with 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7a32396bb1468bbe903030c5bfec0a3e.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
