tbb-dev July 2018

tbb-dev@lists.torproject.org

8 participants
11 discussions

Nightly rebase experiment proposal
by Arthur D. Edelstein 03 Feb '20

03 Feb '20

Hi everyone, Here's a plan for experimenting with moving Tor Browser from ESRs to mozilla-central. Why try this? There are several reasons I can think of: * There is no mobile Firefox ESR. In order to keep mobile Tor Browser secure, we would either need to constantly monitor for security fixes and apply backports. It will be simpler to follow the Mozilla release cycle. * Tor Browser will receive all security patches and security features from Mozilla, not simply those deemed important enough to backport to the last ESR. * Closer collaboration between Mozilla and the Tor Browser team will be possible, because everyone will be focused on the same codebase. For example, non-urgent patches can land directly on mozilla-central, bypassing tor-browser.git altogether, and those patches will be deployed to Tor Browser faster than they would have been on an ESR-only schedule. Mozilla will provide expert review of patches. Also, some non-urgent patches by Tor Browser may be written by Mozilla engineers. * The Tor Browser development process will be smoother and more gradual. Instead of rebasing and patch-fixing sprints ahead of each ESR, we can automatically rebase patches every night, and fix any patch whenever its rebase fails. (The total rebase effort should be approximately the same as before.) * Patches that frequently break because they live on "hot code" can be identified and uplifted. * We'll need to continuously monitor the mozilla codebase for new features that could harm privacy. That's potentially difficult, but by focusing on Mozilla's current work, we can hopefully stop patches that affect privacy before they land. Here's how I envision the new rebase process: * An automated script rebases all tor browser patches every night against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr. An email alert will be sent if the rebase of any patch fails. (I have a prototype script that does the basic rebasing -- it found that ~40/140 patches from our ESR-52 branch could be auto-rebased onto mozilla-central without any intervention.) * Any failed patches will need to be manually fixed up promptly so that the automated rebase can resume. * Diagnostic Tor Browser bundles will be built against the latest rebase branches. We can also run regression tests. So how do we ramp up this experiment? 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on top of Firefox 59-beta. (We have to do this anyway.) 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser patches nightly onto mozilla-(central, beta, stable, esr). 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds based on nightly rebases. At this point, we can evaluate whether we would like to transition to releasing Tor Browser alphas based on the mozilla-beta branch. Switching Tor Browser stable to mozilla-stable can happen sometime after that. How does this sound? Interested to hear what you think. Thanks, Arthur

7 12

Feedback on the embedding API in tor_api.h
by isabela 03 Aug '18

03 Aug '18

Hello tor browser mobile devs! I am writing to you because you are part of a group of mobile developers that we (Tor network team) are contacting to ask for feedback on work we have done to help mobile devs embed Tor in their apps. We did a survey with other mobile devs (back in mid 2017) and based on some of that feedback we created the 'tor_api.h' controller API - you can read more about this work at the ticket #23684 [1]. We would be very thankful if you could spend a bit of your time looking at what we built, and if possible testing it to give us feedback (or report bugs). This will help us fix what is broken and improve it! Please create a child ticket to our #25510 [2] master ticket for collecting feedback and/or bug reports. Thank you in advance! Isabela [1] https://trac.torproject.org/projects/tor/ticket/23684 [2] https://trac.torproject.org/projects/tor/ticket/25510

3 4

[Survey] Does your team uses github.com?
by isabela 30 Jul '18

30 Jul '18

Hi there, I am sending this to all vegas teams in order to collect information to make decisions on how we should configure github.com for Tor teams use. To be clear - we are not replacing hosting our own git repo for github.com. We are considering using it as a synced repo for other means (more information below). Please answer this as soon as you can so we can get things organized :) and projects that want to use it can move on to use it. thanks! isabela background: This history goes way back then I will do in the background I am providing here. If you want to know more ping (isa or maybe irc in general cuz isa doesn't know i tall either). To make things short, we have been investigating options to improve our workflow and volunteers workflow. Network team has being doing a lot of that and recently decided to use github.com as a solution for, between other things: * receive and review volunteers collaborations * review long pieces of code * use travis/CI testing from github.com infra When doing it we saw that OONI is also using github.com in their workflow. And after the network team migrated to it, stem also start using it. With that, an instance of gitlab that we had for tests (oniongit) was only being used by the UX/Services teams. To consolidate how we do things, UX/Services teams decided to move to github.com too (and we will kill oniongit). The idea here is to have github.com for volunteers patches and some of the stuff listed above that the network team is doing (if people want them) but we will: * keep trac as our issue tracker (so all teams will continue to use trac tickets to coordinate their work) * our real repo will always be our repo (so we can only push to master on our repo and only us can do it) There is more to what I am saying here, more configuration details and use cases you might want to talk about. That is why I am sending this survey, to learn more from all teams. The goal here is to organize how tor does things with github and have this option available for teams to use. If you think your team doesn't need this you can just let us know in the survey. note: some configuration discussion is going on in this other pad: https://pad.riseup.net/p/Organizing-GitHub-and-Tor survey: Do you currently use github for anything? If yes, could you describe a bit how? Things like: * What usernames your team members has on github? * What github projects is your team using? * What github repos? * Any special permissions configuration? * Do you sync what is there with tor's git? (gitweb) If so how? If you are not using it yet, and could see a reason to start using it, please let us know: * What would you answer for the above questions (for those who are already using it), you can write 'i would need a project named xxxx' for instance. * Is there anything else your team would need in order to be set up to use github?

2 1

Sandboxing Tor Browser - Next Step
by Matthew Finkel 30 Jul '18

30 Jul '18

Hi Everyone, We had a productive meeting yesterday about sandboxing Tor Browser. I sent a high-level summary on tor-dev@ [0]. We ended the meeting while we were discussing/considering the different criteria for how we decide which sandboxing implementation(s) we persue [1]. This is the continuation of that topic. Specifically, we currently have four sandboxing options under consideration (there may be more we aren't considering): a) one standard VM on all desktop OSes running Tor Browser on Linux b) Per-OS container/virtualization solution c) No container/vm, but sandboxing the parent and content processes using OS-specific mechanisms (dropping privs etc.) d) a mix of all options choosing the best per platform With each of these mechanisms, we enumerated some criteria for evaluating them and choosing the best option for Tor Browser: 1) (in the face of a browser exploit) tracking protection 2) (no browser exploit) tracking protection 3) (in the face of a browser exploit) proxy bypass protection 4) (no browser exploit) proxy bypass protection 5) user experience 6) development effort (including time to market with improved security) 7) maintainability 8) uplift possibilities 9) installation size? (part of user experience?) 10) ability to take advantage of expected future security improvements 11) Compatibility with future browser/app development plans at the Tor Project As mentioned during the meeting, there doesn't currently exist a common set of sandboxing mechanisms across all platforms. Maybe this will exist in some years when Docker is the de facto standard run-time. Until then, we have platform-specific implementations we must use. How should we document ranking each of the sandboxing options with the stated criteria? Would this be easier on another pad or using a spreadsheet (ethercalc)? Thanks, Matt [0] https://lists.torproject.org/pipermail/tor-dev/2018-July/013350.html [1] https://pad.riseup.net/p/sandbox-07-24

4 3

Fwd: Call for Participation: W3C Workshop on Permissions and User Consent
by Tom Ritter 24 Jul '18

24 Jul '18

For anyone west coast local perhaps... ---------- Forwarded message --------- From: Samuel Weiler <weiler(a)w3.org> Date: Fri, Jul 13, 2018, 2:14 PM Subject: Fwd: Call for Participation: W3C Workshop on Permissions and User Consent To: <public-device-apis(a)w3.org>, public-web-security(a)w3.org < public-web-security(a)w3.org>, <public-privacy(a)w3.org> W3C is holding a workshop on Permissions and User Consent, September 18-19 in San Diego. The full CFP is at: https://www.w3.org/Privacy/permissions-ws-2018/cfp.html I encourage your participation. -- Sam Weiler, W3C -------- Forwarded Message -------- Subject: Call for Participation: W3C Workshop on Permissions and User Consent Resent-Date: Thu, 12 Jul 2018 08:03:03 +0000 Resent-From: w3c-ac-members(a)w3.org Date: Thu, 12 Jul 2018 10:02:51 +0200 From: Coralie Mercier <coralie(a)w3.org> To: w3c-ac-forum(a)w3.org CC: chairs(a)w3.org Dear Advisory Committee Representative, Chairs, W3C is pleased to call for participation in: W3C Workshop on Permissions and User Consent September 18-19 2018, San Diego, CA https://www.w3.org/Privacy/permissions-ws-2018/cfp.html Thanks to Qualcomm for hosting the workshop. This workshop brings together security and privacy experts, UI/UX researchers, browser vendors, mobile OS developers, API authors, Web publishers and users to address the privacy, security and usability challenges presented by the complex and overlapping variety of permissions and consent systems that are currently presented for hardware sensors, device capabilities and applications on the Web. The scope includes: * user consent; * bundling of permissions; * lifetime/duration of permissions; * permission inheritance to iframes and other embedded elements; * relation to same origin policy; * UIs and controls; * interaction with private browsing modes; * implicit permission grants; * progressive permission grants; * cross-stack permissions: how OS, browser, and web app permissions interact; * permission transparency; * relation to regulatory requirements; * special considerations for systems that use the browser as a pass-through (e.g. EME and Web Authentication); and * permissions/transparency/UI as it relates to display-less devices that connect to the Internet. We aim to share experiences and user studies, leading to common understanding of when and how to seek user consent for use of various Web platform capabilities. We expect this workshop to lead to concrete and consistent guidance for API authors and implementers and to identify areas for further standardization or research. An important take-away from this workshop should be guidance on how Permissions APIs should be designed, both now and in the future, considering the rapid evolution of the web platform. For more information on the workshop, please see details and submission instructions: https://www.w3.org/Privacy/permissions-ws-2018/cfp.html If you have any questions, please contact organizer Samuel Weiler <weiler(a)w3.org>. W3C Members interested in sponsoring this workshop should contact Alan Bird <abird(a)w3.org>. This announcement follows section 8 of the W3C Process Document: https://www.w3.org/2018/Process-20180201/#GAEvents We look forward to seeing you there. Coralie Mercier, Head of W3C Marketing & Communications -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/CMercier/

1 0

Fwd: Intent to update bugs: Non-GeckoView bugs in Firefox for Android
by Tom Ritter 23 Jul '18

23 Jul '18

I couldn't find any tor bugs in '*Bugs to close*' In '*Bugs to re-prioritize*' I found 15: Uplift Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=507641 https://bugzilla.mozilla.org/show_bug.cgi?id=942652 https://bugzilla.mozilla.org/show_bug.cgi?id=1282826 https://bugzilla.mozilla.org/show_bug.cgi?id=1314776 https://bugzilla.mozilla.org/show_bug.cgi?id=1314778 https://bugzilla.mozilla.org/show_bug.cgi?id=1371180 https://bugzilla.mozilla.org/show_bug.cgi?id=1377509 Test Harness Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1314793 https://bugzilla.mozilla.org/show_bug.cgi?id=1373550 Feature Requests: https://bugzilla.mozilla.org/show_bug.cgi?id=1357994 https://bugzilla.mozilla.org/show_bug.cgi?id=1337647 https://bugzilla.mozilla.org/show_bug.cgi?id=1358040 https://bugzilla.mozilla.org/show_bug.cgi?id=1376601 I am going to close the TorOnFennec feature bugs. I think if we want any of those uplift bugs landed we will need to reach out directly to people and come up with a plan for review. If you're fine addressing them locally for the lifetime of Fennec, it would be ideal for us to close them to avoid things in our bug queries. Matt, Igor, let me know what you think! -tom ---------- Forwarded message ---------- From: Emma Humphries <emma(a)mozilla.com> Date: Wed, Jul 11, 2018 at 7:49 PM Subject: Intent to update bugs: Non-GeckoView bugs in Firefox for Android To: fx-team <fx-team(a)mozilla.com>, Mobile Everyone <mobile-all(a)mozilla.com>, "dev. planning" <dev-planning(a)lists.mozilla.org>, Firefox Dev < firefox-dev(a)mozilla.org> Cc: Susheel Daswani <sdaswani(a)mozilla.com>, Barbara Bermes <b(a)mozilla.com>, Andreas Bovens <abovens(a)mozilla.com>, David Bolter <dbolter(a)mozilla.com>, Kevin Brosnan <kbrosnan(a)mozilla.com> Hello, I want to update you on discussions between Barbara Bermes, Andreas Bovens, David Bolter, Susheel Daswani, Kevin Brosan and myself on unresolved and untriaged bugs in Firefox for Android and the actions we're taking on the bug backlog. Since our strategy for mobile is changing, Susheel's team is focusing on a small number of bugs in Firefox for Android which aren't in the GeckoView component. Non-GeckoView bugs which are not being worked on and have been modified in the past 18 months (~580 days) will be re-prioritized as P5. Unconfirmed, non-GeckoView bugs will be closed as incomplete. Non-GeckoView and non-JimDb bugs unmodified in the past 18 months will be closed as incomplete. Bugs which are enhancement requests will be reviewed, and ones which won't be taken up as features/enhancements will be resolved as wontfix. To summarize: *Bugs to close* - Non-GeckoView, Non-JimDB bugs more than 560 days since last modified https://mzl.la/2Jg2Co4 (~3,500) - Unconfirmed bugs to close https://mzl.la/2L65rgk (~300) *Bugs to re-prioritize* - Bugs to move to P5: https://mzl.la/2L6SpMA (~2,000) *Bugs to review or move* - GeckoView bugs to move to new product (https://mzl.la/2N5M98s) (~120) - Enhancements to be reviewed (https://mzl.la/2JfF6aB) (~190) This work is detailed in https://bugzilla.mozilla.org/ show_bug.cgi?id=1473195. The BMO team will move the GeckoView bugs to a new product https://bugzilla.mozilla.org/show_bug.cgi?id=1460337. I plan to do these moves on Wednesday the 25th of July. If there is a non-GeckoView, non-enhancement, bug in Firefox for Android which you know ought to be addressed, please needinfo Barbara Bermes and Susheel Daswani on the bug so they can determine if it will be prioritized. Emma Humphries EPM/Bugmaster, Firefox Mozilla

2 1

help collecting info for sponsor8 Q2 report
by isabela 23 Jul '18

23 Jul '18

Hello mobile devs! As you won't have a meeting this week (at least that is my understanding maybe I am wrong :) I decided to ping the mobile devs via email to ask for help collecting tickets and all the stuff worked on Q2. Here is the pad for that: https://storm.torproject.org/shared/lVHpb3X36tWaVem8NRarrj0mCgocd0-oz7lj--z… Let me know if you have any questions! cheers, isabela

2 1

HOPE talk
by Matthew Finkel 19 Jul '18

19 Jul '18

Hi Tor Browser Devs, Sorry I didn't send this sooner. On Friday at HOPE we're giving an "Onion Report". During that presentation I'll talk about some of the awesome work you've done over the last year (and continue doing). I'm currently planning on hilighting the new circuit display, the onion+https indicator, and ESR60. Are there any other user-facing features I should mention? I can talk about uplift and some of the progress made with Mozilla, as well. Should I mention http2 should be enabled in 8.0 stable? I'll also talk about TBA and Onion Browser for the mobile-side. Let me know if you have any thoughts - either on-list or off-list. Thanks! Matt

3 2

Missing Today's Meeting
by Matthew Finkel 16 Jul '18

16 Jul '18

Hi All, Unfortunately I'll miss today's team meeting. I'll read through the meeting log. - Matt

1 0

Sandboxing Tor Browser - A New Beginning (?)
by Matthew Finkel 06 Jul '18

06 Jul '18

Hi All, This is the beginning of a conversation about creating a plan for moving towards sandboxing Tor Browser on every platform. Over the last few years, there existed a Sandboxed Tor Browser on only Linux[0] (created and maintained by Yawning Angel). However, Tor Browser aims at providing a Private Browser on all supported platforms (Microsoft Windows, Apple Mac OS X, GNU/Linux, and Android (AOSP))[1][2], this means we must provide a sandboxed run-time environment on all platforms. Unfortunately, each operating system provides a unique set of sandboxing techniques and capabilities, so we must work with the facilities we are given. In some cases, we may need to be creative about how we achieve our goals. I do not have all the answers, and there are some open questions below. On Windows, we have the Windows integrity mechanism[3], Windows Containers[4], SetProcessMitigationPolicy[5], App Container[6], and maybe some others. Some of this functionality is already used by Firefox. On Mac OS X, there are two sandboxing techniques available. The first is Seatbelt[7]. Apple deprecated it in favor of code signing entitlements[8]. Unfortunately, the code signing entitlements are not as fine-grained as those Seatbelt provides, but we can enable different entitlements per "target"[9]. I don't know if this will be difficult for us. Therefore, we should utilize the code-signing restrictions where they are appropriate, but we should follow Safari[10], Chromium[11], and Firefox[12][13] by applying restrictive Sealtbelt policies where applicable. On GNU/Linux, we can use the namespacing and secure computing (Secure Computing) facilities in the kernel exposed to userspace. Sandboxed Tor Browser on Linux already shows how these can be combined and form a sandbox. In particular, we can use bubblewrap[14] as a setuid sandboxing helper (if user namespace is not enabled), if it is available. In addition, we can reduce the syscall surface area with Seccomp-BFP. CGroups provide a way for limiting the resources available within the sandbox. We may also want to manually proxy/filter other system functionality (X11). Last, but not least, on Android, we begin with a fairly strict sandbox provided by its permissioning model[15], distinct per-app users, and SELinux policies. Because every app is run using a distinct user, and each has its own storage directories, we get Linux's DAC on the file system for "free". In addition, we can use some of the same techniques available on GNU/Linux on Android, namely the seccomp-bpf and namespaces, if they are available. Android provides privilege and permission isolation within an App by using Services. With some refactoring, we can isolate some parts of Firefox into isolated permissionless services[15]. I'll begin by describing the goals, as I see it, for sandboxing Tor Browser. Hopefully, this will help us evaluate the different available techniques. These goals are derived from the Design document[16] and are the means for archieving Tor Browser's end-goal. In particular, the sandboxing techniques preserve the Security Requirements of a private browser when the browser, itself, fails at maintaining those criteria. By this I mean the sandbox should be designed such that if the browser process loses any of the Security properties (through a logical bug, exploited vulnerability, etc), the sandbox provides an additional layer of those properties and the user is not in immediate danger. The sandbox may, in some situations, improve the Privacy properties of Tor Browser, for example if a component/device is emulated instead of providing the browser with raw access. We should use these mechanisms when they are available. 1) Proxy Obedience 2) State Separation 3) Disk Avoidance 4) Application Data Isolation 5) Secure Updating 6) Usable 7) Cross-Origin Fingerprinting Unlinkability We'll go through these one-by-one and describe the role of a sandbox and how we can achieve this on each platform. Note, this design assumes a launcher-based sandboxed architecture (similar to the Sandboxed Tor Browser on Linux): ------------------ | Launcher | ------------------ | | ------------------------------ | | | | v | | ---------------- | v | Sandbox | v ----------------- | ----------- | ----------------- | Sandbox | | | Broker | | | Sandbox | | ------------- | | ----------- | | ------------- | | | Firefox | | --------------- | | Tor | | | ------------- |------/ \_________| ------------- | ----------------- Controller ----------------- |____________________________________| Proxy IPC Note, the sandboxed broker process (or processes) moves some functionality from the launcher process into a child process. This process is not as heavily sandboxed as the Firefox and Tor process, but, for example it would not need networking. This process would handle sending NEWNYM, provide a circuit display, change bridge configuration (general controller functions). In addition, it would handle copying files into and out of the Firefox sandbox, as an example. Unfortunately, there is not an existing cross-platform solution for this design. We can take bits-and-pieces from other solutions, creating this will require engineering effort. 1) Proxy Obedience The last line of defense against a proxy-bypass is a mechanism for dropping all outgoing IP packets from the browser that are: - not TCP - or TCP but not destined for the Tor proxy port (SOCKS or HTTP) - or all packets (including TCP) if the proxy listener is not a TCP port (Unix domain socket, named pipe, etc) We should also consider guarding the creation of all non-Unix domain sockets and non-named pipes with a pref. I believe sandboxing should be optional, but enabled by default (at least with first few versions), so excluding that code at compile-time is not an option. However, a pref-guard only stops unintended proxy-bypass through normal control flow. This only slightly increases the difficulty of some exploit methods. Per-platform sandboxing techniques: a) Microsoft Windows i) Windows 8+ If the user can elevate for administrator permissions, then the launcher can: - install a network filter using the Windows Filter Platform[17]. This can deny any connection from any process (based on the process's fully-qualified file name)[18]. This adds some risk because if the launcher process exits unexpected for whatever reason, the firewall rule may remain in place. ii) Windows 10 We can create a new network namespace[19] using the (undocumented) HNSCall procedure[20]. This is very appealing. iii) Windows 7+ If the platform is Windows 8+ and the user cannot elevate to Administrator or if the platform is Windows 7: - TODO: can/should we use DLL injection of WinSocks and manually filter all proxy-bypass network connections? Is there something we can use for mitigating ROP gadgets within the sandbox? b) Mac OS X i) We can restrict network access using the com.apple.security.network.client and com.apple.security.network.server entitlements[21]. ii) We can further restrict which types of connections the browser is allowed. Previously, there was a seatbelt profile for Tor Browser[22], but it is not usable with newer versions of the browser. We can continue using it for only allowing access requests for Unix domain sockets, and denying all other network connections. c) GNU/Linux i) On Linux, significant progress was already made in terms of sandboxing Tor Browser. There are two methods we can use: - Isolated network namespace via bubblewrap[14] - Seccomp-BPF on socket syscalls ii) If bubblewrap is not available, we can fallback on using unshare if it is available and user namespace is enabled iii) If user namespaces are not avialable, we ask the user for elevated privileges and manually fork into the new network namespace (worst-case). d) Android i) We can use the same (or similar) Seccomp-BPF filter that we use on Linux ii) We can move the Gecko service into an isolated process without any permissions (including Networking). iii) If all networking goes through Necko, and Neck is in the isolated process, then the remaining code, outside the isolated process, should be proxy-safe or it is the tor process. 2) State Separation Per-platform sandboxing techniques: a) Microsoft Windows i) I'm not sure if there is more we can do here. b) Mac OS X i) The Seatbelt profile[22] can restrict access to all other Firefox profiles ii) The Seatbelt profile can only allow access for bundled libraries iii) We may exclude entitlements for most system services c) GNU/Linux i) We can create new IPC, mount, and uts namespaces ii) We can provide a clean environment iii) The new mount namespace contains only the required bundled libraries required for running iv) D-Bus/I-Bus access would be nice, if we can do it safely. d) Android i) All apps are isolated by default, so there should never be shared state. ii) Ensure we have the smallest set of intent filters we need iii) Ensure we have the smallest set of exported components we need iv) Ensure we have the smallest set of broadcast receivers we need v) Ensure we only use Broadcast intents where it is necessary vi) Is there something else we should investigate here? 3) Disk Avoidance In general, I'd like #7449 mitigated. Per-platform sandboxing techniques: a) Microsoft Windows i) Windows 10+ - On very recent versions of Windows, we can create temporary filesystem Layers[23][24]. I'm not sure if these are memory-backed or filesystem-backed. - We can create a read-only layer over the installation directory - #18367 may be useful (side-by-side user/app data on Windows) - Can we can isolate the container from system services? b) Mac OS X i) We can use entitlements[25] ii) The Seatbelt profile[22] provided additional access restrictions. iii) Is there a filesystem layering mechanism available in OS X (like tmpfs in Linux)? - Specifically, if we can use this for ~/Library/Caches/TemporaryItems and ~/Downloads c) GNU/Linux i) We can create new IPC, mount, and uts namespaces ii) #18369 may be useful (side-by-side user/app data on Linux) d) Android i) The app is self-contained by default ii) Need #26574 iii) Additional auditing required 4) Application Data Isolation I'll claim the per-platform sandboxing techniques are the same as Disk Avoidance. 5) Secure Updating Nearly the same sandboxing techniques can be used on all platforms. A launcher-component (maybe not the launcher, but a reduced-privileged process, not the browser) downloads the update. Next, on download completion, a launcher-component verifies the download and installs it (I can't justify verifying the download in an unprivileged, sandboxed process - I'd like to do it, but I don't see a benefit). a) Microsoft Windows i) Layer read-only filesystem on top of install dir, prevents presistant modifications b) Mac OS X i) Seatbelt profile prevents write access of app binaries c) GNU/Linux i) Mount namespace provides read-only access of install dir ii) Mount namespace does not include launcher binaries d) Android i) If App was installed using a App Store, then that is responsible for updating ii) If the app was installed by the user (side-loaded), then the we can isolate downloading into a separate process, and then verification can be handled in an isolated process. Finally, the Android Package Manager controls installing the update. 6) Usable Unfortunately, despite the above suggestions, this sandboxing model fails if users find its unusable. In particular, with temporary file systems, we should provide a method for safely extracting a file from the temporary location and copying it to a permanent location using the launcher process. In addition, exposing operating system functionality which may be fingerprintable and/or another attack vector should be optional if it unbreaks the web (such as providing pulseaudio on Linux[26]). As usual. we must be careful about giving users too many customizable switches. 7) Cross-Origin Fingerprinting Unlinkability I've less experience here on non-Linux OS (and Sandboxed Tor Browser is already a good base on Linux). Which other components should we consider spoofing (if possible) or go out of our way and disallow access (if not possible using the above means)? [0] https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux [1] https://www.mozilla.org/en-US/firefox/60.0esr/system-requirements/ [2] https://support.mozilla.org/en-US/kb/will-firefox-work-my-mobile-device [3] https://msdn.microsoft.com/en-us/library/bb625963.aspx [4] https://github.com/Microsoft/dotnet-computevirtualization/blob/master/src/M… [5] https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-p… [6] https://docs.microsoft.com/en-us/previous-versions/windows/apps/hh464936(v=… [7] https://developer.apple.com/library/archive/documentation/Security/Conceptu… [8] https://help.apple.com/xcode/mac/current/#/dev88ff319e7 [9] https://developer.apple.com/library/archive/documentation/Security/Conceptu… [10] https://trac.webkit.org/browser/webkit/releases/Apple/Safari%2011.1.1/WebKi… [11] https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing… [12] https://wiki.mozilla.org/Security/Sandbox#OSX [13] https://dxr.mozilla.org/mozilla-central/source/security/sandbox/mac/Sandbox… [14] https://github.com/projectatomic/bubblewrap [15] https://developer.android.com/reference/android/Manifest.permission [15] https://developer.android.com/guide/topics/manifest/service-element#isolated [16] https://www.torproject.org/projects/torbrowser/design/ [17] https://docs.microsoft.com/en-us/windows/desktop/FWP/windows-filtering-plat… [18] https://docs.microsoft.com/en-us/windows/desktop/FWP/permitting-and-blockin… [19] https://docs.microsoft.com/en-us/virtualization/windowscontainers/container… [20] https://github.com/Microsoft/hcsshim/blob/master/internal/hns/namespace.go#… [21] https://developer.apple.com/library/archive/documentation/Miscellaneous/Ref… [22] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/… [23] https://github.com/Microsoft/hcsshim/blob/master/internal/wclayer/createlay… [24] https://github.com/Microsoft/hcsshim/blob/master/internal/wclayer/createscr… [25] https://developer.apple.com/library/archive/documentation/Security/Conceptu… [26] https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux#…

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev July 2018