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