Toolship: A more secure workstation

The best answer to keeping your workstation clean &amp; secure is, in my view, a thin-client paired with ephemeral remote environments:<p>Immutable or chain-of-trust based host OS (e.g. nix or iOS)<p>Minimal software installed (including docker, which itself is heavy and full of vulns or opens the door to them)<p>Do everything on ephemeral remote environments where the configuration is stored in reviewable tools (e.g. GitHub) and the state can be wiped at will. This means you reduce your surface area for persistent malware to supply chain and network attacks, which require careful practices to avoid but which are well-understood<p>Remote envs are preferred to local virtualization (e.g. quebes) because they lend themselves to team use and sharing more, and so are more likely to be widely adopted and collectively improved. Also easier to create different hardware configurations as needed (when you need a bigger GPU temporarily), as well as different environment types - e.g. always-on previews for QA testing. Also eliminates persistent paths in the local OS for malware storage

Your workstation will never be secure. Ever. It&#x27;s not possible. Give up and work to implement zero trust. Ephemeral environments like CI&#x2F;CD are not inherently secure because they&#x27;re ephemeral either.

Interesting approach to maintaining a clean dev environment using containers. This approach reminds me of Fedora Silverblue[1] that I’ve been wanting to try. It leverages OSTree for atomic upgrades and rollbacks. Users can run containers for CLI utils using toolbox[2]. This way, the base OS remains pristine, and there&#x27;s less risk of &quot;dependency hell&quot; or inadvertent “package upgrades gone wrong”.<p>[1]: <a href="https:&#x2F;&#x2F;fedoraproject.org&#x2F;silverblue&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;fedoraproject.org&#x2F;silverblue&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;docs.fedoraproject.org&#x2F;en-US&#x2F;fedora-silverblue&#x2F;toolbox&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.fedoraproject.org&#x2F;en-US&#x2F;fedora-silverblue&#x2F;toolb...</a>

Docker seems a bit unwieldy for this use case. Given it runs in a Linux VM on macOS, wouldn&#x27;t all these commands have considerable overhead?<p>On Linux, the pledge utility[1] seems like a better fit for this. I&#x27;m not aware of what the macOS alternative would be, but considering this functionality stems from OpenBSD, maybe it can be ported to Darwin?<p>[1]: <a href="https:&#x2F;&#x2F;justine.lol&#x2F;pledge&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;justine.lol&#x2F;pledge&#x2F;</a>

You might enjoy <a href="https:&#x2F;&#x2F;github.com&#x2F;jessfraz&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;.dockerfunc">https:&#x2F;&#x2F;github.com&#x2F;jessfraz&#x2F;dotfiles&#x2F;blob&#x2F;master&#x2F;.dockerfunc</a> I think she had an article about this as well.

I would also recommend looking into NixOS reproducible builds, which allows declaratively specifying the entire system configuration and precisely defining which packages are installed, their versions, and dependencies. The OS remains immutable and consistent. A quite powerful tool for creating a secure and minimalistic workstation environment.<p><a href="https:&#x2F;&#x2F;nixos.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;nixos.org&#x2F;</a>

A more extreme version of this would be to install something like Prox-mox on a machine (doesn&#x27;t have to be the actual machine you&#x27;re using, but probably could be) instead of the standard OS, and then create virtualized containers for each &quot;use case&quot; (and then use good security practices on each containerized OS as well of course).<p>Setup correctly, if any one container was to get compromised, it shouldn&#x27;t leak out to anywhere of the other ones. Would be super inconvenient, I&#x27;m guessing to actually have a semblance of efficiency there would still likely be a &quot;main&quot; container and you&#x27;d SSH into others in order to do tasks associated with that container. Not too much different than the &quot;clean OS&quot; described here, probably the helper scripts could be similarly adapted to utilize the individual containers instead of docker containers.<p>I personally would be hard pressed to consider something like that, but seems like the logical continuation of this type of machine configuration&#x2F;setup.

I was nodding along until it became clear the Docker containers were being run as root...

I think if I were going to the trouble of dockerizing and isolating all my tools, I wouldn’t want to rely on someone else’s registry of dockerfiles.<p>This reminds me a lot of the cycle of sandboxing:<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2044&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;xkcd.com&#x2F;2044&#x2F;</a>

I dream of situation where I&#x27;d be developing software on plain Debian Stable with nothing else needed. It is already an immense platform so it does feel bit ridiculous that I&#x27;d <i>truly</i> need much more than that.

I have written dew (<a href="https:&#x2F;&#x2F;github.com&#x2F;efrecon&#x2F;dew">https:&#x2F;&#x2F;github.com&#x2F;efrecon&#x2F;dew</a>) for more or less the same purpose. I hardly keep any binary (and dependency) in my installation, they are all inside containers that I can easily dispose of at any time. The default in dew is to run them as your user. At the command prompt, instead of running, for example, kubectl xxx, I run dew kubectl xxx. It&#x27;s a bit slower but provides an increased level of security.

I have the same concern. Something might be worth looking into is replacing docker with Podman because it runs as the authenticated user rather than using a daemon running as root. Also, I believe Podman desktop allows for multiple VMs.<p>Also consider QubesOS. Where everything runs in a VM (if you can find appropriate hardware on which to run it).<p>Less flexible but easier to install is ChromeOS FLEX (or a high end Chromebook). Like QubesOS, ChromeOS lets you run Linux in a VM but with the ability to open native windows.

I understand the benefits of VM&#x2F;Docker based isolation. But, how to efficiently share data across boundaries and still stay protected? How can a development VM protect against malicious NPM packages that steal sensitive data (e.g., secrets&#x2F;keys&#x2F;confidential code needed for development and present inside the VM)? Am I missing something here?

I do this for years. but instead of docker I use LXD (even for GUI stuff). my base system is always clean and idempotent (chezmoi). all my clients look the same. laptop, desktop workstation, etc.<p>I even have a portable LXD environment which always looks the same, on a USB flash drive. wherever I go, I have the same environment.

Anyone see a reason this couldn’t work for a fully “remote” dev environment, if the Docker daemon were running somewhere else?

I have been thinking how to work with multiple users in a convenient way. The problem is that file permissions causes problems when you want to switch between users. I have not found a really ideal way of working using different users, but I think it needs some approach, I just haven&#x27;t found it yet.

WSL is quite good for this type of thing.

Firejail can also be a useful option, though no good if you&#x27;re on Mac <a href="https:&#x2F;&#x2F;firejail.wordpress.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;firejail.wordpress.com&#x2F;</a><p>Uses the same Linux primitives as docker etc, but can be a bit more ergonomic for this use case

Reminder: Docker Hub image tags are not cryptographically secure. They can be replaced by DockerHub or their colo or government at any time.<p>You need something like org&#x2F;image@sha256:&lt;hash&gt; instead.

Workstation security is definitely in the category of things I&#x27;ll only vaguely pretend to care about if you&#x27;re paying me.

The favicon of the site looks like familiar.

Docker is not a trust boundary CMV