11 ms·

Toolship: A more secure workstation

68 points by yapret 3y ago

zokier 3y ago
I dream of situation where I'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'd truly need much more than that.
coreyh14444 3y ago
WSL is quite good for this type of thing.
- ritchiey 3y ago
  WSL probably is good but I believe it still has access to the whole Windows file system. Linux on ChromeOS is probably better because its file system is separate. Files and directories must be explicitly shared from the main OS. I think both have the ability to open windows on the main desktop so you can run graphical IDEs and the like in the VM which is nice.
  - chris37879 3y ago
    The filesystem access is optional and can be removed, WSL2 is actually a fairly nice implementation of a linux sandbox that can be used like it's just running alongside windows. I think your concern is valid for WSL1, where the seperation is managed by a Microsoft provided Windows driver, but WSL2 is just a VM with dynamic memory allocation, so you can lock it down basically as well as any other Hyper-V VM, it just has a lot of integrations enabled by default.
screamingninja 3y ago
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. https://nixos.org/ https://nixos.org/
- aliasxneo 3y ago
  You can also use Nix/Home Manager to manage your Mac (what the author is using). I used NixOS for a few months as a VM and then eventually just switched back to my Mac. Couldn't stand all of the hacks that were needed to get software to behave the way Nix expected them (i.e., JIT binaries not dynamically linked to /nix/store).
  - pxc 3y ago
    Nix-Darwin is nice module system for macOS as well. It's a bit older than Home Manager, and also supports configuring some macOS-specific and systemwide settings.
DavyJone 3y ago
You might enjoy https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc I think she had an article about this as well.
- llimllib 3y ago
  https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ https://blog.jessfraz.com/post/docker-containers-on-the-desk... is the one I remember, a bit old but still useful to see how she does it. Seems super painful and indirected for a nebulous gain to me, but find your joy however you want I guess
skywhopper 3y ago
I was nodding along until it became clear the Docker containers were being run as root...
- mr-karan 3y ago
  Since the author of this post is making efforts to bind mount specific directories, is that still a legit risk? root inside the container isn’t essentially the same root on host. But yes, UID and GID mappings along with user namespacing will be better.
  - soraminazuki 3y ago
    But you have to be root outside of the container to run Docker. Which means the author has to run every single little command as root. That violates the principle of least privilege, increases the potential damage caused by bugs or mistakes, and therefore is a very legit risk. Also notice how the shell snippets in the article doesn't use sudo to run docker. That indicates that the author probably added their user to the docker group, which is equivalent to always logging in as root. That's terrible, terrible security practice. I can't agree that root inside the container is different from root on the host, either. The kernel makes no such distinction unless user namespacing is enabled. When containerized processes gain access to host resources, whether intentional or not, they'll have the same level of access as root on the host.
    - mr-karan 3y ago
      Noted. Yep, valid points. Thanks for explaining!
ssfrr 3y ago
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. This reminds me a lot of the cycle of sandboxing: https://xkcd.com/2044/ https://xkcd.com/2044/
ritchiey 3y ago
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. Also consider QubesOS. Where everything runs in a VM (if you can find appropriate hardware on which to run it). 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.
mr-karan 3y ago
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's less risk of "dependency hell" or inadvertent “package upgrades gone wrong”. [1]: https://fedoraproject.org/silverblue/ https://fedoraproject.org/silverblue/ [2]: https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...
- smallerfish 3y ago
  I have silverblue on a laptop, but hadn't poked about sufficiently yet. Toolbox looks great. Thanks for pointing it out.
- speed_spread 3y ago
  I use Silverblue and it works like a charm. The only problem I found is that you need to install your IDE locally instead of using a Flatpak to be able to launch it from within a toolbox. Also, toolboxes can not be upgraded across major versions (eg Fedora 37 -> 38) and have to be recreated instead.
- eaglefield 3y ago
  I'm running silverblue but running my containers through distrobox. Both toolbox and distrobox are running on podman under the hood, so it's the same technology as far as I understand. However, distrobox has some interesting features relevant to this idea of development isolation. One is that it has an assemble feature[1] built-in. Where you can feed it a recipe file and it will build or rebuild containers accordingly. The other is that it allows setting a custom home directory for the container, among other host/container isolating options[2]. Perfomance wise my containers take a couple MB of rams and no perceptible CPU usage when not in use. At least as far as I can tell. [1] https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md https://github.com/89luca89/distrobox/blob/main/docs/usage/d... [2] https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-create.md https://github.com/89luca89/distrobox/blob/main/docs/usage/d...
Ancapistani 3y ago
Anyone see a reason this couldn’t work for a fully “remote” dev environment, if the Docker daemon were running somewhere else?
imiric 3y ago
Docker seems a bit unwieldy for this use case. Given it runs in a Linux VM on macOS, wouldn't all these commands have considerable overhead? On Linux, the pledge utility[1] seems like a better fit for this. I'm not aware of what the macOS alternative would be, but considering this functionality stems from OpenBSD, maybe it can be ported to Darwin? [1]: https://justine.lol/pledge/ https://justine.lol/pledge/
- orangea 3y ago
  Mac doesn't have seccomp so no. The functionality could be implemented but it would have to use a completely different mechanism.
tedajax 3y ago
Workstation security is definitely in the category of things I'll only vaguely pretend to care about if you're paying me.
jan_Sate 3y ago
The favicon of the site looks like familiar.
mongol 3y ago
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't found it yet.
- yjftsjthsd-h 3y ago
  Does group membership not help?
  - mongol 3y ago
    It can help a bit but it is still complex.
sneak 3y ago
Reminder: Docker Hub image tags are not cryptographically secure. They can be replaced by DockerHub or their colo or government at any time. You need something like org/image@sha256:<hash> instead.
- efrecon 3y ago
  You are entirely right. Problem with the sha256 is that you kind of need a comment pointing to the proper tag (at the time of generation). It gets tedious with time.
lijok 3y ago
Your workstation will never be secure. Ever. It's not possible. Give up and work to implement zero trust. Ephemeral environments like CI/CD are not inherently secure because they're ephemeral either.
- yjftsjthsd-h 3y ago
  If we assume a workstation compromise, why would we trust the zero trust infrastructure that was set up with that workstation?
  - lijok 3y ago
    You can't trust it. One of the first real lessons security work teaches you is that nothing can ever be perfectly secure, it's all about achieving a level of security that is appropriate given your threat model, and gives you enough confidence to be able to sleep at night. There's steps you can take that involve incredibly secure procurement processes of air gapped devices, but even that will not prove absolute security.
LocalPCGuy 3y ago
A more extreme version of this would be to install something like Prox-mox on a machine (doesn't have to be the actual machine you're using, but probably could be) instead of the standard OS, and then create virtualized containers for each "use case" (and then use good security practices on each containerized OS as well of course). Setup correctly, if any one container was to get compromised, it shouldn't leak out to anywhere of the other ones. Would be super inconvenient, I'm guessing to actually have a semblance of efficiency there would still likely be a "main" container and you'd SSH into others in order to do tasks associated with that container. Not too much different than the "clean OS" described here, probably the helper scripts could be similarly adapted to utilize the individual containers instead of docker containers. I personally would be hard pressed to consider something like that, but seems like the logical continuation of this type of machine configuration/setup.
- yjftsjthsd-h 3y ago
  So https://www.qubes-os.org/ https://www.qubes-os.org/ ?
  - ar_lan 3y ago
    They are similar, but Qubes is more targetted at the end user - proxmox is more traditionally used as the hypervisor for distributed applications. You can probably achieve the same goals with either though (barring differences in Xen and KVM).
    - _joel 3y ago
      Proxmox isn't a hypervisor (last time I checked!), it's a management plane to different hypervisors.
      - LocalPCGuy 3y ago
        > Proxmox is an open-source, Type 1 hypervisor that comes as a Debian-based Linux distribution. With Proxmox, users can experience a hypervisor that can integrate Linux containers (LXC) and KVM hypervisor, networking functionality, and software-defined storage in a unified platform. I'm not saying you are wrong entirely - it can be used as a management plane for different hypervisors, but it is also a hypervisor in it's own right as I understand it. (grabbed the quote above from ServerWatch). There is a lot of confusion about this topic as some people argue it isn't a type 1 because it goes through KVM, but others rebut that because KVM is in the kernel and has direct hardware access (very gross summary of arguments I barely know enough about to keep up, and sometimes don't).
kjok 3y ago
I understand the benefits of VM/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/keys/confidential code needed for development and present inside the VM)? Am I missing something here?
- adamckay 3y ago
  No, I don't think you're missing anything, other than you'd only mount the directories you want the tool / development environment to have access to. Take for instance the `npm` command [1], it mounts `$PWD` so if you install a compromised package then it can go through the folder you're in, but it can't then go up directories and sniff around your home directory. It would also only have access to the environment variables that have been configured for the container, which in this case would also include AWS credentials. 1 - https://github.com/yapret/toolship/blob/main/src/node/functions.zsh https://github.com/yapret/toolship/blob/main/src/node/functi...
  - kjok 3y ago
    Makes sense. However, to be able to use packages installed in $PWD (compatibility), the Docker image must be an exact replica of the host (e.g., same node version, same libs such as libcrypto) Besides, bins installed under ~/.local or /usr/local during "npm install" are not available outside the Docker image.
- aloer 3y ago
  It looks like you are focussing on business secrets and, while important, at least for me my main concern would be personal secrets on personal hardware that I am also doing side projects on. A business today can reduce the blast radius by quite a lot with separate laptops ("customer/project laptop"), sample data and restricted/time limited access to production data. In an ideal world no npm dependency could affect my online banking, icloud photo library or private messengers.
zoomzoom 3y ago
The best answer to keeping your workstation clean & secure is, in my view, a thin-client paired with ephemeral remote environments: Immutable or chain-of-trust based host OS (e.g. nix or iOS) Minimal software installed (including docker, which itself is heavy and full of vulns or opens the door to them) 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 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
- hulitu 3y ago
  > The best answer to keeping your workstation clean & secure ... > Immutable or chain-of-trust based host OS (e.g. nix or iOS) Pegassus ? Did you notice that Apple fixes vulnerabilities only after they are find by third parties ?
efrecon 3y ago
I have written dew (https://github.com/efrecon/dew https://github.com/efrecon/dew) 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's a bit slower but provides an increased level of security.
mnahkies 3y ago
Firejail can also be a useful option, though no good if you're on Mac https://firejail.wordpress.com/ https://firejail.wordpress.com/ Uses the same Linux primitives as docker etc, but can be a bit more ergonomic for this use case
surfer7837 3y ago
Docker is not a trust boundary CMV
omani 3y ago
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. 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.

68 points by yapret 3y ago

I dream of situation where I'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'd truly need much more than that.

coreyh14444 3y ago

WSL is quite good for this type of thing.

ritchiey 3y ago
WSL probably is good but I believe it still has access to the whole Windows file system. Linux on ChromeOS is probably better because its file system is separate. Files and directories must be explicitly shared from the main OS. I think both have the ability to open windows on the main desktop so you can run graphical IDEs and the like in the VM which is nice.
- chris37879 3y ago
  The filesystem access is optional and can be removed, WSL2 is actually a fairly nice implementation of a linux sandbox that can be used like it's just running alongside windows. I think your concern is valid for WSL1, where the seperation is managed by a Microsoft provided Windows driver, but WSL2 is just a VM with dynamic memory allocation, so you can lock it down basically as well as any other Hyper-V VM, it just has a lot of integrations enabled by default.

screamingninja 3y ago

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. https://nixos.org/ https://nixos.org/

aliasxneo 3y ago
You can also use Nix/Home Manager to manage your Mac (what the author is using). I used NixOS for a few months as a VM and then eventually just switched back to my Mac. Couldn't stand all of the hacks that were needed to get software to behave the way Nix expected them (i.e., JIT binaries not dynamically linked to /nix/store).
- pxc 3y ago
  Nix-Darwin is nice module system for macOS as well. It's a bit older than Home Manager, and also supports configuring some macOS-specific and systemwide settings.

DavyJone 3y ago

You might enjoy https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc I think she had an article about this as well.

llimllib 3y ago
https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ https://blog.jessfraz.com/post/docker-containers-on-the-desk... is the one I remember, a bit old but still useful to see how she does it. Seems super painful and indirected for a nebulous gain to me, but find your joy however you want I guess

skywhopper 3y ago

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

mr-karan 3y ago
Since the author of this post is making efforts to bind mount specific directories, is that still a legit risk? root inside the container isn’t essentially the same root on host. But yes, UID and GID mappings along with user namespacing will be better.
- soraminazuki 3y ago
  But you have to be root outside of the container to run Docker. Which means the author has to run every single little command as root. That violates the principle of least privilege, increases the potential damage caused by bugs or mistakes, and therefore is a very legit risk. Also notice how the shell snippets in the article doesn't use sudo to run docker. That indicates that the author probably added their user to the docker group, which is equivalent to always logging in as root. That's terrible, terrible security practice. I can't agree that root inside the container is different from root on the host, either. The kernel makes no such distinction unless user namespacing is enabled. When containerized processes gain access to host resources, whether intentional or not, they'll have the same level of access as root on the host.
  - mr-karan 3y ago
    Noted. Yep, valid points. Thanks for explaining!

ssfrr 3y ago

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. This reminds me a lot of the cycle of sandboxing: https://xkcd.com/2044/ https://xkcd.com/2044/

ritchiey 3y ago

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. Also consider QubesOS. Where everything runs in a VM (if you can find appropriate hardware on which to run it). 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.

mr-karan 3y ago

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's less risk of "dependency hell" or inadvertent “package upgrades gone wrong”. [1]: https://fedoraproject.org/silverblue/ https://fedoraproject.org/silverblue/ [2]: https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/ https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...

smallerfish 3y ago
I have silverblue on a laptop, but hadn't poked about sufficiently yet. Toolbox looks great. Thanks for pointing it out.
speed_spread 3y ago
I use Silverblue and it works like a charm. The only problem I found is that you need to install your IDE locally instead of using a Flatpak to be able to launch it from within a toolbox. Also, toolboxes can not be upgraded across major versions (eg Fedora 37 -> 38) and have to be recreated instead.
eaglefield 3y ago
I'm running silverblue but running my containers through distrobox. Both toolbox and distrobox are running on podman under the hood, so it's the same technology as far as I understand. However, distrobox has some interesting features relevant to this idea of development isolation. One is that it has an assemble feature[1] built-in. Where you can feed it a recipe file and it will build or rebuild containers accordingly. The other is that it allows setting a custom home directory for the container, among other host/container isolating options[2]. Perfomance wise my containers take a couple MB of rams and no perceptible CPU usage when not in use. At least as far as I can tell. [1] https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md https://github.com/89luca89/distrobox/blob/main/docs/usage/d... [2] https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-create.md https://github.com/89luca89/distrobox/blob/main/docs/usage/d...

Ancapistani 3y ago

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

imiric 3y ago

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

orangea 3y ago
Mac doesn't have seccomp so no. The functionality could be implemented but it would have to use a completely different mechanism.

tedajax 3y ago

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

jan_Sate 3y ago

The favicon of the site looks like familiar.

mongol 3y ago

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't found it yet.

yjftsjthsd-h 3y ago
Does group membership not help?
- mongol 3y ago
  It can help a bit but it is still complex.

sneak 3y ago

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

efrecon 3y ago
You are entirely right. Problem with the sha256 is that you kind of need a comment pointing to the proper tag (at the time of generation). It gets tedious with time.

lijok 3y ago

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

yjftsjthsd-h 3y ago
If we assume a workstation compromise, why would we trust the zero trust infrastructure that was set up with that workstation?
- lijok 3y ago
  You can't trust it. One of the first real lessons security work teaches you is that nothing can ever be perfectly secure, it's all about achieving a level of security that is appropriate given your threat model, and gives you enough confidence to be able to sleep at night. There's steps you can take that involve incredibly secure procurement processes of air gapped devices, but even that will not prove absolute security.

LocalPCGuy 3y ago

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

yjftsjthsd-h 3y ago
So https://www.qubes-os.org/ https://www.qubes-os.org/ ?
- ar_lan 3y ago
  They are similar, but Qubes is more targetted at the end user - proxmox is more traditionally used as the hypervisor for distributed applications. You can probably achieve the same goals with either though (barring differences in Xen and KVM).
  - _joel 3y ago
    Proxmox isn't a hypervisor (last time I checked!), it's a management plane to different hypervisors.
    - LocalPCGuy 3y ago
      > Proxmox is an open-source, Type 1 hypervisor that comes as a Debian-based Linux distribution. With Proxmox, users can experience a hypervisor that can integrate Linux containers (LXC) and KVM hypervisor, networking functionality, and software-defined storage in a unified platform. I'm not saying you are wrong entirely - it can be used as a management plane for different hypervisors, but it is also a hypervisor in it's own right as I understand it. (grabbed the quote above from ServerWatch). There is a lot of confusion about this topic as some people argue it isn't a type 1 because it goes through KVM, but others rebut that because KVM is in the kernel and has direct hardware access (very gross summary of arguments I barely know enough about to keep up, and sometimes don't).

kjok 3y ago

I understand the benefits of VM/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/keys/confidential code needed for development and present inside the VM)? Am I missing something here?

adamckay 3y ago
No, I don't think you're missing anything, other than you'd only mount the directories you want the tool / development environment to have access to. Take for instance the `npm` command [1], it mounts `$PWD` so if you install a compromised package then it can go through the folder you're in, but it can't then go up directories and sniff around your home directory. It would also only have access to the environment variables that have been configured for the container, which in this case would also include AWS credentials. 1 - https://github.com/yapret/toolship/blob/main/src/node/functions.zsh https://github.com/yapret/toolship/blob/main/src/node/functi...
- kjok 3y ago
  Makes sense. However, to be able to use packages installed in $PWD (compatibility), the Docker image must be an exact replica of the host (e.g., same node version, same libs such as libcrypto) Besides, bins installed under ~/.local or /usr/local during "npm install" are not available outside the Docker image.
aloer 3y ago
It looks like you are focussing on business secrets and, while important, at least for me my main concern would be personal secrets on personal hardware that I am also doing side projects on. A business today can reduce the blast radius by quite a lot with separate laptops ("customer/project laptop"), sample data and restricted/time limited access to production data. In an ideal world no npm dependency could affect my online banking, icloud photo library or private messengers.

zoomzoom 3y ago

The best answer to keeping your workstation clean & secure is, in my view, a thin-client paired with ephemeral remote environments: Immutable or chain-of-trust based host OS (e.g. nix or iOS) Minimal software installed (including docker, which itself is heavy and full of vulns or opens the door to them) 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 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

hulitu 3y ago
> The best answer to keeping your workstation clean & secure ... > Immutable or chain-of-trust based host OS (e.g. nix or iOS) Pegassus ? Did you notice that Apple fixes vulnerabilities only after they are find by third parties ?

efrecon 3y ago

I have written dew (https://github.com/efrecon/dew https://github.com/efrecon/dew) 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's a bit slower but provides an increased level of security.

mnahkies 3y ago

Firejail can also be a useful option, though no good if you're on Mac https://firejail.wordpress.com/ https://firejail.wordpress.com/ Uses the same Linux primitives as docker etc, but can be a bit more ergonomic for this use case

surfer7837 3y ago

Docker is not a trust boundary CMV

omani 3y ago

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. 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.