Each container, by default, runs in a separate network namespace. You can use docker CLI to create specific networks that can be shared with other containers, or use docker-compose for it. Technically, for processes outside containers you can still use the same network of that container by running the inside the network namespace of the ‘VPN’ container (for example running them with unshare). However, I wouldn’t recommend this, as containers are supposed to run mostly isolated workload and not for this kind of use-case. But yeah, technically it’s feasible.
It’s the de-facto standard for runtime container security (sysdig is based on it). The only competitor afaik is aqua security’s tracee, which is way less mature. It is very well supporter, there are tons of rules maintained by the community and it is a CNCF project used by enterprise solutions (I.e., shouldn’t disappear overnight).
build the image properly, or use good images. This means limit dependencies as much as possible, as minimal images as possible (less updates due to CVEs, less tooling).
do not mount host volumes, if you really have to, use a dedicated subpath owned by the user of the container. Do not use homedirs etc.
do not run in host namespaces, like host network etc. Use port mapping to send traffic to the container.
If you want to go hardcore:
analyze your application, and if feasible, build and use a more restrictive seccomp profile compared to the default. This might limit additional syscalls that might be used during an exploitation but that your app doesn’t need.
run falco on the node. Even with the default set of rules (nothing custom), many exploitation or posts-exploitation steps would be caught, such as “shell spawned” etc.
I don’t think it’s you, it generally is a bad practice to have multiple processes inside a container. It usually defeats most of the isolation, introduces problems with handling zombie processes (therefore you need an init) and restarting tools when they crash (then you need something like supervisord, which I guess this image might use - I didn’t check). Each software adds dependencies, which can conflict (again defeating the idea of containers), and of course CVEs. Then you have a problem with users etc.
So yeah, containers are generally not meant to be used this way. The project might be cool but I would be very uncomfortable running it like this, especially if that’s going to be my primary email, with all the password resetting capabilities etc.
If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.
Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).
In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.