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

Yawning Angel yawning at schwanenlied.me
Sat May 27 12:15:40 UTC 2017

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

> 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.

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


Yawning Angel

[0]: I'm also hoping that something like landlock-lsm gets
mainlined (https://github.com/landlock-lsm/linux/commits/landlock-v6),
because then someone can have the kernel enforce file system
restrictions a la AppArmor, without ever having to be root.

[1]: In the "It can download, validate, and install Tor Browser from
official tarballs/signatures" sense.  It also does external updates,
because firefox shouldn't be able to rewrite itself or the tor binary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170527/750e36d2/attachment.sig>

More information about the tbb-dev mailing list