Yawning Angel:
On Sat, 27 May 2017 12:27:21 +0200 intrigeri intrigeri@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