> 2) Utilize some container runtime to provide isolation for legacy applications and stub out features such as filesystem calls so they do not to be aware of its existence.
I've been thinking about doing this on my laptop at work. With a bit of thought, it shouldn't be too hard to run for example software compilation or in fact most CLI/TUI tools using a minimal disk and network namespace using systemd or a container runtime.
Practically, this would allow me to put e.g. ever beloved NPM into a disk namespace where a ~/.ssh or even the .git of the repo it is in just doesn't exist and a network namespace in which the company VPN doesn't exist (or it just has a route for the NPM repository host). This can also be used to label the process using SELinux or apparmor as a second line of defense against and possibly after an escape of something bad.
However, time hasn't been available for this so far. And no, it wouldn't be end-user-friendly.
I've been thinking about doing this on my laptop at work. With a bit of thought, it shouldn't be too hard to run for example software compilation or in fact most CLI/TUI tools using a minimal disk and network namespace using systemd or a container runtime.
Practically, this would allow me to put e.g. ever beloved NPM into a disk namespace where a ~/.ssh or even the .git of the repo it is in just doesn't exist and a network namespace in which the company VPN doesn't exist (or it just has a route for the NPM repository host). This can also be used to label the process using SELinux or apparmor as a second line of defense against and possibly after an escape of something bad.
However, time hasn't been available for this so far. And no, it wouldn't be end-user-friendly.