Toolship: A more secure workstation
yann.pt
yann.pt
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
> 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 ?
There's steps you can take that involve incredibly secure procurement processes of air gapped devices, but even that will not prove absolute security.
[1]: https://fedoraproject.org/silverblue/
[2]: https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...
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/d...
[2] https://github.com/89luca89/distrobox/blob/main/docs/usage/d...
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?
Seems super painful and indirected for a nebulous gain to me, but find your joy however you want I guess
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.
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).
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.
> 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.
I've have, since late 2000's and used it to deploy production deployments for eden.sahanafoundation.org in Haiti, Chengdu and other places, using Proxmox and KVM.
I've also built public and private clouds using OpenNebula and OpenStack (using KVM/libvirt). I'm also vmware certified (or was, back in late 2000's, when working for a prominent UK ISP).
It's a management framework, it doesn't do virtualisation itself, it uses the libvirt framework. I can use the same kvm hypervisor by using qemu-kvm (or virt-manager, which uses the same stuff). Again it's just a management layer.
You’re trying to make the distinction KVM is separate - I’m saying KVM is a part of Proxmox making them functionally one and the same.
If you want to be very precise - KVM is the hypervisor. It just so happens to also be a part of the kernel! And Proxmox can also be run on bare metal hardware meaning - it can deploy and manage VMs with access to direct hardware management. As I already gave a reference to - this seems to be a common point people hit disagreement on, like we are precisely having at this moment.
Your nitpick is a muddying of waters in an attempt to “be superior” (and attaching your LinkedIn is pretty odd).
If you’re to be consistent, you’d also be saying ESXi is not a hypervisor - you’d say only vmkernel is. On a tight technicality this might be true, but it’s such a nitpick that unless you’re actively debugging in that layer of the stack the distinction is worthless.
I don’t think you and I will see eye to eye. You are so hyper focused on nitpicking a tiny definition that I’m not willing to concede on.
You told me to, "Try It". I have. Many times, I told you about them and you despite that you think I'm attaching a linked in. I'm answering the thing you told me.
Not sure what 'energy' you're going on about, if you reread this you might realise you're the one being a bit obtuse.
You're also making up stuff I might potentially say, whilst also admitting I'm probably right, which says a lot about you imho. Maybe work from the things people say, not what you think they say in your head.
I hope you find inner peace, but for reference, proxmox is a management layer using libvirt, which interacts with the hypervisor, KVM. Jeez...
Proxmox has KVM as part of its kernel. You're deliberately ignoring this fact. I've already expressly stated that KVM is the specific part that does the virtualization multiple times and you keep pretending I'm not.
> I'm not sure why you find this so difficult to understand.
I'm not?
> Not sure what 'energy' you're going on about, if you reread this you might realise you're the one being a bit obtuse.
You went out of your way to nitpick a comment I made about the differences in how Proxmox and Qubes OS are being used to say "you're wrong" about a detail that was not only irrelevant to the conversation.
Proxmox, ESXi, etc. are conventionally considered hypervisors.
> You're also making up stuff I might potentially say, whilst also admitting I'm probably right, which says a lot about you imho.
No, you don't know how to read. Let me take you back to first grade for a second.
What I said was that there is some dispute in over if KVM being a part of the kernel that helps constitute an OS makes the OS the hypervisor. I literally gave a reference to this distinction as well, and conceded that if you want to be very technically accurate, that KVM is the hypervisor.
What I'm saying is that KVM is a core part of Proxmox that enables it to function as a hypervisor, and you are going to deep ends to ensure everyone knows that my claim is 100% verifiably wrong even though it's semantics.
> Maybe work from the things people say, not what you think they say in your head.
Let's take a step back. I said:
"proxmox is more traditionally used as the hypervisor for distributed applications... (barring differences in Xen and *KVM*)"
to which you said:
"Proxmox isn't a hypervisor (last time I checked!), it's a management plane to different hypervisors."
In other words - "you're fucking wrong, it doesn't include a hypervisor at all". Which is:
a) Not what I said. I said it is used as the hypervisor. You’re not fucking installing Virtualbox on it. b) Intentionally ignoring the fact that I call out KVM in reference to it. What the hell? c) Inaccurate.
Let’s break it apart.
> it's a management plane to different hypervisors.
Source? I haven't seen any capability of Proxmox to integrate with Xen, vmkernel, Hyper-V, XCP-ng, etc.
It deeply integrates with KVM (which you seem to never address, as if accepting this fact is akin to Voldemort to you.
> It's a management framework, it doesn't do virtualisation itself, it uses the libvirt framework.
Not true. From a developer themselves: https://forum.proxmox.com/threads/how-hypervisors-like-proxm...
> I hope you find inner peace, but for reference, proxmox is a management layer using libvirt, which interacts with the hypervisor, KVM. Jeez...
Again, spreading lies.
I can do this all day with you. I don't think you're just wrong now, I think you're actively lying.
--
Or, you can stop being such a dick. I already gave you an out, which is that this specific topic is actively debated online - just like we are doing now. But instead, you went this route:
> whilst also admitting I'm probably right, which says a lot about you imho
So no, you're clearly a bad faith author. Imagine telling a VI Admin that ESXi is not the hypervisor.
Glad we cleared up that it's not a hypervisor though, KVM is the hypervisor, whatever glue that sits between them (be it perl/qemu or libvirt). Promox is still not a hypervisor.
No. I disagree for reasons you refuse to respond to.
> KVM is the hypervisor
Yes I’ve said this since the beginning?
> qemu
Thanks for acknowledging you were a liar.
> Proxmox is still not a hypervisor.
I’ve already acknowledged why I see why you think this, because you want to strictly define the line at KVM. I, and many others, disagree with you.
In fact, general Google consensus also disagrees with you. Please, change https://en.m.wikipedia.org/wiki/Proxmox_Virtual_Environment and https://en.m.wikipedia.org/wiki/Hypervisor if this is the biggest hill you must die on.
Your weird pretense that Proxmox is not capable of deploying VMs is objectively wrong. How does it do it? Via KVM - an integral component of Proxmox.
Since you’re a brick wall who can’t see nuance, understand conventional definitions, or even give the slightest amount of understanding to another point of view, then there’s no reason to keep talking with you.
Right now you can set up a VM or an LXC container. In comparison to docker/podman, LXC is more like being a sysadmin.
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.
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.
This reminds me a lot of the cycle of sandboxing:
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.
1 - https://github.com/yapret/toolship/blob/main/src/node/functi...
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.
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.
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.
Uses the same Linux primitives as docker etc, but can be a bit more ergonomic for this use case
You need something like org/image@sha256:<hash> instead.