Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toolship: A more secure workstation

yann.pt

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Toolship: A more secure workstation

#31

Post by speed_spread »

mr-karan wrote: post #12

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://fedorapr…

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.

Re: Toolship: A more secure workstation

#32

Post by ar_lan »

yjftsjthsd-h wrote: post #27
LocalPCGuy wrote: post #25

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…

So https://www.qubes-os.org/ ?

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

Re: Toolship: A more secure workstation

#33

Post by kjok »

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?

Re: Toolship: A more secure workstation

#34

Post by m463 »

LocalPCGuy wrote: post #25

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…

I think the killer app for proxmox would be integrating docker or podman as a first-order feature.

Right now you can set up a VM or an LXC container. In comparison to docker/podman, LXC is more like being a sysadmin.

Re: Toolship: A more secure workstation

#35

Post by zoomzoom »

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

Re: Toolship: A more secure workstation

#36

Post by efrecon »

sneak wrote: post #20

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

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.

Re: Toolship: A more secure workstation

#37

Post by efrecon »

I have written 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.

Re: Toolship: A more secure workstation

#38

Post by adamckay »

kjok wrote: post #33

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?

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

Re: Toolship: A more secure workstation

#39

Post by _joel »

ar_lan wrote: post #32
yjftsjthsd-h wrote: post #27

Earlier quoted context omitted.

So https://www.qubes-os.org/ ?

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

Proxmox isn't a hypervisor (last time I checked!), it's a management plane to different hypervisors.
Post reply on HN