>which may or may not be *detected* by a sharply observant user, but could >still not be *prevented* by one
Um, that is incorrect. I'm not sure you understand at all what I'm talking about here so let's go over it step by step: A. User visits a site associated with a pre-stored password and presses a special key combination. B. Dom0 polls the active window title repeatedly over let's say one full second. Attentive users may at this point glance briefly at the window title to make sure it matches what the website is. (This isn't *really* necessary given how infeasible an attack would be, but a single glance at the title during the polling period is all you need. You don't need to stare at it. I often glance at the HTTPS when I visit sites, don't you? Why not glance at the window title?) C. At the end of the polling period, Dom0 copies your password to the clipboard of the VM associated with the active window. D. If the window title did something odd, DON'T PASTE YOUR PASSWORD IN THE PASSWORD FIELD. And definitely don't paste your password in the password field and then hit submit. It's as simple as that. Since we're talking about non-compromised VMs only here, the attacker will be unable to retrieve the clipboard and your password will thus be safe. You might do something like write a browser extension to automatically paste the password in the password field as browser password managers typically do. Such an extension could and should, of course, take additional measures to ensure the password is the correct one intended (I can think of a couple mechanisms offhand.) This is preferable, and it's also something that would take more effort. >Your argument appears to reduce to "This may be theoretically exploitable, but the ease of implementation and additional convenience is more important to me" Uh, yes. That's Joanna's philosophy, too. Everything is a tradeoff. I'm not claiming that she would agree with me that this tradeoff is a good idea, but the perfectionist stance you appear to be taking, as embodied by this statement, is antithetical to everything I've seen in the Qubes philosophy. Qubes is about reasonable security (citation: the Qubes motto / tag line) with reasonable usability. If security always trumped usability, surely there wouldn't be a GUI at all. (If I'm not mistaken, that's pretty much the approach the OpenBSD people used to justify their superlative claims.) >hold, passwordless sudo is *not* a theoretical weakness What rubbish. Yes it is. >The key difference between this and the passwordless sudo argument you bring >up is that the qubes security model explicitly assumes that user->root >privilege escalation within a VM is possible The 'Qubes security model' depends on user behavior to support it. It actually puts a far greater burden on the user to not be stupid (e.g. use banking VM for all kinds of other stuff) than this password tool would. If you insist there's no theoretical security loss with passwordless sudo, then there surely is no theoretical security loss with a password tool such as this. Heck, we don't even need to consider remote attacks to see how usage entirely determines the security implications of a passwordless sudo: a person walking by can compromise your un-screenlocked machine. And this is already a threat model that Qubes takes seriously, as demonstrated by their anti-evil maid packages. Obviously, a passwordless sudo in Dom0 or the VMs is a major vulnerability whenever physical security cannot be guaranteed. You are not just relying on the user to properly use screen lockers, but you are also relying on the screen locker software to not fail. An uncompromisingly strict obedience to the security in depth principle, with no regard for user convenience, would surely frown on such a single point of failure, no? But I repeat, I mostly agree that the convenience of passwordless sudo outweighs the risks, and even I would go a step further and say that this could be an example of an inverse of the password post-it note effect: when a secure tool (such as Qubes) becomes significantly easier to use with a very small additional risks incurred, it results in a REAL WORLD SECURITY GAIN, at the cost of some additional minor theoretical security risks. This is exactly as it is with a password manager such as I describe, except the risk is even more negligible because the attack would have to be conducted completely blind and could be easily spotted and foiled by an aware user. Such a tradeoff should be acceptable for the first iteration of a password manager. Later iterations could use browser extensions or multiple VMs doing fancy tricks or whatever long term solution is best. And as far as my using phrases like "attentive users" goes, another analogous situation can be found with something else that's already shipping with Qubes: Whonix. In many situations, Tor can be more dangerous than no proxy at all, even if you fully understand how it works. For a noob who understands nothing but a magical gateway that makes everything private, Tor is a liability. Let me end by stressing that there could easily be good arguments against such a tool... it might be harder to implement than I imagined, or it could be that I'm the only crazy person copy-pasting passwords from offline VMs thus no one else would care because this tool would be a bit more cumbersome to use than a browser password manager, or perhaps there's a much better solution that's already in the works. -- 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/5264d207-7053-4a8e-a38c-8afffe5ff7bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
