29/10/12 19:41, adev@??? wrote:
>> I did this from a fresh Tails session:
>>
>> sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc-4.6
>> sudo apt-get update
>> sudo apt-get install --yes linux-headers-686-pae virtualbox-dkms \
>> virtualbox-qt
>> vboxmanage createvm --name Tails --ostype Debian --register
>> vboxmanage modifyvm Tails --memory 1024
>> vboxmanage storagectl Tails --name SATA0 --add sata \
>> --controller IntelAHCI
>> vboxmanage storageattach Tails --storagectl SATA0 --port 0 \
>> --device 0 --type dvddrive --medium host:/dev/cdrom
>> vboxmanage startvm Tails
>>
>> And then Tails starts as a guest within Tails, using the same boot
>> media (there's no need to copy in the image to ram like you did).
>
> This would be great for Tails as we can use vboxmanage to modify the
> virtual tails as needed. I dont see Tails copying any ISO or filesystem
> into RAM anytime soon (and booting the VM from that), it does have high
> performance though compared to using the CD but really isnt necessary?
Sorry, but I don't understand what you mean here.
>> Actually the Tails host I did this from was itself a VirtualBox guest,
>> so it also shows that nested VMs work, but the nested-guest is slooow.
>
> How slow? Unusably slow? Would Tails need to do something different to
> ship a virtualized tails solution?
Well, about as slow as running from DVD I'd say. It's mostly booting it
up that takes time.
> I havent tested using virtual tails from the same mechanical optical disk
> yet.
Me neither. But as long as the host has booted completely, there
shouldn't be much competition between the host and guest to read from
the media.
>>> * Allows stronger enforcement of tor-only connections, an attacker must
>>> break out of a virtual machine, in addition to previous steps taken. A
>>> VM
>>> can be configured to only be able to send traffic through the tor
>>> process
>>> running on the host machine.
>>
>> Sure, but to configure the applications in the guest to use the host's
>> Tor is non-trivial for most users (and would require us to make Tor's
>> ports listen on more than localhost). I'd like a way so a whole VM is
>> Torified without additional configuration inside the VM. Here's some an
>> article one can find inspiration from:
>>
>> <http://www.howtoforge.com/how-to-set-up-a-tor-middlebox-routing-all-virtualbox-virtual-machine-traffic-over-the-tor-network>
>
> I can see the low effort maintainability goal, and it could be quicker and
> easier to ship a virtualized tails that virtualises the entire VM, and
> maybe think about individual app & firewall configuration later
>
> However I do note that currently the firewall has per application rules,
> and some apps have stream isolation, how much work would it be to have a
> slightly different firewall configuration, and tell the apps to use the
> same socks port, but vbox.guest.hostadapter.ip instead of localhost?
>
> It would also need the bootmagic to be able to control which firewall
> script gets loaded
Exactly. We are talking about two different use cases, which are (1) and
(2) in what you outline below:
>>> * Enables the features described at
>>> https://tails.boum.org/todo/Two-layered_virtualized_system/
>>
>> Needless to say, including Virtualbox host software in Tails is only a
>> small step on the way to the above. There's still a lot of work left to
>> achieve it in a user-friendly way (i.e. zero user configuration).
>
> Yes a small step along the way. A shipped virtualbox might get more people
> to start testing virtualization in tails.
>
>
> I see some use cases here:
>
> (1) User wants an entire $any VM to be torified, this VM is not
> necessarily tails. They load they VM and the entire VM is torified through
> one socks port. Then they can run their $random windows app
>
>
> (2) Tails livecd IS the guest VM. Existing apps have exactly the same
> stream isolation because the tails guest apps are preconfigured to connect
> to vboxguest.hostadapter.ip:socksport
>
> This does seem like alot of work, getting all the DNS reconfigured,
> virtual tails does look like it has alot of issues to be ironed out
I'm not sure it has to be so complicated. In the Tails guest
('app-guest' in my "design" below) we could use firewall rules to
redirect all traffic to the relevant local ports to the corresponding
ports on the Tails host (or 'tor-guest'). Or set up `socat` instances
that listens on e.g. port 9050 in the guest and forward them to port
9050 on the host (or 'tor-guest'). We could even write a short script
that runs in the Tails guest ('app-guest') and scans torrc for all
*Port:s and sets up the redirection accordingly.
Any sort of re-configuration is easy as long as it's Tails we're dealing
with. But for an arbitrary OS the best we can do is to Torify the whole
VM from the Tails host.
>> One interesting thing to note, though, is that the host can start
>> several guests using the same boot media in the way I described above.
>> Hence we could add some kind of hook during Tails' boot process that,
>> depending on some "magic" parameter set by the host (if any), makes
>> Tails boot into specialized profiles (e.g. one that only runs Tor and
>> one that runs the GUI stuff). For instance:
>>
>> * tor-guest: Boot Tails into a minimal mode (no Xorg etc.) that just:
>> - starts Tor with all its ports listening on the network.
>> - sets an appropriate firewall (only allow inbound traffic from the
>> 'app-guest' vm (see below) to Tor's ports, and only the outbound
>> traffic made by Tor).
>> * i2p-guest: Same as 'tor-guest' but adapted for i2p.
>> * app-guest: Boot Tails exactly like it's done now except:
>> - it uses the Tor instance running on 'tor-guest' vm.
>> - sets an appropriate firewall (only allow connections to the
>> 'tor-guest' and 'i2p-guest' vms)
> Like!
>
>
>>
>> If no such profile is set Tails boots normally. In Tails Greeter we add
>> an option called "Use isolation through virtualization" (or similar)
>> that when set:
>>
>> 1. Continues from Tails Greeter to a simple X screen (no GNOME etc.
>> running; only vms are supposed to be run from the host from now on).
>> 2. Starts a Tails guest with the 'tor-guest' parameter in headless
>> mode. (not sure about the 'i2p-guest' yet since it should start
>> automatically)
>> 3. Starts a Tails guest with the 'app-guest' parameter in fullscreen
>> mode. This is where the user should interact with Tails from now on.
>>
>> Relevant settings from Tails Greeter on the host must be forwarded to
>> these guests appropriately, e.g. persistent Tor data dir to 'tor-guest'
>> and all other persistent directories to 'app-guest' (using VirtualBox'
>> shared directories, I guess), and the language settings should be set in
>> 'app-guest' etc.
>>
>> A fine question, though, is whether there exist something like this
>> "magical" parameter I talk about above in VirtualBox. The simplest
>> would be if Virtualbox could add stuff to the kernel commandline, but I
>> doubt that is possible in any sane way. More likely something can be
>> achieved through the guest additions. It seems like the host can execute
>> arbitrary commands on guests using `vboxmanage guestcontrol execute`,
>> which could be used to alter how Tails boots from then on.
>>
>> Are you interested in investigating this?
>
> Not that interested but I will work it out if it helps
>
> So we need the tails virtualbox guest to receive a message or a flag, set
> by the tails host. This message needs to be received as early as possible
> so that the tails guest knows how it is supposed to configure itself
Exactly.
> Yes I think I can work this out, give me some time and I will research it
Excellent! I'm looking forward to hear about your findings.
Cheers!
