Special (Secure) Browser Frontend for Qubes?!
mara.k...@gmail.com
I am using Qubes daily for a while now. One thing I think is really missing is some sort of identity management. This is most visible when browsing. You shop something on Amazon, then go to check some Facebook updates and look at WhatsApp. Then you browse Hacker News click on this link and that link, end up on Wikileaks by accident then look at which club to visit in the evening... Yes this is shit.
But convenience often wins over security/privacy. Not only do you have to assume that all sites you visit within the same VM knows everything you did in there, but also you have to assume they know all the passwords for all the other sites you visit there and basically have full control over that VM. If you don't assume that, then why are you using Qubes in the first place...
I think what would solve this dilemma is a custom dom0 browser layer. The way this can work is as follows:
* Each identity consists of white-listed domains and HTTPS certificates (like amazon plus all its garbage), bookmarks, history, it's own password & auto-fill store and basically everything else like it's own cookies and the works.
* Trying to visit a non-white-listed website will simply not work without switching identities properly or using a special disposable identity
* Two identities are never used on the same VM
* You always use a new VM for each tab (there is potential for optimization, like sharing a VM per identity as long as this identity has at least one tab still open)
* Each VM is disposable (no home file system sharing) and get's the corresponding identity auto-copied on boot (only the essentials for Firefox)
* The browser gets installed after launch, so no kind of tracking can take place here via installation UUIDs etc.
So the core feature of this dom0 browser is basically identity management and the usual tab-based browser gui with history, settings, etc. But in contrast to what we have now, this dom0 browser will also manage the VMs that run the actual browsers and blit their page view into its dom0 tab.
Is there anything like that under development? Or how would you solve this issue?
Cheers
Alex
> Hi,
>
> I am using Qubes daily for a while now. One thing I think is really
> missing is some sort of identity management. This is most visible
> when browsing. You shop something on Amazon, then go to check some
> Facebook updates and look at WhatsApp. Then you browse Hacker News
> click on this link and that link, end up on Wikileaks by accident
> then look at which club to visit in the evening... Yes this is shit.
>
same identity on the same AppVM, and then you can create another in
another AppVM. If the identity can be discarded safely, then you can use
a DispVM.
There's little actual reason to use a hard-separate identity for each
and every web service you visit; first because they don't usually talk
to one another (i.e. amazon does not ask facebook for your info, nor
does this happen the other way around) and second because many of them
are, in fact, the very same entity (fb and whatsapp, gmail and youtube).
Third because you usually want to present a "brand" identity of yourself
around the web. Think of your personal blog or github account presented
on your linkedin profile: this is a reinforcement of your "brand"
identity, so you would like to share the connection between your github
and your linkedin identities.
> But convenience often wins over security/privacy. Not only do you
> have to assume that all sites you visit within the same VM knows
> everything you did in there, but also you have to assume they know
> all the passwords for all the other sites you visit there and
> basically have full control over that VM. If you don't assume that,
> then why are you using Qubes in the first place...
something like keepassx. Using it moves the security bar from 2 to 3 on
a scale to 10... It's better than nothing, and you can have a separate
keepassx AppVM for extremely sensitive passwords (and extremely
frustrating user experience, but still..).
>
> I think what would solve this dilemma is a custom dom0 browser layer.
> The way this can work is as follows:
an idea as bad as it gets. The main reason why dom0 does not have
networking, and should not have, is to prevent exposing data on *all* of
the VM at once. As a side effect of this, the less software there is on
dom0 the better.
Your proposal flies straight in the face of this architectural
principle. While I agree that your proposal makes sense from a
user-experience point of view, I solved my multiple-identity problem
simply with many appVM, that share some identities that can be shared
together - say, the 5 e-mail accounts I have to use for work.
TL;DR: first, do you really actually need to separate each and every
identity you use? second, once you realize that many identities can
co-exist (and indeed, sometimes you would like this to happen) do you
really need that many isolated VMs? third, why would you need to move
this complexity in dom0?
--
Alex
Simon
> Not only do you have to assume that all sites you visit within the
> same VM knows everything you did in there, but also you have to
> assume they know all the passwords for all the other sites you visit
> there and basically have full control over that VM
> I think what would solve this dilemma is a custom dom0 browser layer.
> The way this can work is as follows:
While I agree with you on your assumptions, I completely disagree on
your conclusion. What should actually solve this dilemma is to use
several AppVMs, each one dedicated to a different activity, or as I
prefer to refer it myself: to different sensitivity levels.
This way indeed, you can consider that a website at some sensitivity
level may have access to full information belonging to this same
sensitivity level, but if you design this correctly this should not be a
major issue.
So, first make a list of your different on-line activities and the
sensitivity of information stored / transmitted in each cases (if you
need some ideas, there was a very interesting article from Joanna
describing the process: you should quickly find and recognize it thanks
to the spaghetti-like diagram it contains ;) ).
Then, you may want to apply different setups to Firefox depending on the
needs and the trust level.
For instance:
- You may want to apply maximum paranoia on your random surf AppVM,
- You may want to be a bit more permissive in your shopping AppVM so
NoScript will not break a payment process right in the middle, leaving
you uncertain about how many times you will be charged.
- You may have a dedicated Firefox instance still having the infamous
Flash plugin installed when you need to access some websites requiring
it.
- Etc.
Decide how you may want to store your logins and passwords. Here are two
possible solutions, but there are other ones of course:
- Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest
you to create a "Web" or "Firefox" group, and then create a different
sub-group for each of you AppVM so everything stays clean and organized.
- Use Firefox integrated password management.
Before you scream, do not forget that all activity in this Firefox
will be limited to the same sensitivity level. For instance, you are in
your "Public forums" AppVM, someone posts a link to a third-party
website: you will *not* open this link in the same AppVM but instead
copy/paste it in your "Random surf" AppVM. Would this site be malicious
and steal your password database, it would miserably fail (without
mentioning Firefox "paranoid" settings in this AppVM).
The only way for someone to actually gets its hand on your Firefox
password database is to first hack the forum, and use it as a pivot to
then be able to hack your computer and get access to your file system.
At this point, installing a keylogger or a malicious Firefox extension
becomes just trivial, so avoiding to use Firefox password store will be
of no help and if you design your AppVMs correctly then all the efforts
deployed by the attacker will be done quite in vain since he will not
actually gain any new valuable information.
If you use Firefox password management, I would however still
recommend you to use the Secure Login extension
(https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so
Firefox does not dumbly automatically fill any password field without
requiring any human intervention (I find it a shame it still acts this
way by default): this prevents you against online stealing of your
password store content and require the attacker to either exploit the
browser or get his hands on your file system.
The two are not exclusive. Actually, if you use Firefox password store
(and I find it really more convenient than doing a dozen Ctrl-Shift
thing each morning just to identify myself on random public websites,
but YMMV), I would strongly recommend to keep at least a backup of these
passwords in some password safe like (X)KeePass.
There are still a some other points you mention in your bullets I did
not addressed until now:
> * Trying to visit a non-white-listed website
There are several Firefox modules (plus Qubes' firewall) which should
help you to ensure that you do not use an AppVM from a certain
sensitivity level to access websites belonging to other ones. Modules
like uMatrix or NoScript which allow to better control third-party
requests seem like a must here.
> * You always use a new VM for each tab
different tabs instead of different windows, but I'm not sure to see any
real advantage of this.
If you have too many windows opened (which indeed happens very quickly
with Qubes), do not hesitate to use your windows manager feature to
handle them:
- Assign specific activities to your workspaces (or desktops) and name
them accordingly instead of keeping the default names (it is easier to
distribute and manage your opened windows between the "Web", "Work" and
"Personal" workspaces than the default "1", "2" and "3"). I moreover
recommend having a different set of shortcut per workspace, even if
there is sadly no standard way to do this in XFCE (see
https://askubuntu.com/questions/581913/can-i-set-up-my-xfce-workspaces-differently)
- Reduce or roll them: since the switch to XFCE, have you noticed that
using the mouse wheel on a window title bar you can roll it to save
space and avoid distraction? I find this feature really useful.
- Check your windows manager setting to adapt it to your taste. For
instance, personally I set it to not display reduced windows in the
Alt-Tab menu, so I can focus on the window I am currently working with.
> * Each VM is disposable
to selectively make some AppVM to be volatile it would be helpful.
Some of my AppVM are used only for browsing and are not meant to store
anything locally (bookmark and history may be either
hardcoded/discarded, or saved remotely using the Sync feature). It would
be useful to have them volatile on a day-to-day basis, and turn them
non-volatile only to update Firefox's modules or save a change in its
settings.
> * The browser gets installed after launch, so no kind of tracking can
> take place here via installation UUIDs etc.
concrete threats there are. If you really need to keep your identity
secret for some life-or-death related tasks, instead of generating new
UUID you really should just use the same UUID as a lot of other people
by using Qubes' bundled Whonix support: this will keep you blended in
the crowd.
Talking about missing features for web-browsing, I would love to see a
plugin or a solution allowing to open a link in another designated AppVM
(the "Random surf" VM or a disposable one) with just a right-click
option instead of the current "Right-Click, A, Ctrl-Shift-C, Alt-Tab,
Ctrl-T, Ctrl-Shift-C, Ctrl-C, Enter" sequence...
Best regards,
Simon.
mara.k...@gmail.com
But that is not the point. First of all, unless your life depends on it, it will be very unlikely that you are actually paying enough attention to where you use which identity. A click on the wrong link can already screw it up because then site X read the tracking data placed on site Y and site X shouldn't know about what you were doing with Y... So you need some sort of white-listing to technically prevent those mistakes. Yes this can be done in different AppVMs and that is exactly what I am proposing here. It's about making what you describe much more convenient without a single drawback in security.
> There's little actual reason to use a hard-separate identity for each
> and every web service you visit; first because they don't usually talk
> to one another (i.e. amazon does not ask facebook for your info, nor
> does this happen the other way around)
Um, that is a bold statement, do you have any data to back that up? Maybe Amazon indeed doesn't talk to Facebook (yet), but no one is stopping them either. Facebook definitely has an interest to read your Amazon visits because this way they can link your true identity to your fake profile... for instance.
> are, in fact, the very same entity (fb and whatsapp, gmail and youtube).
True, and for those you will want to use the same identity (it get's complicated quite quickly which is why I am proposing to aid the user with this chore).
> Third because you usually want to present a "brand" identity of yourself
> around the web. Think of your personal blog or github account presented
> on your linkedin profile: this is a reinforcement of your "brand"
> identity, so you would like to share the connection between your github
> and your linkedin identities.
Maybe, but here we have the same issue again. I have other things in my head than trying to remember which sites shares what data with whom and which idenity I have to use where and which AppVM to start for it, it's just insane... This needs to be much simpler.
> And that's actually the point why I'm replying to your e-mail; this is
> an idea as bad as it gets. The main reason why dom0 does not have
> networking, and should not have, is to prevent exposing data on *all* of
> the VM at once. As a side effect of this, the less software there is on
> dom0 the better.
I think you entirely misunderstand my proposal or maybe I wasn't clear enough. My proposed "dom0" browser has no network at all. In fact, it can't do anything you couldn't do manually already. The point is to automate it. This dom0 browser frontend will know which identity belongs to which domain and which AppVM should be used for each identity and what your passwords & cookies were. It also feeds this data to each AppVm on startup so they can completely be disposable... The "real" browsers still run in AppVMs.
> TL;DR: first, do you really actually need to separate each and every
> identity you use? second, once you realize that many identities can
> co-exist (and indeed, sometimes you would like this to happen) do you
What do you mean by "co-exist"? If I use them at the same time in the same browser/VM I might as well just use one single identity because there is no way to know if either of them wasn't compromised or linked in ways I didn't want. I don't see how identities can co-exist (I am also not talking about sign-in data, I am talking about fake "me"'s, fake people so to speak who consume services to protect the real identity; I simply see no use case of why you ever want to share identities within the same AppVM or browser/site).
> really need that many isolated VMs? third, why would you need to move
> this complexity in dom0?
Because dom0 is the only place where this can meaningfully exist. Think of it as a different way of organizing the AppVM windows (not in the XCFE panel's, but instead as real tabs in a dom0 browser) and a lot of infrastructure code to help you with identity management.
Cheers
mara.k...@gmail.com
> several AppVMs, each one dedicated to a different activity, or as I
> prefer to refer it myself: to different sensitivity levels.
See my reply to Alex, maybe that explains why this is exactly what I was talking about ;).
> - You may have a dedicated Firefox instance still having the infamous
> Flash plugin installed when you need to access some websites requiring
Yes but this could and would be all included in this dom0 browser interface.
> - Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest
> you to create a "Web" or "Firefox" group, and then create a different
I am using UNIX pass, but it has the same flaw. If you copy passwords this way they won't automatically get purged from the AppVM, which under the assumption that any AppVM is completely compromised at all times, is not much of a big deal, but still it would be nicer if the password was cleared or even better never copied to the clipboard...
Which is why my idea would be to host Mozilla Sync Service in each AppVM and the let the dom0 browser fill this Sync Server with the passwords belonging to the corresponding identity...
> website: you will *not* open this link in the same AppVM but instead
> copy/paste it in your "Random surf" AppVM. Would this site be malicious
Yes but people WILL click the link. It's not a sane assumption to make. 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. Or even better, pipe it back to dom0 and open it in a new tab & AppVM under the right identity... (this kind of integration is what I am proposing)
> password database is to first hack the forum, and use it as a pivot to
> then be able to hack your computer and get access to your file system.
How he does it is basically immaterial to me as I assume that all AppVMs are evil all the time. The point is to separate them properly so only one identity gets compromised. I want to add that it is generally unlikely that a disposable AppVM with the right configuration will actually be compromised, but it helps to assume them to be to get a better picture of the impact it would have and to minimize that impact.
> (https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so
> Firefox does not dumbly automatically fill any password field without
Yes this looks good.
> like uMatrix or NoScript which allow to better control third-party
Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I imagined also to happen, just in dom0 (which is more trustworthy to me), not in an AppVM.
> It *may* be possible to implement a way to handle different AppVM in
> different tabs instead of different windows, but I'm not sure to see any
> real advantage of this.
The advantage is the same as going back to IE6 times when each tab was its own window and having windows with several tabs in addition to this madness. I don't see how you can not see the advantage of having all browser tabs over all AppVMs organized in a dom0 browser interface as tabs in comparison to having tons of floating windows with sub-tabs each ;).
> instance, personally I set it to not display reduced windows in the
> Alt-Tab menu, so I can focus on the window I am currently working with.
I don't think any of those suggestions really helps with the problem. All in all I think Qubes OS in general lacks a good UI for what it is doing, but I also understand that you have to start somewhere. But in the end the way Qubes does AppVM and identity management at the moment is truly terrible, but it works. All I want to do is to come up with a plan to improve it ^^.
> be useful to have them volatile on a day-to-day basis, and turn them
> non-volatile only to update Firefox's modules or save a change in its
I think the Mozilla Sync Server could be of help here...
> To be honest I did never investigated this, I'm not sure what the
> concrete threats there are.
Are you so sure that your AppVM doesn't have an unique fingerprint that potentially could be exposed via a malicious website, browser extension or the browser? In that case, even using the same base template for disposable VMs could be a privacy disaster (I am not sure Qubes OS has taken any steps, like maybe "Tails", to actually mitigate fingerprinting in disposable VMs)
On top of that have you ever tried to use Panopticlick? Even tails gets more or less uniquely fingerprinted primarily via the non-standard browser window size when it is maximized and also because it seems to apply some uncommon browser settings that maybe only tail users have...
> UUID you really should just use the same UUID as a lot of other people
That requires you to know the UUID, also UUID was more a token for "fingerprintable data", not to be taken literally.
> by using Qubes' bundled Whonix support: this will keep you blended in
> the crowd.
Yes but also dead slow :P. I was more thinking of using separate VPN services for each identity, or maybe even my own VPN server (NSA will likely still be able to cross reference, but at least not my ISP). I don't care much about NSA, since as I said before I am no target for them and the steps I take already make me pretty much invisible in the huge noise (besides mentioning them quite often :D). But I want to basically go "dark" when it comes to normal services and companies.
> Talking about missing features for web-browsing, I would love to see a
> plugin or a solution allowing to open a link in another designated AppVM
> (the "Random surf" VM or a disposable one) with just a right-click
That should be the simplest part of my proposal :D.
Cheers
Alex
> [...]
>> nor does this happen the other way around)
>
> Um, that is a bold statement, do you have any data to back that up?
> Maybe Amazon indeed doesn't talk to Facebook (yet), but no one is
> stopping them either. Facebook definitely has an interest to read
> your Amazon visits because this way they can link your true identity
> to your fake profile... for instance.
everywhere, and that's why I don't like to use it. Otherwise, beyond
compromising each and every client computer, I don't see how a
big-ass-company could pose the threat you try to shield against.
> [..let's skip the branded identity thing..]
>> every identity you use? second, once you realize that many
>> identities can co-exist (and indeed, sometimes you would like this
>> to happen) do you
>
> What do you mean by "co-exist"? If I use them at the same time in the
> same browser/VM I might as well just use one single identity because
> there is no way to know if either of them wasn't compromised or
> linked in ways I didn't want. I don't see how identities can co-exist
> (I am also not talking about sign-in data, I am talking about fake
> "me"'s, fake people so to speak who consume services to protect the
> real identity; I simply see no use case of why you ever want to share
> identities within the same AppVM or browser/site).
you are saying "there may exist a site which, compromising my AppVM,
gains intelligence on my identity on other sites". Which is a nice
assumption, and as me and Simon said, is exactly the meaning of AppVMs:
isolating failure. If I'm using a "dangerous" site or clicking a
"dangerous" link, I'd better use a different AppVM to make sure that any
malware infections I may encounter don't steal any sensitive data.
But then you propose to go full-nuclear on this threat model, arguing
that "every appvm is compromised" and "every website is malicious",
which I think are a little stretched tinfoil-hat assumptions.
While your proposal can technically be done, this does not automatically
create neither a threat model that fits the defense nor a compelling
reason to implement that.
Somebody, earlier this year, suggested to encrypt the image file of the
virtual hard disks of any AppVM; while this can technically be done, he
failed to provide a sound threat model this proposal would shield
against, because dom0 cannot be "telepiloted" into doing anything,
lacking networking, and having a standalone agent that does that many
things, with all the possible variables, is really really hard (and then
you have the cheaper thermorectal cryptanalysis). He did not account for
increased slowdown, which can already be felt with many AppVMs open
without single-machine encryption, and ultimately his proposal did not
gain traction.
I'd like you to reconsider your submission, better describing the threat
model you have in mind, so we (casual readers) can better understand why
we should sponsor your proposal.
Last, reading your answer to Simon's e-mail, I feel that a reasonable
incarnation for your threat model could be aggressive online
advertising; and I'm sorry to inform you that your proposal would not
protect against that, unless one uses a different TOR circuit for each
"dom0 browser tab", since big ad networks already track users without
any assumptions on the client, but by approximate ip geolocation, time
fingerprinting (both latency and time-of-day), and other techniques that
don't necessarily rely on client cooperation.
Does your proposal really harden agains a real threat, or is it
something that should be done only because it could be done?
Btw, thank you for taking the time to write us your proposal and
replying to our e-mails.
--
Alex
mara.k...@gmail.com
> something that should be done only because it could be done?
>
> Btw, thank you for taking the time to write us your proposal and
> replying to our e-mails.
Well honestly "proposal" is probably too much credit for the time I spent on it so far and I mainly wanted to probe for the idea more. I think I am going to write a true proposal that can actually be reviewed and your input definitely helps to guide that effort, which is also why I asked that question in the first place.
And I am not actually sure I will address a threat model, since it doesn't really do more than you can do manually. It is really more about regaining the convenience while maximizing the additional privacy and security Qubes OS technically provides, you see... But I agree that it is required to be much more specific and clear but I can't do that so quickly in a mail, so I will take this conversation and address the issues raised in a more structured manner ^^.
Thanks & Cheers
Chris Laprise
>> And that's why you can use many appVMs in the first place. You share the
> But that is not the point. First of all, unless your life depends on it, it will be very unlikely that you are actually paying enough attention to where you use which identity.
the website (because the "wrong" VM you're using doesn't have that
cookie/ID on file) should be a strong cue that you may be in the wrong
VM. Plus, Qubes is constantly displaying the VM name at the top of the
window... you should be checking it whenever you start a new activity.
OTOH, robust whitelisting (taking third-party sites into account) in
general would be a nice feature to have. But I'm thinking this needs to
be a browser-level feature, not OS-level, because the problem is mostly
specific to web browsing.
Chris
Simon
mara.k...@gmail.com wrote :
> Which is why my idea would be to host Mozilla Sync Service in each
> App
Firefox instances to either point to different Sync services or share
the same service but use different credential.
This way, you can ultimately prevent Firefox from having to store
anything locally : Firefox data goes to Sync, downloads you would like
to keep goes in your network-less storage AppVM, and everything in the
browsing AppVM gets wiped at each AppVM restart.
The only limitation for now, as I said in my previous email, is I don't
know a way to set an AppVM to use a volatile storage on a day-to-day
basis to enforce no modification to remain persistent between AppVM
restart except those explicitly allowed through Firefox Sync (and a
manual setting when one explicitly needs to modify it: update the
add-ons, save a new browser setting, etc.).
Using environments as much stateless as possible seems to be one of the
goal pursued by Qubes team if I understand their research documents
correctly, so even if it not possible right now (unless someone say it
is?) I guess sooner or later it will be.
> I am using UNIX pass, but it has the same flaw. If you copy passwords
> this way they won't automatically get purged from the AppVM, which
> under the assumption that any AppVM is completely compromised at all
> times, is not much of a big deal, but still it would be nicer if the
> password was cleared or even better never copied to the clipboard...
compared to other Qubes issues, but nevertheless a good point even if
from my point of view this could completely uncorrelated from your
tabbed AppVM idea.
What I understand from your sentence would be a feature like a keyboard
shortcut which, instead of putting the content of the global clipboard
into the AppVM clipboard as Ctrl+Shift-V currently does, would instead
simulate the keystrokes corresponding to the current global clipboard
content (a kind of macro).
> 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.
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.
> Thanks for uMatrix, I didn't know that one. But yes this is pretty
> much what I imagined also to happen, just in dom0 (which is more
> trustworthy to me), not in an AppVM.
neither the browser nor its AppVM, you may want to setup some web proxy
VM between your AppVM and the Firewall VM.
The same way the Firewall VM is configurable from Dom0, you could
imagine that the proxy could be configurable too to define a per-AppVM
white and black lists.
> The advantage is the same as going back to IE6 times when each tab was
> its own window and having windows with several tabs in addition to
> this madness. I don't see how you can not see the advantage of having
> all browser tabs over all AppVMs organized in a dom0 browser interface
> as tabs in comparison to having tons of floating windows with sub-tabs
> each ;).
windows belonging to different sensitivity levels to be clearly
separated from one another.
Have you looked toward tabbed windows managers? I do not know if there
is anything which would suit your needs, but their idea as per my
understanding is to handle several windows as tabs. This would however
put two tabs layer instead of one.
To be able to get one single layer of tabs, you would need to have the
browser itself and its rendering engine clearly separated, so you can
have the browser (with no Internet access) running in Dom0 handling
different rendering engine for each tabs, each being able to run in the
same or different tabs (the tab color would then help to distinguish
among the AppVM as windows border colors currently do).
Chrome used to rely on individual processes for each tab for a long time
now, AFAIK it is still an ongoing work on Firefox due to its history
(addon compatibility was a great issue). Nevertheless, even with this
basis in place I suspect this would still require a huge amount of work
to get such tight integration correctly done.
> All in all I think Qubes OS in general lacks a good UI for what it is
> doing, but I also understand that you have to start somewhere. But in
> the end the way Qubes does AppVM and identity management at the moment
> is truly terrible, but it works. All I want to do is to come up with a
> plan to improve it ^^.
so I do not expect it to offer the same level of sophistication than
more mature Linux distributions do.
Qubes goal is security, and in this domain it offers unique features
that those more mature ditros cannot offer, the rest will most certainly
come in its own time, I'm confident about this :)!
As for plans, I'm not involved in devs but there are some publicly
available information, like:
- Qubes OS usability and UX: https://www.qubes-os.org/doc/usability-ux/
- Qubes OS high-level roadmap:
https://github.com/rootkovska/qubes-roadmap
Qubes developers are not sleeping or wondering what to do ;), even if I
guess that new ideas and suggestions are always welcome.
> Are you so sure that your AppVM doesn't have an unique fingerprint
> that potentially could be exposed via a malicious website, browser
> extension or the browser?
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.
This does not apply however for other AppVMs, where if I'm not wrong
Firefox add-ons for instance gets assigned random UID upon installation.
Those IDs would allow to distinguish two otherwise identical AppVM, or
link two different AppVM running the same template. However the attacker
must have access to the file-system since, AFAIK, those ID are not
normally available to web pages scripts.
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
Be aware however that if you modify the Firefox bundled in your Tails
distro, it will then not be 100% identical to other people's Tails
browser. Depending on your actual threat this may be something you may
want to take into consideration.
> Yes but also dead slow :P. I was more thinking of...
Yes, security is always a matter of compromise :).
Regards,
Simon.
Alex
>> I am using UNIX pass, but it has the same flaw. If you copy passwords
>> this way they won't automatically get purged from the AppVM, which
>> under the assumption that any AppVM is completely compromised at all
>> times, is not much of a big deal, but still it would be nicer if the
>> password was cleared or even better never copied to the clipboard...
>
> I think this may be a good point, maybe not of the highest priority
> compared to other Qubes issues, but nevertheless a good point even if
> from my point of view this could completely uncorrelated from your
> tabbed AppVM idea.
>
> What I understand from your sentence would be a feature like a keyboard
> shortcut which, instead of putting the content of the global clipboard
> into the AppVM clipboard as Ctrl+Shift-V currently does, would instead
> simulate the keystrokes corresponding to the current global clipboard
> content (a kind of macro).
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 ;)
>
>> 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.
>
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.
>> The advantage is the same as going back to IE6 times when each tab was
>> its own window and having windows with several tabs in addition to
>> this madness. I don't see how you can not see the advantage of having
>> all browser tabs over all AppVMs organized in a dom0 browser interface
>> as tabs in comparison to having tons of floating windows with sub-tabs
>> each ;).
>
> I suppose everyone have their own taste ;). Personally, I prefer to have
> windows belonging to different sensitivity levels to be clearly
> separated from one another.
>
> Have you looked toward tabbed windows managers? I do not know if there
> is anything which would suit your needs, but their idea as per my
> understanding is to handle several windows as tabs. This would however
> put two tabs layer instead of one.
vertical-split layout; all the others are tabbed, and it works great. It
may well emulate the concept of "dom0 browser".
>> Are you so sure that your AppVM doesn't have an unique fingerprint
>> that potentially could be exposed via a malicious website, browser
>> extension or the browser?
>
> 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.
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.
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.
>
> 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
that my browser from this AppVM I'm replying from is unique among the
~170K browsers panopticlick has ever tested. Yay! From what I can see,
WebGL + canvas + fonts are the main conveyors of uniqueness bits, but I
cannot easily disable them without severely compromising my browsing
experience.
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
--
Alex
Simon
Alex 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 ;)
>
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).
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".
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.
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.
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.
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
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.
Alex
> 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?
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).
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".
> [...]
> 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.
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.
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!
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 :).
>> 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 hypothesis of protecting from tracking, which would ultimately be
not worth the effort.
--
Alex
Tai...@gmx.com
as they all have the same browser fingerprint.
Micah Lee
> FYI: Having different VM's using the same template doesn't really matter
> as they all have the same browser fingerprint.
Tor Browser. Other browsers don't attempt to hide your browser
fingerprint, especially the most fingerprintable part, your IP address.
But browser fingerprinting isn't many people's primary concern, I think.
I use browsers in separate AppVMs for compartmentalization. So if one
browser gets compromised (or if a website uses css tricks to guess my
browser history, etc.), the attacker won't be able to obtain any
information about what's going on in browsers in other AppVMs.