On Wed, Dec 25, 2013 at 3:56 PM, intrigeri <intrigeri@???> 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@???
> https://mailman.boum.org/listinfo/tails-dev
>
