If we want Tails host and guest VM to share the same image, we need to figure out a means to get the VM running without loading Tor and having applications reference the http proxy as well as other anonymity components, such as ttdnsd (Tor DNS daemon). This isn't an easy task as there are many means by which Tails works in order to prevent accidental leakage. So I've been thinking about two possible mechanisms for making this happen:
- Use a union file system whiting out network.d scripts, rc.d scripts, and configs scripts as necessary, as well as replacing config scripts where possible - Make a snapshot of the /etc directory prior to executing any of the config/chroot_local-hooks and use that within the VM Neither of these are ideal. The first will create a monolithic file containing information from many of the different setup files in config, the latter might exclude something that actually offers utility for even the VM. Another, two much more complex approach would be: - In each file, have flags that specify if these are VM actions, host actions, or both (I don't know how exactly this would work, but there should be some means of doing this) - Have a duplicate set of config files for the VM Cheers, David On Sun, Dec 29, 2013 at 1:11 AM, David Wolinsky <isaac.wolin...@gmail.com>wrote: > > > > On Wed, Dec 25, 2013 at 3:56 PM, intrigeri <intrig...@boum.org> wrote: > >> Hi, >> >> David Wolinsky wrote (19 Dec 2013 03:14:39 GMT) : >> > I want to start working on integrating the of Pseudonymity as >> > defined by WiNoN into Tails. >> >> I'm very happy to see someone work on this. >> >> > To do this I propose the following: >> >> > - In the host, we run redsocks (http://darkk.net.ru/redsocks/), this >> will >> > pick up traffic from the VMs and redirect it to Tor. >> >> I have a few questions here: >> >> - Is Tor running on the host system, or inside a dedicated VM? >> >> The latter would have the benefit of making it hard for >> a compromised Tor client to gather information about the local >> networking setup, hardware identifiers, etc. I guess going with the >> former is easier to implement as a first iteration, and I'd like to >> see a working first iteration ASAP, so I guess it totally makes >> sense to postpone this for now. >> >> - How does this play with our stream isolation design [1]? >> In other words, what kind of SocksPort(s), with what stream >> isolation options, would the TCP traffic be redirected to? >> >> I could probably take "once we segregate each pseudonym into its own >> VM, we don't care anymore" for an answer, but I've not thought this >> through yet. >> >> [1] https://tails.boum.org/contribute/design/stream_isolation/ >> >> This is an interesting point. It may be totally reasonable to apply the > same rules as Iceweasel on a per-VM basis, once we move to that phase. > Without multi-vms and no vm introspection, I imagine the most desirable > approach would be to use a stricter, less performance oriented isolation > policy. > > Actually I went through Tails in more depth recently, since posting this > message, and it seems we don't really need a unique SocksPort for each VM, > but rather just direct it to the appropriate SocksPort for the correct > level of isolation desired. > >> > Currently there exists no package for redsocks in Squeeze, should >> > we check to see if the Wheezy package works or just build our own >> > Redsocks package? >> >> Replied in the dedicated thread you started about it. >> >> > - Install the necessary software for both LXC and KVM >> >> I understand you decided to go with KVM only for now, and I think it >> totally makes sense. The state of the LXC userspace doesn't look very >> good yet, and it's still unclear to me how strong it is nowadays >> against a root compromise of the guest (enterprisey distros who >> currently ship solutions based on LXC only dare doing so with >> additional safeguards such as SELinux and AppArmor). >> > Right, this may be something we just keep in house for experimenting due > to these reasons. > >> >> > - Give amnesia the right sudo abilities to start LXC and KVM >> >> I bet this will have to be a bit finer grained than this, but I see >> what you mean :) >> >> > - Add start LXC Pseudonym and KVM Pseudonym to the desktop >> >> What system would be started by these launchers? >> Another full-blown Tails, or something else? >> >> If Tails, what difficulties do you expect to face, in other words, how >> should the Pseudonym-Tails differ from a "standard" one? I guess we >> could brainstorm it a bit to start with. E.g. do we want the user to >> be shown Tails Greeter? Or do we want to forward (some of) the user's >> choices into the Pseudonym-Tails, such as language and keyboard layout >> settings? We can also probably postpone this to when something simple >> and working is ready to be tested, your call :) >> > This is my current "research" task. In our winon prototype, we use a > single root disk image intended for the host and then use a stackable file > system (aufs) to mask or enable features for guests that deviate from the > host. The idea being that the guest should be a simple system with no > knowledge of Tor (and other Tails services) and just appear to be connected > to a NAT. For the actual mask file system, we use something called Virtfs > that is similar to shared directories for virtualbox. So that the guest > just mounts a directory from the host as its mask layer. This would then > contain whatever necessary to prevent many of the tails securing services > to be running in the guest. One favor I ask of you is if you could point me > to some documentation that enumerates what all this might be. A second > favor, how do you feel about our method? Do you have an alternative method? > Ideally, this would be self-maintaining or require a minimal amount of > effort. > >> >> > - Upon starting a Pseudonym, we'll add a Tap device and connect it to a >> > bridge, where redsocks will pick up the traffic. For each pseudonym, >> we'll >> > run a unique redsocks instance and start a new Tor proxy socket. >> > - We can either a pseudonym watcher to clean up state or just run the >> > pseudonym in a script, blocking on the VM execution. When the VM has >> been >> > closed, it is automatically cleaned up. >> > - Use IP Tables to enforce communication between the pseudonyms and Tor >> > In this instance, each pseudonym will have a unique IP address, but it >> will >> > only be able to talk to Tor running via the bridge and not other >> pseudonyms. >> >> OK. >> >> > Call this round 1, and we'll add more details as we discuss. >> >> Looks good for round 1 :) >> >> Cheers, >> -- >> intrigeri >> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc >> | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc >> _______________________________________________ >> tails-dev mailing list >> tails-dev@boum.org >> https://mailman.boum.org/listinfo/tails-dev >> > >
_______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
