Hi,
while discussing opportunities for increased cooperation between Tails and Freepto [1] recently, I've mentioned the upcoming Tor Browser's self-updater, and one of the Freepto developers rightly noted that there may be a fundamental incompatibility between this updater, and the desire to confine the browser in a sandbox. Indeed, it seems quite clear to me that one of the important tasks such a sandbox should fulfill would be... to avoid the confined program from modifying itself.
It seems that supporting such sandboxes is part of your plans ([2], [3]), so I'm curious: what's the TBB team's take on this problem?
[1] http://www.freepto.mx/ [2] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorP [3] https://trac.torproject.org/projects/tor/ticket/5791
Cheers,
On 30 June 2014 11:24, intrigeri intrigeri@boum.org wrote:
Indeed, it seems quite clear to me that one of the important tasks such a sandbox should fulfill would be... to avoid the confined program from modifying itself.
This is not as clear to me. The traditional purpose of a sandbox is to confine a program from performing tasks it should not. These would fall into categories like opening files it shouldn't, attempting IPC calls, writing files it shouldn't, making network connections to locations it shouldn't, or make system calls it shouldn't.
Preventing a program from modifying itself is a distinct problem. Obviously, a program can rewrite itself in memory and as long as it is executing, it has modified itself in way it likes (it will still be sandbox-constrained though). It could even modify itself to 'hide' itself from the UI or the OS to whatever extent the sandbox allows it (this would probably be just hiding the UI, the sandbox is unlikely to allow anything else) so when you think you've closed it, you haven't.
Trying to prevent an application from modifying itself on disk, so that the changes persist after application shutdown, _could_ be achieved by a sandbox - but it would have to be taken on a case-by-case basis. Considering Tor Browser, the sandbox could probably, easily, enforce read-only access to executables and libraries. But I'm not sure how many things the 'New Identity' button wipes out. If it doesn't wipe out everything, there are persistence mechanisms between application executions that the sandbox _should_ allow. For example, if installed extensions persist between 'New Identity' - that's allows arbitrary code execution (inside the sandbox). It could change the entry guards, hardcode an exit, install a theme, plant cookies (are they erased on startup _and_ shutdown? I don't know), or change the homepage.
It sounds more like you want application imaging. You want to be able to say "On application startup, I want to be rolled back to a known-good installation of the application without any 'cruft' that may have accumulated". If you're willing to sacrifice all customizations (including guards) made, then all the auto-updater would need to do would be to provide a signed manifest so that you can verify the signature of all files present, and remove any files not in that manifest. With some shell scripting, you can have an auto-updating application that rolls back to a known good state on start.
-tom
Hi,
Tom Ritter wrote (30 Jun 2014 17:03:49 GMT) :
Preventing a program from modifying itself is a distinct problem.
Point taken.
Trying to prevent an application from modifying itself on disk, so that the changes persist after application shutdown, _could_ be achieved by a sandbox - but it would have to be taken on a case-by-case basis. Considering Tor Browser, the sandbox could probably, easily, enforce read-only access to executables and libraries. But I'm not sure how many things the 'New Identity' button wipes out. If it doesn't wipe out everything, there are persistence mechanisms between application executions that the sandbox _should_ allow. For example, if installed extensions persist between 'New Identity' - that's allows arbitrary code execution (inside the sandbox).
Indeed, the sandbox I have in mind would grant write access to Data/Browser/profile.default/extensions, and given the potential for persisting arbitrary code in there, it makes little sense to block write access to other programs and libraries shipped by the bundle.
It could change the entry guards, hardcode an exit, [...]
Yep, I guess that's correct due to the fact the browser (when using tor-launcher) needs to be allowed to control Tor directly.
It sounds more like you want application imaging. [...]
Thanks for the detailed analysis!
Cheers,
-
intrigeri -
Tom Ritter