When a jail is encryted at rest using 'encfs' we detect that and ask for
a password upon starting the jail.
This sounded like a neat little idea which ended up taking nearly 4 days
to do...
EncFS needs to be running as root, as it is a FUSE system and it will
actually stop root from reading/writing files if it is running as a
user. It also is very picky about not running in a namespace, it manages
to hang indefinitely otherwise where a shutdown can't complete because
the process doesn't want to die :-)
So, it runs as root, takes the password via a pipe and we have a
watchdog proces to kill it when the jail is shut down.
The pipe was always there, but we didn't really use it so far.
This now uses the pipe to send back the PID of the 'jailer' which we
store in a 'state' file.
After introducing a new process that dispatches new processes _inside_
the jail, there is no point leaving the root owned 'runner' in memory.
So we move its functionality to the new mini-dispatcher (since renamed
to jailer) and remove it from the tree.
When a request comes for a profile that already has someone running,
we now send a message to that jail and make them run the second
application in there directly.
The basis here is that it is impossible to recreate the 'jail' exactly
with things like tmpfs. So requests like "start a new firefox window in
the same process" need to actually run in the jail we created before.
So due to that I leave a process that I call 'mini-dispatch' which
itself lives inside of the jail, so it can trivially exec a new process
there.
The defaults are not 'secure', as they would be annoying to the max.
This is an isolation runner, removing a lot of attack vectors, for sure
but the name would give the wrong impression with defaults like we have
now.
Added plenty of small docs.
Changed the message to be pre-fixed with a message-size in order to allow
us to get interrupted on read() and know
if we need to read more.
Also fixes the bug that the server shuts down after one process as
reported by some.
Starting this tool will now allow one to
- use dbus to request the running of an executable
- the tool creates assigns a userId and creates
a dir in like /data/1100
- a tiny priviledged part changes ownerhip of that dir
to the chosen userId.
- it also runs the executable in that dir with this uid.
The effect is that no applications or users (without root)
can read the private files from those apps and they can't
read them from each other.
Running them as different users additionally means all the
standard protections apply and RPC is private between
components of one app.
For instance useful if you have a neochat daemon that listens to the
network while the main app may or may not be running. All using the same
UID naturally.
tomFlowee