Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howt…

Delete this message

Reply to this message
Autore: adev
Data:  
To: tails-dev
Nuovi argomenti: [Tails-dev] VirtualBox host software vs. networking [Was: Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer]
Oggetto: Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer
> 29/10/12 19:54, adev@??? wrote:
>
>>> IIRC, VirtualBox host software sets iptables/netfilter up in a way
>>> that makes the guest system bypass the existing firewall / or be
>>> blocked by it, so some care should be taken on this side.
>>
>> One idea is to use host-only networking in the virtualbox guest, and the
>> apps in the guest can connect to appropriate socks-port(s) on the hosts
>> host-only adapter
>
> Sure, a host-only adapter probably make this easier than the bridged
> setup described in the link.


And more secure




>> Bridge mode is the problem, it would be worth checking if the amnesia
>> user
>> can leverage the virtualbox bridge kernel module/driver to bypass tor.
>> This would violate tails design because currently the amnesia user is
>> not
>> allowed direct internet access.
>
> This is interesting and certainly needs to be investigated further
> (added to todo item). My initial testing shows that, indeed, bridged
> adapters bypass the host's firewall.



I suspect that the answer is Yes, by default the amnesia user can use the
bridge adapter to bypass the host firewall, unless we do something to stop
this



>> Bridge mode and NAT support could simply be left out alltogether from
>> tails, any drivers deleted/not-installed
>
> Allowing NAT is at least not a leaking-related problem since the NAT:ed
> traffic appears "normally" in the host OS, so in Tails it will be caught
> by the firewall.
>
>> If the kernel modules for bridge and NAT adapters is left out of tails,
>> that would leave only the host-only networking adapter.
>
> vboxnetflt is used for bridged adapters, but host-only adapters requries
> *both* vboxnetadp and vboxnetflt to be loaded.



That is unfortunate, I'm sure we'll think of some way to fix the problem
though