[PATCH] TorVM implementation

[Abel Luck]

Hi folks,

My qubes-tor service is ready for review. As Joanna suggested, I've
pushed it to a git repo.

Source:
https://github.com/abeluck/qubes-addons/commit/060b04871fd5f4f0faf40e7c7c5d55aa313387fa

Documentation:
https://github.com/abeluck/qubes-addons/blob/master/qubes-tor/README.md

To build it:
I'm not sure quite how to integrate my addons repo into qubes-builder,
so I suggest checking out the repo then copying my changes over:

$ rsync -a qubes-addons/* /path/to/qubes-builder/qubes-src/addons/
$ cd /path/to/qubes-builder/qubes-src/addons/
$ make rpms_tor

The rpms will be in rpm/x64/qubes-tor*.rpm, where you can copy the to
your templatevm.

Eagerly awaiting feedback, cheers,

~abel

(public key attached to this message)

[Hakisho Nukama]

Hi Abel,

nice work so far, thanks!

Would you advice to use a separate template for your AppVMs which uses
TorVM as a NetVM (one template per anonymous identity)?

My concern is about linking nicely separated domains with some kind of
fingerprinting, be it through browser uniqueness or list of installed packages
on a *common* template.

Prerequisite are:
- common template of identity exposing VM (banking, work) and anonweb
- compromise anonweb and banking/work VM or
- active/passive fingerprint gathered from both browsers

If work, personal, untrusted and anonweb VMs are based on a common
template a leak of both lists of installed applications and their
versions could link your identity from you trusted VM to your anonweb VM.

Browser uniqueness: Is it only different in qubes_ip and hostname
(maybe profile-path) on both AppVMs sharing a common template?

Qubes_IP isn't assigned randomly at VM start. Depending on behaviour
this could lead to same IP for anonweb after each restart, which might be
unique for a system.

Best Regards.
Hakisho Nukama

[Marek Marczykowski]

Actually qubes_ip is assigned at VM creation time. But it isn't unique for
system - actually every Qubes installation will use the same IPs for its VMs.
So this can be used to say "this is Qubes", but not identify specific user.
Anyway fact of using Qubes is quite unique...

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Marek Marczykowski]

On 13.10.2012 18:23, Abel Luck wrote:
> Hi folks,
>
> My qubes-tor service is ready for review. As Joanna suggested, I've
> pushed it to a git repo.
>
> Source:
> https://github.com/abeluck/qubes-addons/commit/060b04871fd5f4f0faf40e7c7c5d55aa313387fa
>
> Documentation:
> https://github.com/abeluck/qubes-addons/blob/master/qubes-tor/README.md
>
> To build it:
> I'm not sure quite how to integrate my addons repo into qubes-builder,
> so I suggest checking out the repo then copying my changes over:
>
> $ rsync -a qubes-addons/* /path/to/qubes-builder/qubes-src/addons/
> $ cd /path/to/qubes-builder/qubes-src/addons/
> $ make rpms_tor

You've made changes exactly as it should be :) So instead of rsync it can be
"git pull" (or fetch + checkout) and then "make addons" from qubes-builder dir.

> The rpms will be in rpm/x64/qubes-tor*.rpm, where you can copy the to
> your templatevm.
>
> Eagerly awaiting feedback, cheers,

I've reviewed the code, everything looks good :)
Merged into my master branch. Also I've uploaded ready packages into
"unstable" yum repository. Docs (copied from README.md, with a little update
in installation instructions):
http://wiki.qubes-os.org/trac/wiki/UserDoc/TorVM

Again, many thanks!

[Abel Luck]

Hakisho Nukama:

> On Sat, Oct 13, 2012 at 4:23 PM, Abel Luck <ab...@guardianproject.info> wrote:
>> Hi folks,
>>
>> My qubes-tor service is ready for review. As Joanna suggested, I've
>> pushed it to a git repo.
>>
>> Source:
>> https://github.com/abeluck/qubes-addons/commit/060b04871fd5f4f0faf40e7c7c5d55aa313387fa
>>
>> Documentation:
>> https://github.com/abeluck/qubes-addons/blob/master/qubes-tor/README.md
>>
>> To build it:
>> I'm not sure quite how to integrate my addons repo into qubes-builder,
>> so I suggest checking out the repo then copying my changes over:
>>
>> $ rsync -a qubes-addons/* /path/to/qubes-builder/qubes-src/addons/
>> $ cd /path/to/qubes-builder/qubes-src/addons/
>> $ make rpms_tor
>>
>> The rpms will be in rpm/x64/qubes-tor*.rpm, where you can copy the to
>> your templatevm.
>>
>> Eagerly awaiting feedback, cheers,
>>
>> ~abel
>>
>> (public key attached to this message)
>
> Hi Abel,
>
> nice work so far, thanks!
>

Thank you, though I haven't done much more than packaging for Qubes the
already great work others have done.

> Would you advice to use a separate template for your AppVMs which uses
> TorVM as a NetVM (one template per anonymous identity)?
>

I use a separate template for my Net+ProxyVMs, than my normal AppVMs.

> My concern is about linking nicely separated domains with some kind of
> fingerprinting, be it through browser uniqueness or list of installed packages
> on a *common* template.
>
> Prerequisite are:
> - common template of identity exposing VM (banking, work) and anonweb
> - compromise anonweb and banking/work VM or
> - active/passive fingerprint gathered from both browsers
>
> If work, personal, untrusted and anonweb VMs are based on a common
> template a leak of both lists of installed applications and their
> versions could link your identity from you trusted VM to your anonweb VM.
>

As for separate templates for AnonVMS and AppVms, it isn't a bad idea
necessarily. The system fingerprinting your talking about is definitely
possible. If you can spare the HD space, I would not advise against it.

But, like Marek said, the act of using Qubes in and of itself is unique
and likely will be for some time.

> Browser uniqueness: Is it only different in qubes_ip and hostname
> (maybe profile-path) on both AppVMs sharing a common template?
>

If this is a concern for you, it is *essential* that you use TorBrowser
and **NOT** vanilla firefox from your AnonVMs. The Tor project has put
much effort into ensuring the TBB footprint is the same for all users,
and it will only get better.

Of course the TBB uses its own tor, which is undesirable (tor-within-tor
is bad). Attached to this email is a launcher for the TBB that bypasses
the bundled Tor and Vidalia. Be careful with it. (Note, the torbutton's
"new identity" doesn't work).

~abel

[Abel Luck]

Marek Marczykowski:

> On 13.10.2012 18:23, Abel Luck wrote:
>> Hi folks,
>>
>> My qubes-tor service is ready for review. As Joanna suggested, I've
>> pushed it to a git repo.
>>
>> Source:
>> https://github.com/abeluck/qubes-addons/commit/060b04871fd5f4f0faf40e7c7c5d55aa313387fa
>>
>> Documentation:
>> https://github.com/abeluck/qubes-addons/blob/master/qubes-tor/README.md
>>
>> To build it:
>> I'm not sure quite how to integrate my addons repo into qubes-builder,
>> so I suggest checking out the repo then copying my changes over:
>>
>> $ rsync -a qubes-addons/* /path/to/qubes-builder/qubes-src/addons/
>> $ cd /path/to/qubes-builder/qubes-src/addons/
>> $ make rpms_tor
>
> You've made changes exactly as it should be :) So instead of rsync it can be
> "git pull" (or fetch + checkout) and then "make addons" from qubes-builder dir.
>

Oy, of course. In fact I added my addons repo as a remote in
qubes-builder/qubes-src/addons with

$ git remote add abel my_repo_uri

>> The rpms will be in rpm/x64/qubes-tor*.rpm, where you can copy the to
>> your templatevm.
>>
>> Eagerly awaiting feedback, cheers,
>
> I've reviewed the code, everything looks good :)
> Merged into my master branch. Also I've uploaded ready packages into
> "unstable" yum repository. Docs (copied from README.md, with a little update
> in installation instructions):
> http://wiki.qubes-os.org/trac/wiki/UserDoc/TorVM
>
> Again, many thanks!
>

Thanks for merging so quick. There are some issues I need to resolve
quickly, in particular a version of TorBrowser.

I'll ping when updates are ready.

[Abel Luck]

ba1...@yahoo.de:

> Nice work Abel - i thank you
>
> I'm new to Qubes and i test it for a week now and i like it very much
>
> it was hard to add your chaanges to my system ...

Did you install the packages from 'unstable' ?

> it worked only after i
> had given the standard template DNS and Net Access and disabling the Yum
> Proxy.... and deinstalling the tor version i had installed before
>

That shouldn't be necessary at all. The default template firewall
settings (disallow all except update proxy) works fine. There should be
no reason to change the template firewall settings.

Can you describe the error?


> however I'd like to have an Debian Template....

Can't help you here sorry..

>
> and add some repos esp EPEL and RPMfusion to add some more pkgs

You can add that yourself in /etc/yum.repo.d/

>
> Qubes is great
>
Hear hear!

[al qubes]

 
Did you install the packages from 'unstable' ?

Yes

 

> it worked only after i
> had given the standard template DNS and Net Access and disabling the Yum
> Proxy.... and deinstalling the tor version i had installed before
>

That shouldn't be necessary at all. The default template firewall
settings (disallow all except update proxy) works fine. There should be
no reason to change the template firewall settings.

no the firewall setting of the default fedora template

 

Can you describe the error?

no resolving etc  

> however I'd like to have an Debian Template....

Can't help you here sorry..

>
> and add some repos esp EPEL and RPMfusion to add some more pkgs

You can add that yourself in /etc/yum.repo.d/

i added them but they don't work - i suspect the proxy is filtering them  

[Marek Marczykowski]

On 16.10.2012 17:04, al qubes wrote:
>
>>
>>
>> Did you install the packages from 'unstable' ?
>>
>> Yes
>
>
>>> it worked only after i
>>> had given the standard template DNS and Net Access and disabling the Yum
>>> Proxy.... and deinstalling the tor version i had installed before
>>>
>>
>> That shouldn't be necessary at all. The default template firewall
>> settings (disallow all except update proxy) works fine. There should be
>> no reason to change the template firewall settings.
>>
> no the firewall setting of the default fedora template
>
>
>> Can you describe the error?
>>
> no resolving etc

I suspect you've set up tor proxy for TemplateVm, in which case update proxy
isn't available (it is on your netvm, not in Tor network). You should use
separate ProxyVM for tor and attach only some of AppVMs to it (especially not
TemplateVM...).

[Juergen Schinker]

yeah i got it now and added the repos that i want ...i added them to the default template

I run in to other Problems:

i want to stream Miro contetn through their sharing feature - netatalk or bonjour or mDNS whatever ...well it doesn.t work

Bluettoth also doesn't work although i added the whole PCI controller to netvm and chgrp user /dev/rfkill etc - i don't get the Bluetooth Button !

Cheers

Juergen

[Marek Marczykowski]

On 18.10.2012 15:33, Juergen Schinker wrote:
> yeah i got it now and added the repos that i want ...i added them to the default template
>
> I run in to other Problems:
>
> i want to stream Miro contetn through their sharing feature - netatalk or bonjour or mDNS whatever ...well it doesn.t work

All of above protocols are using broadcast/multicast which isn't routed. It
should be possible to use them in netvm, but this is rather nasty workaround
than long term solution. On the other hand, routing multicast isn't trivial
task, so I don't suspect to have it done in QUbes anytime soon...

> Bluettoth also doesn't work although i added the whole PCI controller to netvm and chgrp user /dev/rfkill etc - i don't get the Bluetooth Button !

Try to start "bluetooth-applet" manually - AFAIR it isn't enabled by default.
If this is the case, you can enable it by copying
/etc/xdg/autostart/bluetooth-applet.desktop to ~/.config/autostart (create dir
if necessary) and add "QUBES" to OnlyShowIn= entry in this file.

[Marek Marczykowski]

On 19.10.2012 10:31, Juergen Schinker wrote:
> Thanks
>
> that raises an interesting question : What Traffic is being routed and which not?

Every traffic that can be *routed* (and NATed), of course respecting per-VM
firewall settings (default for AppVM is "allow all"). Only outgoing
connections are allowed.
Actually broadcasts and mulicasts can't be routed in standard network.

> regarding Bluettooth as user "user" or as root ?

user.

>I've set it up and now i have a working Bluettooth mouse in netvm but not in
others vm huh

If you connect mouse to netvm it isn't surprising that it isn't working in
other VMs... To have input device for all VMs, it must be connected to dom0.
Of course exposing dom0 to bluetooth traffic is huge security hole, so my
suggestion is... do not use bluetooth mouse. Not only for that Qubes-specific
reason, but also to not allow sniffing (and possible hijacking) your mouse
activity.

> I really think there should be a Tips and Tricks Segment in the wiki....

I'm trying to add links to interesting messages on the list to the "User doc"
section.