On 11/04/2016 10:59 AM, Simon wrote: > Hi Alex, > > Alex wrote : >> On 11/03/2016 11:37 AM, Simon wrote: If you use keepassx you may >> want to use its auto-type feature, which is designed exactly to >> prevent password theft by keylogger-only or clipboard-monitor-only >> malware. Auto type works by typing random parts of the password via >> simulated keystrokes and other parts via copy-and-paste, making the >> life of password stealing malware writers miserable ;) >> > > Do you mean that KeepassX auto-type feature works in a cross-AppVM > way? No, it does not - it works this way by design, which is not specifically made for Qubes but for any windowing gui environment (also windows, osx). So you can use auto-type inside a single AppVM (where you have both keepassx and your browser), but you cannot use it cross-appVM because of Qubes' window content redirection.
I don't know exactly how it works on linux, but I think it just sends window messages, so it works on the local X windows inside an AppVM, but it will not automatically do anything qubes-related. > The only way it should be possible would be to store Keepass(X)'s > database alongside with the browser, but in this case I see no > substantial benefits over using the browser's own password management > DB (unless we are talking about an application without similar > feature, like handling SSH password for instance). I do use it for other applications, so I like to have it all centralized and easily portable/syncable without having a bunch of text files. Like I said in an earlier e-mail, I also like the increased practical security with respect to browser-kept credentials - it surely is not much of a protection, since owning the browser you can reach local files/programs, but it just makes this difficult and hardly applicable to everybody. The reasoning is, if you develop an exploit to gather all passwords kept by Firefox or Chrome, it may just be some javascript exploit. If you get to run arbitrary code as the tab user it often gets much more complicated; you are more likely to stop at gathering passwords kept in the internal DB rather than go full-nuclear on trying to access every password keeper that may be installed, in any version that may exist, to convince it in giving you all of the passwords. Database files from password keepers are usually encrypted, so the browser exploit can't just copy any *kdbx file it finds... That's what I mean by saying "it's not secure, it's just much more unlikely as an attack". > [...] > What I'm talking here is about a user-friendly way to open an > untrusted link from a sensitive AppVM into an untrusted AppVM, this > should actually not involve the clipboard at all but be a simple, > classical right-click operation. This indeed seems a nice idea. I can see the problem in implementing that; the interfaces for opening an URL are all but standard, sadly :( something like Android's Intent system, ported to a desktop OS, would provide a single tapping point to intercept the action (and, in our case, ask the user "do you want to open that in a dispVM?") > I do not think there is really any risk of wrong manipulation here: > personally I do not remember having mistakenly right-clicked on a > file and opened it in a disposable VM or sent it to another VM when I > just wanted to open it locally using a simple left-click. I agree. >>> One should not do any change to their Whonix AppVM, so everyone >>> uses the same, and an app running in the AppVM, no matter how >>> malicious it is, cannot access anything outside of the AppVm >>> without having to break Xen isolation first and cannot apply any >>> modification of it which will survive an AppVM restart. >>> >>> So I'm quite confident that there is no easy way to remotely >>> distinguish two Whonix AppVM instances or identify one. >> Which is nice, if your threat model is trying to identify the AppVM >> and not the user behind it - which is usually false. >> >> While identification of the client device is one of the way of >> identifying people it's not the only way, and usually the goal is >> not the identification of the client device itself. For an easy >> example, that's why spies in hollywood movies connect to the net >> from public WiFi hotspots, hotels, airports, but not from home. > > From my understanding, there is actually two level of correlation > when you want to convict someone: > > 1) You demonstrate that it was the same machine which was used for > all incriminated actions. 2) You demonstrate the link between the > suspect and the machine. > > In your statement, for n incriminated actions, you would need to > demonstrate n times the involvement of the suspect which can be very > hard, if not impossible. > > It is far easier to demonstrate that the same computer has been used > for all of the n incriminated actions (either actively by putting > some tracking bug on it or passively by correlating various > information for instance), no matter if it is using some public or > private Internet access, and then show a single proof demonstrating > that this computer is actually owned and used solely by the suspect. > My explanation was based on the assumption that we were defending against unwanted nuisances, like pervasive advertising or stalking psychopaths, not against law incrimination... That's a very different threat model. And what you described is exactly how law enforcement works on the forensic side, and - I'm sorry Dave, I'm afraid I can't do that - I have nothing against that as a principle. > I do not use tinfoil hats, these are lies invented by governments to > better spy on us. I'm telling the truth: this has been > scientifically proven! Sorry, but your statement lacks in logic. The scientific paper is correct and logical, because that's exactly why antennae have funny shapes - I did build myself cantennas when the WiFi craze started, and had to tune them to exact frequencies. The size of tinfoil hats makes them obvious resonators to their characteristic frequence, which logically depends on their form and dimensions, exactly as the study finds. That works for metallic cutlery too, you know. And for any metallic necklace, ring, wristband you may wear. And for a bunch of reasons, broad parts of the radio spectrum is "reserved for governments", while actually any government has little differences in the reserved spectrum part. A frequency that may be reserved in the USA may be freely available to anyone in Europe, or Russia, or China, you name it. The flaw in your logic is that nowhere in the study you quoted is stated that the natural fact that metallic object resonate at the most random frequencies (unless tuned, and then we call them antennae) indicates that is a government-driven effort to spy on anyone. The only indication is, as quoted in the link you shared, the phrase "We speculate that the government may in fact have started the helmet craze for this reason", which is, as written, speculation. Knowing some MIT fellows myself, this last phrase may just have been a prank on tinfoil-hat-wearers... :D Btw, the first to mention Hitler wins. Oops, I won :D > As a StackExchange user, I take this as an opportunity to share my > hope that the proposal to open a section dedicated to Qubes will > eventually reach all criterion and open: > > https://area51.stackexchange.com/proposals/98519/qubes-os > > I think this would be a really great place to share information and > build a good quality and more practical knowledge base and encourage > the readers of this mailing list to commit :). It would be nice to have it :) >> So let me sum this thread up: I'd have to severely cripple my >> browsing experience to hide from some unspecified tracking but then >> I'd love to simplify the UI around the browser, thus paving the way >> for more inter-vm mistakes... Mmm I think I'll pass :D > > Personally if I use several AppVM for browsing it is not against > tracking (I have the same IP anyway), but as what I consider to be a > minimum security level (even if only very few OSs propose this > currently). I do isolate my browsing activities for security too; my summary was on the hypothesis of protecting from tracking, which would ultimately be not worth the effort. -- 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 [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/bb96337e-e0b9-23ba-0a0c-441e274935ae%40gmx.com. For more options, visit https://groups.google.com/d/optout.
