Re: [Tails-dev] Sandboxing Tor Browser: strategy for trackin…

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The Tails public development discussion list
Assumpte: Re: [Tails-dev] Sandboxing Tor Browser: strategy for tracking "upstream" AppArmor profile
On 23/01/15 20:50, intrigeri wrote:
> Hi,
>
> I'm working on #5525 ("Sandbox the web browser"), and have an AppArmor
> profile that works locally for most basic use cases. Now, I'm
> wondering how to integrate it into Tails and I need your input.
>
> This profile was derived from the one I've worked a lot on for
> torbrowser-launcher (https://micahflee.com/torbrowser-launcher/).
>
> I think we have two solutions:
>
>    1. Download "upstream" profile and apply Tails-specific patch at
>       ISO build time

>
>    2. Ship a forked profile in our Git repository

>
> (And no, there's no "3. Upstream our changes" given how our different
> our Tor Browser installation is from standard ones. About 20% of our
> changes could be made configurable upstream with tunables, but given
> it's only 20%, I don't think it's worth the added complexity.)
>
> #1 has the advantages that we get upstream improvements for free,
> and we're forced to track upstream, and to adjust our own patch
> whenever needed: otherwise, Tails ISO build fails.
>
> #2 has the advantage that the Tails build won't ever fail due to
> upstream changes. But our Tor Browser may break at runtime because we
> failed to integrate upstream changes in their AppArmor profile.
>
> From my point of view, #1 feels cleaner: it forces us to do the right
> thing wrt. upstream, and it fails earlier (at build time).


While I appreciate #1 forcing us to track upstream, I think these build
failures that depend on things external to Tails (e.g. fetching from APT
repos outside of our control) are quite problematic:

* They further complicate things for potential Tails contributors and
adds the impression that Tails building is a fragile black art
(rightfully so, actually!).

* I worry that excessive build failure notifications will result in some
kind of "the boy who cried wolf" syndrome for us, or at least that they
become a nuisance we tend to ignore or delay, instead of something we
appreciate.

IMHO we already expose ourselves too much to these kind of externally
triggered build issues, and without a 24/7 on call developer that will
fix them ASAP, I think we need less of them, not more.

Besides, we already require manual intervention for upgrading the Tor
Browser, so why not adding "upgrade the apparmor profile" to those
instructions? Of course, we generally upgrade the Tor Browser *very*
late in the release process, so if an issue arise it becomes a quite
serious blocker, but #1 wouldn't catch all such issues any way, e.g.
those introduced by such a new Tor Browser release.

Just some food for thought for now. Personally I'm not at all sure which
approach is the best.

Cheers!