This allows a jail to have a VPN config associated and as a result we start
a new net namespace, completely isolating the jails networking.
We then start an openVPN client to route between the main network and the
jails' network.
The main limitation here is that we don't setup DNS, which basically means
that the VPN will route DNS calls to the other side, but since we don't
remount resolv.conf this depends on the vpn provider actually mapping the
nameserver we use. For people that use a nameserver like 192.168.100.1,
this most of the time works just fine.
Improvement is possible.
This code now no longer makes tmpfs based mounts NOEXEC.
This was an optimization that didn't really add anything anyway
since those tmpfs would all be default be local to the jail anyway,
making any executable being placed there invisible to the rest
of the system. So what were we protecting?
For apps that use shell we every now and then saw zombies appear as a
child of the jailer process. Presumably the shall re-parented those to
process 1, which is our jailer inside the jail.
This adds a forever loop to simply call wait() repeatedly which clears
the state (makes clear we don't care about their state, really) and thus
removes the zobie processes.
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.
We resolve a symlink to an exe now only at the time we start the
application, avoiding the target being the one ending up in the config
file instead of the symlink.
The same now happens with the insertion of '/shared/' in the path
should the (resolved) exe path be in the users' homedir.
The audio permission allows hiding of pulse audio and pipewire sockets.
The kde session (ksmserver) socket and state files allowing some more
apps to run properly.
When starting a new application for the first time you can
start them with these two feature.
Autodelete:
this waits until the iso-pipe file is removed by the jailer,
which it does when all processes stopped,
and then proceeds to remove all files for the jail.
Secure:
Puts all known rights in the 'denied' list, making the jail
quite secure. Not a VM or a docker, but close.
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.
When the profile has an init-script, we execute that with bash _before_
the actual executable is started.
This allows things like preparing the jail for a fresh run every time.
Notice that adding a second app in the same running jail skips the init
script.
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.
We re-route the dbus socket to a different location and then start
the dbus proxy in order to provide a filtered view of the world for our
jailed application.
DBus is a fantastic and a horrible system at the same time. It provides
only basic concepts and features which others can build on top of. Which
is great as many have done that building on top of it.
Unfortunately many apps have completely missed the idea of security and
hierarchy so its a mess now and you can't really open up most to apps...
Favourite stupid design, the org.freedesktop.Notifications has under
there the 'klipper' app. With an endpoint to destroy all its historical
data. Making 'just open the notifications, what could go wrong' end with
pain.
tomFlowee