[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] TBB, iptables, and seperation of concerns



> Hi,
>
> Chris wrote (12 Dec 2011 08:35:01 GMT) :
>
>> 1. A user should not have to download a CD from a site every time an
>> update comes out.
>
> What kind of better solution are you thinking of?
>
> We've got an incremental upgrade system in the works:
>    https://tails.boum.org/todo/usb_install_and_upgrade/#index5h2
>
> Don't hesitate using the Tails communication channels to suggest
> improvements etc.

I think a solution with AUFS would make more sense. While there are some
benefits initially to doing it with squashfs the compression gained is
quickly overtaken by the amount of disk space this will eat up. Using AUFS
with a read-only mode would be the better way to do it. There would be
nothing left on the disk after a reboot (except for any encryption
partitions which were mounted read/write) and users could still update the
software through normal channels (apt).

>
>> 2. Users should not need to know how to authenticate the download (each
>> update to TBB or Tails)- while nice users aren't competent enough to do
>> in
>> practice and the difficult in doing it makes it unlikely even those who
>> know how may not do it. So we should avoid making the user do the
>> authentication at all.
>
>> That can be done if there is a distribution that is installed.
>> Authentication of updates is already built into apt. Lets use it.
>> Install once and forget.
>
> I may be missing your point, but Tails is not a random collection of
> packages that could be individually upgraded without any thought.
> Tails is a carefully crafted system that aims at guaranteeing certain
> properties. We do our best to ensure an ISO we ship meets a certain
> specification. There is simply no possible way for us to ensure the
> same for "that ISO plus any number of APT upgrades on top of it".
>
> Details:
>    https://tails.boum.org/forum/Security_Updates:_apt-get_Sufficient__63__/#comment-ee6b87ae9397f6a9045f6c77fb52272d
>

"which doesn't happen in the Tails' context." < from the above page

I may not fully understand the problem here as it is not well explained.
If I take an educated guess at where the problem lies I think it is
nothing that can't be overcome. The "tails context" is a design issue and
not something that can't be overcome. I believe the issue is mainly that
Tails runs from a CD and if installed is using squashfs. Thus it can't be
updated (except each time the system is booted, and even then some updates
require a reboot, at which point those updates are lost).

A few things need to be made and would need coordination with other
related projects:

1. Tails switches from squashfs to AUFS with two modes of operation, one
being read-only, and the other being for updating with apt. It is easy to
prove nothing is leaked to disk with this change.

2. A version of the TBB is released via the Tor repository where this
version has apparmor applied around Firefox and Tor runs as a separate
user.

The Tor user (and apt) should be the only users which have access to the
Internet. This would mean users can't accidently leak anything. DNS,
accidentally printing a sensitive document, or similar.

Users would lose anything not saved to an encrypted disk on reboot. The
same thing that happens now. If an update was detected the system could be
remounted in read/write mode for apt and then rebooted. Since updating
occurs before the encrypted partition is mounted there is no risk of
writing data to the unencrypted portion of the disk.

>> 3. Does tails prevent non-Tor communications? I was reading something
>> which suggested it was an idea. If it is an idea chances are it isn't
>> implemented.
>
> It does. Details:
>
>    https://tails.boum.org/about/
>    https://tails.boum.org/contribute/design/
>

Great. So there is a proper firewall.

> Cheers,
> --
>   intrigeri <intrigeri@xxxxxxxx>
>   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
>   | The impossible just takes a bit longer.
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>


_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk