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?
In one dedicated, networkless AppVM I have Keepass (sadly started some
time ago with the new DB version which, AFAIK, is still not supported by
KeepassX :( ), in another network-enabled AppVM I have the browser (or
any other software for that matters).
As per my understanding there is no way for the Keepass(X) software to
emulate keystrokes on the browser's interface, unless I missed something
very important in Qubes' architecture.
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).
Besides it is incredibly annoying to operate this way. I am not
some prime target of the NSA ^^, and I doubt many of the people using
qubes will be... So you want to be safe, but you still want the
convenience... The right way is to block the link, unless it refers
to
a white-listed domain for this identity.
No, the right way is to propose people an option in the browser's
right-click menu offering them to open this link in an untrusted VM
(similar to the "Send to another VM" or "Open in a disposable VM"
option
in the file manager).
I agree with you that, IMHO, the right-click followed by 'A',
Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter
"shortcut" sequence to achieve the same task currently could and
should
be improved in terms of usability for Qubes to reach a wider audience.
But I do like the fact that I have to make so many mistakes in order to
copy my data from the "pr0n" VM to the "work-boss" VM... But if I have
to copy a pr0n link from a 4chan greentext to another pr0n tab I only
have to ctrl+c / ctrl+v like I used to do with plain fedora. I'd
strongly disagree with any simplification of inter-vm generic clipboard
sharing. I'd agree with some easier facilities for centralized
(trusted,
without networking) PasswordDatabaseVM. But I'll doubt I'll be using
it;
I like to keep a "porn" keepass database on the porn VM, many work
keepassx db on their respective VM, and so on, to further avoid having
a
simple "autotype" open the wrong URL.
I'm not talking about clipboard sharing by itself, which I also consider
to be good as it is now (unless maybe the minor fact that it overwrites
the default common shortcut to paste something in a terminal, but that's
really not big deal).
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.
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.
The only real risk of wrong manipulation is to directly open the
untrusted link in the sensitive VM. The current situation does not help
against that, actually it even encourage to do such wrong practice by
making it more difficult to open a link in a different AppVM.
I do use i3wm as my window manager, and have only 1 monitor with the
vertical-split layout; all the others are tabbed, and it works great.
It
may well emulate the concept of "dom0 browser".
Thank you for this confirmation. I never used such windows manager
myself, but this was indeed my assumption. I hope Mara will have the
opportunity to check this :) !
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.
As I stated in other messages, it's deceptively easy to get carried on
to pure paranoia. Model your threats before shopping for the right
tinfoil hat.
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!
http://scienceblogs.com/startswithabang/2009/04/03/weekend-diversion-do-tinfoil-h/
"Statistical evidence suggests the use of helmets may in fact enhance
the government’s invasive abilities. We speculate that the government
may in fact have started the helmet craze for this reason."
It is good to see serious researchers taking great care of defending our
privacy, ;) !
Panopticlick and online-activities tracking is yet another wide
subject.
I invite you to check the answer I wrote there on this subject:
https://security.stackexchange.com/a/138525/32746
Thank you for the link, it's been an interesting reading.
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 :).
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).
The threat for me is not unspecified:
1. Create a malicious website, or hack a vulnerable small site to make
it store some malicious content.
2. Post a link claiming there is a interesting article on some secured
forum or mailing list.
3. Get access to the visitors computers content, including their
credentials to this more secured forum / mailing list + potentially
other resources.
Such threat is far from being NSA-level.
AFAIK, Qubes OS is the only libre and production-ready OS allowing to
effectively fight against such threat... as long as you take the habit
to not mix all of your surfing in one single AppVM.
Regards,
Simon.
--
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/0b4d7bce59b1c33238ba81d66ba89454%40whitewinterwolf.com.
For more options, visit https://groups.google.com/d/optout.
