[tbb-dev] So, about the Linux sandbox in the long term?

[Georg Koppen]

Yawning Angel:
> On Sat, 27 May 2017 12:27:21 +0200
> intrigeri <intrigeri at boum.org> wrote:
>> With Micah Lee's Tor Browser Launcher (TBL) on Linux with AppArmor
>> enabled, this is not a problem: the sandboxing is done by the kernel
>> and thus different confinement rules can be (and actually are) applied
>> to the Firefox and Tor processes.
> 
> Quickly skimming the firefox profile included in TBL, does `network
> tcp,` do what I think it does?
> 
> The differences in approaches, IMO, is totally irrelevant to "does
> there need to be fundamental architectural changes" since:
> 
>  * There's nothing preventing anyone from combining both approaches[0],
>    and I can make a solid case for doing both.
> 
>    The only reason why `sandboxed-tor-browser` doesn't have AppArmor
>    profiles is "Yawning had more important things to do than fuck
>    around building an AppArmor capable kernel and writing profiles,
>    like making everything else work".
> 
>  * AppArmor confinement without an external meta process allows the
>    confined processes too much access (in particular, to handle updates,
>    as you noted).
> 
>  * Linux isn't everything, as much as some of us wish it is (I did
>    the Linux sandbox instead of OSX or Windows after all...).  Speaking
>    pragmatically, factoring userbase into account, it's probably the
>    OS where doing any form of sandboxing protects the least number of
>    users.

I agree with all of this, especially the last point.

Oh, and it is not only Linux, OSX and Windows we need to take into
account for planning the future for our sandboxing work. Android is
coming later this year as a platform for Tor Browser as well. So, if we
start thinking about the need for rewriting parts of what we include
into Tor Browser now (and what is planned to get included into Tor
Browser for Mobile) Android requirements for sandboxing should be
considered, too.

That does not mean we need to have sorted out all of the problems on
every platform we want to support in the future before we start working
on getting The Right Thing done on a single one. However, I want to
avoid a situation where we think "Damn, had I thought about platform X
from the beginning I could have avoided yet another rewrite of Y".

As I heard about Vidalia++ in this thread: let's not forget the failures
of Vidalia (see:
https://www.petsymposium.org/2012/papers/hotpets12-1-usability.pdf) when
designing something new.

Where does that leave us? I think we should come up with a document
(maybe something on the wiki) about the design idea for The Right Thing
which goes into some detail explaining how this could work on all 4
(Linux, OSX, Windows, and Android) platforms, listing as many
showstoppers and possible workarounds we currently can think of, plus
all the things that are already in place (like Unix Domain socket
support etc.).

>> After reading this thread, it seems to me that both architectural
>> issues need to be fixed anyway on the long term, regardless of TBL.
>> And once they are, having TBL (or similar) in common Linux distros
>> will be a great way to provide a good (and perhaps safe enough?)
>> sandboxed-TB user experience on Debian, Ubuntu, Mint and their
>> derivatives. And as a bonus, TBL verifies the initial download of TB
>> better than what most users are able to do.
> 
> FWIW, `sandboxed-tor-browser` folds in a lot of the functionality of
> `tor-browser-launcher`[1], because the only sane way to bolt on a meta
> process based sandbox was to have it also manage installation/updating.
> 
> Honestly, I don't see a reason for `tor-browser-launcher` to exist at
> all in the brave new meta-process launcher based world.  If the new
> launcher can handle installation/updates (as IMO, it should), then
> package the new launcher.

Agreed.

> If people want to continue to use AppArmor, then the meta-process
> launcher package can include the necessary AppArmor profiles.

Yes.

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170530/6d44ace7/attachment.sig>