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

41–50 of 59 posts

Re: Toolship: A more secure workstation

#41

Post by aloer »

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?

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.

Re: Toolship: A more secure workstation

#43

Post by pxc »

aliasxneo wrote: post #7
screamingninja wrote: post #4

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/

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

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.

Re: Toolship: A more secure workstation

#44

Post by kjok »

adamckay wrote: post #38
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 var…

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.

Re: Toolship: A more secure workstation

#45

Post by LocalPCGuy »

m463 wrote: post #34
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.

Yah, as I understand it (not a sysadmin, just hobby stuff), if you want to run something in docker, you'd have to setup the system first and then docker on top of that. I'm not sure you need the docker layer though - it's unnecessary overhead probably. Each VM/container could just have the necessary OS with the packages needed for that particular use case installed directly.

Guessing someone who tried to use a system like this would probably have their own custom containers / linux distributions, or at least have custom install scripts that would function much like the docker compose file does in getting everything installed on that container for different use cases.

Re: Toolship: A more secure workstation

#46

Post by LocalPCGuy »

_joel wrote: post #39
ar_lan wrote: post #32

Earlier quoted context omitted.

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.

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

Re: Toolship: A more secure workstation

#47

Post by ar_lan »

_joel wrote: post #39
ar_lan wrote: post #32

Earlier quoted context omitted.

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.

> Proxmox isn't a hypervisor

KVM is in the kernel, and I specifically called out KVM. If the point you are trying to make is that KVM is the hypervisor, then Qubes is also not a hypervisor because it uses Xen.

But this seems like a very strange distinction to make to me unless you are specifically trying to peer into the inner-workings. At that point you'd probably be saying ESXi is "not a hypervisor" because it has to defer the actual VM deployment to vmkernel.

I don't know of an OS without a kernel.

Re: Toolship: A more secure workstation

#48

Post by mongol »

yjftsjthsd-h wrote: post #26
mongol wrote: post #19

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.

Does group membership not help?

It can help a bit but it is still complex.

Re: Toolship: A more secure workstation

#49

Post by _joel »

ar_lan wrote: post #47
_joel wrote: post #39

Earlier quoted context omitted.

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

> Proxmox isn't a hypervisor KVM is in the kernel, and I specifically called out KVM. If the point you are trying to make is that KVM is the hypervisor, then Qubes is also not a hypervisor because it uses Xen. But this seems like a very strange distinction to make to me unless you are specifically trying to peer into the inner-workings. At that point you'd probably be saying ESXi is "not a hypervisor" because it has…

Proxmox can use a hypervisor, KVM, or manage containers. It's not a hypervisor. Xen is also hypervisor. Saying proxmox is a hypervisor is like saying virt-manager is a hypervisor.

Re: Toolship: A more secure workstation

#50

Post by ar_lan »

_joel wrote: post #49
ar_lan wrote: post #47

Earlier quoted context omitted.

> Proxmox isn't a hypervisor KVM is in the kernel, and I specifically called out KVM. If the point you are trying to make is that KVM is the hypervisor, then Qubes is also not a hypervisor because it uses Xen. But this seems like a very strange distinction to make to me unless you are specifically trying to peer into the inner-workings. At that point you'd probably be saying ESXi is "not a hypervisor" because it has…

Proxmox can use a hypervisor, KVM, or manage containers. It's not a hypervisor. Xen is also hypervisor. Saying proxmox is a hypervisor is like saying virt-manager is a hypervisor.

You're just debating semantics, debatably incorreectly, and for no reason. KVM is not a type-2 hypervisor in this case - Proxmox can be hosted on bare metal and use KVM natively.

> Saying proxmox is a hypervisor is like saying virt-manager is a hypervisor.

This is... just wrong? Proxmox is much more equivalent to ESXi than to a UI application.

--

To grante you the tiniest bit of good faith, I would wager that you and I are two heads of this specific coin.

An excerpt from Wikipedia on the matter (https://en.wikipedia.org/wiki/Hypervisor):

> The distinction between these two types is not always clear. For instance, KVM and bhyve are kernel modules[6] that effectively convert the host operating system to a type-1 hypervisor.[7] At the same time, since Linux distributions and FreeBSD are still general-purpose operating systems, with applications competing with each other for VM resources, KVM and bhyve can also be categorized as type-2 hypervisors.[8]

You seem very concerned that KVM (and thus Proxmox) cannot be considered a Type 1 Hypervisor. I disagree.

But if your assertion is that Proxmox cannot natively deploy VMs... then I have no idea what to tell you. You're blatantly wrong. Just try it.

Post reply on HN