So, about the Linux sandbox in the long term?
Hello, I'm curious what the long term plans for the sandbox are, because as it stands and unless I hear differently, the current status is something along the lines of: * I will poke at it if something really bothers me, and I have the time. * I will fix bugs if something breaks for me. * Someone submits well written patches, which I will review and merge, if I like the patches. nb: The "if I like the patches" clause is so that it doesn't turn into a lisp interpreter masquerading as a text editor, that also happens to launch a browser. This is also largely moot, check the git history to see why. A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because: * It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization. While `sandboxed-tor-browser` makes a valiant effort, the approach is hampered and limited by what it has to work with, and it will forever be stuck reimplementing large chunks of functionality from firefox, torbutton, and tor-launcher. * I am a terrible UI programmer, and looking ahead, it will become increasingly untenable for the sandbox code to chase the incoming tor-launcher changes, in particular it is unlikely that I will be willing or able to replicate the UI/UX improvements or the circumvention auto-discovery feature. It would be a colossal waste of resources to re-implement something like "auto discover bridges". So, if people have a better plan than "the only guaranteed maintenance it gets is that it will get fixes when it breaks on Yawning's laptop, or when people submit detailed bug reports that Yawning can fix in spare time", I'm open to hearing them now. Regards, -- Yawning Angel
Hi Yawning, Thanks for bringing this up and thanks for your work on the sandbox. In my opinion, getting Tor Browser sandboxed should remain a high priority.
A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because:
* It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization.
Can you explain this a little further? Why are these diametrically opposed?
While `sandboxed-tor-browser` makes a valiant effort, the approach is hampered and limited by what it has to work with, and it will forever be stuck reimplementing large chunks of functionality from firefox, torbutton, and tor-launcher.
Are there any other approaches to sandboxing that you now think would be more practical? Thanks, Arthur
On 26 May 2017 at 13:52, Arthur D. Edelstein <arthuredelstein@gmail.com> wrote:
Hi Yawning,
Thanks for bringing this up and thanks for your work on the sandbox. In my opinion, getting Tor Browser sandboxed should remain a high priority.
A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because:
* It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization.
Can you explain this a little further? Why are these diametrically opposed?
So I'm not sure about Linux, but on Windows I would agree with this. Right now the current procedure, and plan, is: firefox.exe starts a hook starts running code in tor-launcher (in the future, tor-launcher might do some auto-probing or auto-bridge download) tor-launcher starts tor firefox.exe talks to tor.exe But what we'd like to get to is a place where firefox.exe (and its content processes) can't talk to the network, they can only talk to tor.exe (using a Windows Named Pipe on Windows, and Unix Domain Sockets on Linux/Mac). That's just half of the sandbox story though. You also have to restrict firefox.exe (both content and parent processes) from doing anything that will cause network requests to be created. Including: - Spawning processes to talk to the network - Loading libraries from remote hosts - Injecting code into other processes - Writing arbitrarily to the filesystem (things like the equivalent of writing to .bashrc) - Scheduling tasks - etc etc So if you do both of those things (restricting the browser from talking to the network, and sandboxing it so even with arbitrary code execution you still can't figure out a way to talk to the network) - you can get strong defense in depth. But wait a minute. If firefox.exe can't launch a process that can talk to the network... how's it supposed to launch tor.exe? And how's it supposed to talk to tor.exe over the control port? Maybe, maybe.... you can set up the sandbox so firefox.exe spawns tor.exe, creates a control port connection, and then sandboxes itself so it can no longer spawn processes or talk to network sockets. I'm not sure. But in general, this is the problem I'm seeing for Windows. It might be a similar problem to Yawning's. -tom
On Fri, 26 May 2017 15:39:16 -0500 Tom Ritter <tom@ritter.vg> wrote: [snip]
So if you do both of those things (restricting the browser from talking to the network, and sandboxing it so even with arbitrary code execution you still can't figure out a way to talk to the network) - you can get strong defense in depth.
But wait a minute. If firefox.exe can't launch a process that can talk to the network... how's it supposed to launch tor.exe? And how's it supposed to talk to tor.exe over the control port?
Maybe, maybe.... you can set up the sandbox so firefox.exe spawns tor.exe, creates a control port connection, and then sandboxes itself so it can no longer spawn processes or talk to network sockets. I'm not sure.
But in general, this is the problem I'm seeing for Windows. It might be a similar problem to Yawning's.
Nailed it. There's a few other things like filesystem visibility (firefox.exe should *NEVER* have visibility into tor's runtime state directory, but needs that to launch tor) related issues, but it's essentially the same problem. I will note that there is nothing keeping anyone from writing a `tor-launcher` addon that does everything that `sandboxed-tor-browser` does (tor-launcher's functionality, updates, launching tor) that re-launches a restricted copy of firefox.exe as a child process, at least on Linux, with quite a bit of effort. I am uncertain about other operating systems, and that sort of approach scares me, primarily because "pulling in a full web browser to do things a smaller self-contained executable can do" feels like a poor design choice and a nightmare to audit. AFAIK this privilege inversion issue is also a problem on OSX. The main difference there (beyond "different platforms"/feature completeness) is that, instead of `sandboxed-tor-browser`, users get two shell scripts that they need to invoke manually. The short version of what I view as a "correct" approach is "abandon tor-launcher, and go back to having an external launcher process like we did when vidallia was a thing, but actually maintain it this time", because having something like that independent/external to Firefox makes more sense architecturally. Regards, -- Yawning Angel
Thanks for the clarifications, Tom and Yawning.
I'm curious what the long term plans for the sandbox are
It seems there are different threats due to browser exploits we are discussing here: (1) pwnage of the whole computer, (2) modifying the browser or tor binaries, (3) modifying the torrc or otherwise launching tor in a malicious way, and (4) one-time deanonymization via the ControlPort. So I wonder if it would make send to take a gradual approach in which defenses are deployed one by one, starting with the low-hanging fruit and working upwards. Something like: Step 1: Containerize the whole bundle to defend against pwnage of the whole computer. Step 2: Create a external update mechanism and prevent firefox.exe from writing to its own directory or the tor directory. Step 3: Patch tor so that tor-launcher doesn't need to write to torrc at all to configure tor. Launch tor independently of the browser, but still configure tor using the tor-launcher extension UI, via a filtered control port. Prevent firefox from accessing tor directory or launching tor. Step 4: Write a new tor-controller UI in QT or similar that replaces functionality in tor-launcher and maybe the circuit display. Am I right in thinking that there is a substantial security benefit to each step? And would it be feasible to deploy each step to users in standard Tor Browser without waiting for the next step to be ready?
On Fri, 26 May 2017 17:45:03 -0700 "Arthur D. Edelstein" <arthuredelstein@gmail.com> wrote:
Thanks for the clarifications, Tom and Yawning.
I'm curious what the long term plans for the sandbox are
It seems there are different threats due to browser exploits we are discussing here: (1) pwnage of the whole computer, (2) modifying the browser or tor binaries, (3) modifying the torrc or otherwise launching tor in a malicious way, and (4) one-time deanonymization via the ControlPort. So I wonder if it would make send to take a gradual approach in which defenses are deployed one by one, starting with the low-hanging fruit and working upwards. Something like:
Beyond, "this would be a massive duplication of effort", there's nothing preventing something like this.
Step 1: Containerize the whole bundle to defend against pwnage of the whole computer. Step 2: Create a external update mechanism and prevent firefox.exe from writing to its own directory or the tor directory. Step 3: Patch tor so that tor-launcher doesn't need to write to torrc at all to configure tor. Launch tor independently of the browser, but still configure tor using the tor-launcher extension UI, via a filtered control port. Prevent firefox from accessing tor directory or launching tor. Step 4: Write a new tor-controller UI in QT or similar that replaces functionality in tor-launcher and maybe the circuit display.
The existing Linux sandbox does all of this already. Re-doing something that already exists (twice), seems somewhat silly to me.
Am I right in thinking that there is a substantial security benefit to each step?
Sure.
And would it be feasible to deploy each step to users in standard Tor Browser without waiting for the next step to be ready?
Might be tricky for other reasons, but I guess? The big gotcha is that containerization is a privileged operation on sensible Linux systems. Regards, -- Yawning Angel
On Fri, May 26, 2017 at 8:05 PM, Yawning Angel <yawning@schwanenlied.me> wrote:
On Fri, 26 May 2017 17:45:03 -0700 "Arthur D. Edelstein" <arthuredelstein@gmail.com> wrote:
Step 1: Containerize the whole bundle to defend against pwnage of the whole computer. Step 2: Create a external update mechanism and prevent firefox.exe from writing to its own directory or the tor directory. Step 3: Patch tor so that tor-launcher doesn't need to write to torrc at all to configure tor. Launch tor independently of the browser, but still configure tor using the tor-launcher extension UI, via a filtered control port. Prevent firefox from accessing tor directory or launching tor. Step 4: Write a new tor-controller UI in QT or similar that replaces functionality in tor-launcher and maybe the circuit display.
The existing Linux sandbox does all of this already. Re-doing something that already exists (twice), seems somewhat silly to me.
Of course it would be! :) For Linux, I was envisioning adopting your work into the standard TBB distribution. Not writing it again from scratch. But we also need these steps on Windows and OS X. And my understanding is that on Linux there's more work to be done for step 4 and maybe some for the stopgap approach in step 3. Rather than waiting for a whole new tor-launcher UX in QT, maybe we can adopt your work from the earlier steps in standard TBB sooner.
Might be tricky for other reasons, but I guess? The big gotcha is that containerization is a privileged operation on sensible Linux systems.
That does indeed sound like a big problem. Any workarounds you know of?
On Fri, 26 May 2017 20:35:24 -0700 "Arthur D. Edelstein" <arthuredelstein@gmail.com> wrote:
The existing Linux sandbox does all of this already. Re-doing something that already exists (twice), seems somewhat silly to me.
Of course it would be! :) For Linux, I was envisioning adopting your work into the standard TBB distribution. Not writing it again from scratch.
It's not clear to me how a lot of that is possible without either doing a stupid amount of UI work (that will get thrown away), or rewriting a lot of the sandboxing code in JS/C++. Am I missing something?
But we also need these steps on Windows and OS X. And my understanding is that on Linux there's more work to be done for step 4 and maybe some for the stopgap approach in step 3. Rather than waiting for a whole new tor-launcher UX in QT, maybe we can adopt your work from the earlier steps in standard TBB sooner.
Maybe I wasn't clear enough in my initial e-mail. Even on Linux, there's a gigantic amount of work that's currently not being done at all, that would be required to improve the "not sandbox" components of the sandboxed launcher to get it up to parity with `tor-launcher`, and the amount of work will only increase as improvements and feature adds are made to `tor-launcher`[0]. *If* the plan is to eventually move to doing an external launcher, there is basically no point at all to doing the "gigantic amount of UI work", because it's for a codebase that is essentially dead, and scheduled for replacement (with the grand unified Qt launcher of awesome[1]). Anyway, it's fairly clear to me that there is no clear plan for how to handle sandboxing's requirements vs `tor-launcher`, so I will continue with: "the only guaranteed maintenance it gets is that it will get fixes when it breaks on Yawning's laptop, or when people submit detailed bug reports that Yawning can fix in spare time" Regards, -- Yawning Angel [0]: As an example, I don't have a good way to update the launcher. [1]: If I had to support 3 platforms, I'd probably write the launcher in C++ with Qt, instead of Go/Gtk3.
Hi, Tom Ritter:
But wait a minute. If firefox.exe can't launch a process that can talk to the network... how's it supposed to launch tor.exe?
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. This requires admin privileges to set the whole thing up initially (which is done e.g. by the torbrowser-launcher Debian package), but then no special privileges are needed when *running* Tor Browser. This approach makes a lot of sense to me on Linux, where the "download an app via a tarball and then double-click it" model is not the most common way to install and run software: most software people need is available in their distro's package repositories. The way this works currently has several drawbacks, that will be easy to fix once architectural issues raised on this thread are addressed in Tor Browser: * It requires the update mechanism to live inside Firefox (as the update code was dropped from TBL), which makes the confinement rules way too lax for my taste. But once there's an external update mechanism, then this will be easy to fix. * It depends on Tor Browser for the configuration of little-t-tor. But here again, once this is handled by a GUI outside of Firefox, TBL can use it and confine Firefox more strictly. * It depends on AppArmor for confinement. That's already the case on Ubuntu and SUSE, and my plan is to have AppArmor enabled by default in Debian 10 (Buster); Red Hat -based distros are out though, until the LSM stacking patches make their way to the mainline Linux kernel. 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. Cheers!
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.
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. Regards, -- 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.
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
On Tue, 30 May 2017 11:04:00 +0000 Georg Koppen <gk@torproject.org> wrote:
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.
Oh boy. I don't see AppArmor working at all, though this depends on the kernel. seccomp + namespaces might work, though this also depends on how the kernel is built. Doesn't the OS handle containerization and secure updates? Are we doing the play store thing? Is tor-launcher even relevant on that platform, or is Orbot going to continue to handle all of that? (I suspect that Android will end up remaining as the redheaded step child, depending on what path makes sense for the real computer platforms.)
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".
Agreed.
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.
This seems like the major issues are primarily UI/UX related. As I mentioned on IRC, there's 0 reason why the meta-process can't present something to the user that looks like tor-launcher, so I think that's the least of the worries.
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.).
I think the design I had in mind for what I want the Linux sandbox to be eventually, would also work on OSX and Windows. No idea about Android, and I didn't bother writing much of it down because I was pressed for time. Sorry. Regards, -- Yawning Angel
On 30 May 2017 at 07:45, Yawning Angel <yawning@schwanenlied.me> wrote:
On Tue, 30 May 2017 11:04:00 +0000 Georg Koppen <gk@torproject.org> wrote:
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.
Oh boy. I don't see AppArmor working at all, though this depends on the kernel. seccomp + namespaces might work, though this also depends on how the kernel is built.
Doesn't the OS handle containerization and secure updates? Are we doing the play store thing? Is tor-launcher even relevant on that platform, or is Orbot going to continue to handle all of that?
(I suspect that Android will end up remaining as the redheaded step child, depending on what path makes sense for the real computer platforms.)
For updates, I suspect that the Google Play and F-Droid (and maybe a custom Tor Project FDroid repo) are the way to go, and supporting anything else would be too much trouble. See also https://lists.mayfirst.org/pipermail/guardian-dev/2017-May/005278.html I haven't looked closely at how FDroid or a custom fdroid repo works though. The OS does handle containerization, thankfully. There are some IPC mechanisms we should investigate (sending URL intents for example). But the sandboxing options on Android are probably much more limited than Desktop linux. I don't know of anyone who's played around with it actually. I think the current plan is to integrate tor into the Browser app; and not use Orbot - but I'm not sure where that would let us do any network-lockdown sandboxing that might be possible. I am not certain if an Android app has permission to rewrite itself. We would need to investigate to be certain that this can only be done by the updater. Definitely a lot of questions here... -tom
Hi, 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?
It does: TBL wasn't converted to using Unix sockets yet. Besides, the network filtering AppArmor support relies on kernel patches that haven't made their way upstream yet, so currently only Ubuntu and OpenSUSE (I think) would block network access if `network tcp,' was removed. So indeed AppArmor is currently not 100% enough for the kind of sandboxing we're looking for. Sorry I forgot that part in my last post!
The differences in approaches, IMO, is totally irrelevant to "does there need to be fundamental architectural changes" since: […]
Agreed on all that.
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.
Great.
Honestly, I don't see a reason for `tor-browser-launcher` to exist at all in the brave new meta-process launcher based world.
I think the only current good reason to keep it around is that it's already packaged for some common distros, has users there, and nobody looked at packaging sandboxed-tor-browser for them yet.
If the new launcher can handle installation/updates (as IMO, it should), then package the new launcher.
Absolutely. This will address the UX/security problems I was referring to wrt. the "download an app via a tarball and then double-click it" model on Linux. So I'm glad we decided *not* to have TBL included in the upcoming new Debian release (Stretch), albeit for unrelated reasons.
If people want to continue to use AppArmor, then the meta-process launcher package can include the necessary AppArmor profiles.
I'll be glad to work on this once the long-term plans are clearer :) Cheers, -- intrigeri
On Fri, 26 May 2017 11:52:05 -0700 "Arthur D. Edelstein" <arthuredelstein@gmail.com> wrote:
A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because:
* It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization.
Can you explain this a little further? Why are these diametrically opposed?
https://lists.torproject.org/pipermail/tbb-dev/2017-January/000451.html
While `sandboxed-tor-browser` makes a valiant effort, the approach is hampered and limited by what it has to work with, and it will forever be stuck reimplementing large chunks of functionality from firefox, torbutton, and tor-launcher.
Are there any other approaches to sandboxing that you now think would be more practical?
The "correct" approach is covered in the previous e-mail as well. Regards, -- Yawning Angel
participants (5)
-
Arthur D. Edelstein -
Georg Koppen -
intrigeri -
Tom Ritter -
Yawning Angel