On 08/27/2016 10:50 PM, johnyju...@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). That would be nice. KeepassX used to have a working auto-type feature before v2, in which it was completely broken on Qubes. I did not try the auto-type of keepassx2 on any other fedora installation...
> 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 tried that, because I used to use that on Windows before moving my main workstation to qubes. It's even more broken than keepassx2. And I say that as a professional cross-platform C# developer, so absolutely no prejudice against Mono. > 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. > [....] > 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. :) > I understand your cynical point of view, but just two paragraphs above that you seem to heavily discriminate against "non-core" repositories (i.e., rpmfusion) wrt Fedora's official repositories. I can't agree with you on that: for me, the Fedora repository is just as exploitable as any other repository can be, be it rpmfusion or debian; did you ever question your blind trust in Fedora's repos above the others? Why do you think one is preferable than the others? I'm sorry if I sound a little aggressive, English is not my primary language, I just want to understand your point of view. That distrust in software repositories is one of the very reasons for the templated infrastructure of qubes: isolate vms, create different templates with different software to minimize exposure of data to untrusted software. >>>> (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. > I think you are mixing threat models, and I myself lost once in that sea... Being Qubes a single-user OS for local-console-interactive workstations, the question about caching web passwords in browser or not does not belong to analysis of physical exploits; thus my threat model, which does not include any physical attacks beyond evil maid. But judging from your paragraph, I can't discern your threat model. Is it a software exploit? Is it an untrusty person walking up to your computer? It seems to me quite inconvenient to have to juggle with 2 usb thumb drives, with all the added burden of connecting each to the correct AppVM... About that: connecting USB thumb drives to AppVMs it's just a couple clicks more, but the added work drove me in using thumb drives less than before. And I think that's a relatively healthy habit to acquire... But I'm going too much OT. > 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. I don't agree this will add any security. Since the keys should actually be in dom0 (or pass through that, if entered by a user), having a compromised dom0 will ultimately lead to global vulnerability, be the disk images encrypted or not. This will negatively impact performance, instead. Again, depending on the threat model, you may want to be able to give up some functionality to increase security in specific scenarios, but - as for the two thumb drives - does the burden really pay out for the users? What benefit to the world does it give an OS which is nearly unusable because of some very unlikely scenarios? I think Qubes fits the general purpose secure OS model, with isolation and segmentation, and I think this makes it fill a long-standing gap between the Windows-with-administrator-user and air-gapped military mainframes. If some user is so concerned with security, they may want to move to military tools or remember that thermorectal cryptanalysis (or the XKCD wrench, if you like) breaks any software security scheme... -- Alex -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b04f8bcc-23db-af89-a084-d075fec372f2%40gmx.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
