On 30 June 2014 11:24, intrigeri <intrigeri@???> 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
