My specific setup is that I use an authorized_keys entry on the host that restricts the guest to running a specific command, which limits what a compromised guest can do to the host. The command is set to a script that has a list of specific permitted actions. This is a good option if you’re looking for a bit of additional isolation between host and guest.
That’s a neat trick, thanks for mentioning this.
command="command" ssh-ed25519 ...
My authorized_keys line looks like this:
command="${HOME}/bin/fromvm vmname",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-ed25519 ...
The actual script uses $SSH_ORIGINAL_COMMAND, exactly as you've described, which means that while the guest thinks its executing e.g. "pbcopy", the host "fromvm" script is actually receiving "pbcopy" in the $SSH_ORIGINAL_COMMAND and can apply the appropriate access control or restrictions.
On the topic of limiting the possible commands - for my use case I only needed pbcopy. Maybe think twice before letting an insecure VM or remote host read your clipboard contents with pbpaste.
Yes, the guest has “unlimited” access to the pasteboard, which does introduce some risks. For example, the guest could set a malicious command line that you paste into the terminal - which is generally mitigated with paste bracketing in zsh, vim, etc. It definitely weakens the isolation to a certain extent, but I don’t think it completely negates the security barrier as you claim.
When it successfully installed, it was terrifying to think that all source code, private files were instantly shared with malicious actors. Not only that, there was the prospect of having to somehow wipe and ensure all files were clean, reinstall the OS, and the possibility of some bootloader remnant still lurking.
In this case, it seems that a security package had replaced a previous malicious package, making this instance benign. But it feels like I am only one typo away from an absolute catastrophe every time I install a package.
VM seems like a good way to add some protection.
I use this script with an additional seccomp filter that also denies access to privileged syscalls, but I don't remember where the filter came from, so I won't post it here — you won't be able to audit it easily as it's basically a compiled binary.
Place the script anywhere and create symlinks named 'node'/'npm'/'yarn'/etc pointing to it, putting them into the start of your $PATH. Run your commands as usual. Use a 'bash' symlink to see what it looks like inside the sandbox.
It's not as good as a VM, but much more convenient.
A lot better than npm that lets any package run postinstall for sure, but as always there are no silver bullets.
Apparently there is also a default list of packages that are allowed to run scripts on download with Bun, FYI https://github.com/oven-sh/bun/blob/main/src/install/default...
Yeah, but someone should try to fix this anyway. It's not a nodejs-specific problem, but it's badly needed in node. Any of the 100s of authors whose packages I depend on might have made a typo, or just been careless. Software development requires a scary level of trust.
I am also increasingly moving to VMs. I want tools (such as VSCode) to run on the main machine, but actual execution to happen in the vm. It's a bit painful and a drag on productivity, especially debugging.
For this reason I run VSCode inside the VM.
The people in the trial got very little done until it was decided to pause it, and I do not have high hopes for when it’s tried again. It strikes me as basically running malware in the name of security.
I much prefer filtering on the endpoint before TLS encryption.
It’s really a 1 step process in your dockerfile or other location.
Don’t understand the need for Tailscale either. When I’m running services or dbs inside the VM, I can easily access them if needed from the host (either by IP or by the hostname I gave to the VM on start up)
The one mixed/negative thing is that language servers will run inside the VM instead of the host where the editor is "running", which can defy your expectations. I find that a plus since language servers love to tie up multiple cores and eat up memory and having that happen inside the constrained VM environment stops my host system from getting bogged down.
I used to edit in a shared mount before and moving to the vscode ssh remote model was a noticeable improvement. It's just faster.
I'm working on a Windows host with a bunch of Linux VMs. Although I can share directories between the host and guests, I prefer to rely on SSH remote because I want to work in the VM's filesystem and its environment. For example, I don't want to care which version of python and what kind of libraries are installed on the host. The VM is supposed to be a container for all that stuff, and different projects have different requirements.
I could probably revise my use of Tailscale. My vague recollection is that I had networking issues when my laptop woke up and Tailscale didn’t have the same issues. Probably a debugging skill issue on my part.
It actually runs the code, including plugins you download from the internet. All your development tools, compilers, etc. are on the remote. And then you just have a blazing fast editor on the front end. It's really unique - you can use Tramp mode in Emacs, but it is extremely slow to copy back and forth. SSH into a remote server? let's just say 200 milliseconds lag when you're trying to input characters is not a good experience.
The highest praise I can give Visual Studio Code is that remote development felt so much like local development that I wondered why it suddenly froze. Well, it turns out it's good, but it still can't deal with a network that's down. That was obvious in retrospect, however I hadn't thought of it at the time because I had completely forgotten I was doing remote development.
maintaining consistent firmware development environments using containers is a great idea, and current solutions involving proxying the compiled binary work well for flashing quickly, but switching back and forth between UART and Serial Debug is always more convenient when the IDE can handle it all
If you are using Docker Engine directly on Linux, you can forward a device to a container via docker-compose `devices` setting.
If you are using Docker Desktop (or similar), there is no native way. However, there are ways to share USB devices via network (USB/IP is an open source implementation of this), in which case you setup server on host device (can be macOS/Windows/Linux), and then run a client software inside a container.
Otherwise you could pipe serial over TCP
will try again with sockets/TCP, thought i hit a roadblock after reading https://github.com/docker/for-mac/issues/5263#issuecomment-7...
It’s slick when it works.
> My physical machine is a 2023 MacBook Pro with M2 Pro CPU
> I’m using VMWare Fusion Pro
> Quite often I’ve found developers frowning up Ubuntu and preaching for folks to use NixOS, Arch, Debian or other distros. The reality for me was Ubuntu was the fastest way to get set up and now
I'm in integrated circuit / semiconductor design. At every big company over the last 30 years we are given a computer and we can change the desktop environment but we aren't installing our own operating system.
The people I know in software have a common OS, compiler, and build environment. They aren't dictating what text editor you use but you aren't working on projects individually but together.
So if everyone at the author's company is doing their own thing do they have problems integrating all the code together? "Oh you used version 2.3.4 but I used version 2.4.7 which fixed this issue, what are we using to ship with?" Or is this not a problem?
Each project we have requires a specific tool chain version (python, elixir, ...) and specific versions of things like postgres. All dependencies are listed with some kind dependency definition file (pyproject.toml, package.json, mix.exs). If you bump a package it's done in the definition file as part of your changes and goes through CI for packaging and releasing. The rest of the team will get the new package version as soon as they pull your changes and run `just deps` or whatever. CI is the ultimate determining factor of whether your code actually "works".
We also package and deploy with containers, but this isn't the real determining factor for any of the above.
The main issue with my setup is that VMware or Windows 11 (my host OS) can't use the GPU when rendering the UI of the VM (I'm not sure if VMware or MS is to be blamed or both) despite having a discrete GPU card installed.
The rendering of the image must all be done by the CPU, which requires a lot of RAM.
After switching to 3 x 4K monitors, the VM requires 62GB of RAM to be able to run on full screen on all monitors (63720 MB to be precise). I recall that I somehow managed to get it working while "only" using around 32GB, but it became unstable. 62GB is the sweet spot where everything runs smoothly. Haven't tried to adjust the settings in years. It was a pain to get working in the first place with 4k monitors, and since I have 256 GB installed, I just left the settings as they are.
At next motherboard upgrade I might revisit, but I think that VmWare still can't take advantages of the host GPU in this regard so I expect the RAM requirement to stay.
Some computer problems can be solved by throwing hardware at it. This is one of those. Give VMware and Windows an obscene amount of RAM, and you can have Teams running smoothly and flawlessly inside a VM on a Windows Client Host in 4K.
Works well enough. Better than Docker on barebone MacOS if you have lot of file access in a volume.
That's one of the thing which surprised me when I started using VMs to develop. First time was with a postgres backed app: I expected to lose performance when moving everything in a VM. But got the exact opposite result at the time. Postgres really liked the linux filesystem more than the windows one, enough to do more than offset the VM tax.
One weird quirk: networking can be peculiar. Windows creates a magic bridging between the host and WSL, and as anything magic, it can break for specific use cases.
VPN is one [0]: my WSL instances lose outgoing networking when connecting to our company VPN. There are workarounds but none are trivial.
[0] https://superuser.com/questions/1715764/wsl2-has-no-connecti...
https://learn.microsoft.com/en-us/windows/wsl/networking#mir...
My setup is mostly one VM per project group / online identity. Most of them using Ubuntu. The problem is when I want to work on an old project to check how it likes new technology I tend to stumble into the "you should have kept the OS up to date" problem. Ubuntu does not make it easy to upgrade if you miss more than a year of update.
And even if you keep up to date, they tend to break things often (loved the X11 to weyland switch when working with screen capture libraries) so new VMs are using debian.
I don't think you have to do some manual configuration to upgrade your distribution because it is a couple years old and current scripts don't support that (like going from a 22.10 to 24.04 is a fun game).
Vscode supports remote containers, so everyone in the org just develops INSIDE a replica of the prod container
All containers run remotely on enormous machines with 800+ GB of RAM and 8+ GPUs
It’s trivial to share environments now because you just open the project and the dev container starts up and installs all the deps, devcontainer.json is just a few kb so just check it into git
Engineering, DevOps, Data science all use this setup, push around your devcontainer.json and everyone gets the same GPU accelerated dev environment with near unlimited RAM and hundreds of CPU cores, none of this hardware is local so you can code on the balcony/beach on your MacBook Air, light and easy to travel with.
We put VMs in the same country as our staff so latency has never been an issue
This is the dev setup I’ve wanted for ages, and it’s a joy to use
Edit: Unless you literally mean "editing code in a container with vi". In which case yes I'd go for the VM too!
They also seem to be pushing it beyond vscode and into something which is editor agnostic. It's not quite there yet on that front, but I'm excited for it as I've been dabbling with other editors recently which don't support devcontainers directly and it always pulls me back to vscode.
It's on a journey for sure, but I've had no performance issues when using it straight out of the box over the past year.
After a 5 years hiatus I started developing mobile apps again and I was frustrated to learn that Apple doesn't allow renewing the developer license on web anymore, I don't own a Mac and even Apple developer app on iPhone didn't allow me to renew my license.
After I signed into a macOS VM, I was able to renew my license through Apple Developer App on iPhone as macOS version of the app requires T2 chip.
Now I have PTSD flashbacks of why I left mobile development in first place.
iCloud/imessage have always been finicky with Hackintosh, but in my experience setting the correct serial number with appropriate Mac model is the key to resolve those issues.
With just couple of years of Hackintosh scene left before support for x86 Macs are dropped completely, a VM Hackintosh makes more sense to me than building a physical Hackintosh.
Now I know what all the WSL users experience seamlessly with their setups. Glad I have something that comes close.
Side note: I checked out your other blog post, and it resonates with my own first post, which I wrote just two days ago: https://fabiendubosson.com/blog/overcoming-perfectionism/. You’re definitely not alone in battling anxiety, perfectionism, and procrastination when it comes to blogging. Keep writing! :)
Happy to set it up and demo if you can share (or DM) a repo URL.
We reach our VMs via VDI.
I most often see this sort of thing where corporate IT can't stomach devs getting root on their own machines. It's a very specific sort of corporate dysfunction.
But, I am in an airgapped environment that is tightly regulated if you get it.
Such a setup works (I'd know for I have one at home doing just that but it's not my main PC) but how's it like to work like that?
The GPU hooked to the hypervisor can either be on another monitor or on another input (in the latter case you'd "go" to the hypervisor by changing the monitor's input).
So I've installed proxmox on it to utilize it's resources for other stuff as well
For my personal use, I created an Arch VM with GPU and USB PCIE passthrough, all 3 monitors directly connected to that GPU
It's so seamless and fast that I don't even feel I'm working inside a virtual machine
I have other headless VMs hosted to do other things (opensense etc)
After failing to install Windows in a VM (thanks TPM), I found a way to run Windows apps nearly natively (https://github.com/winapps-org/winapps). It works by starting a Windows docker image and streaming the application frame with RDP. As the RDP client handles the copy/paste and other niceties such as shared directories, it's way easier to integrate in my env than the other options.
The only kind of plausible explanation the author gives is that it's "more secure" because the imaginary attacker will have to take an extra step to get the password from the VM instead of the host OS? -- This seems like such an inconsequential / worthless benefit to jump through the hoops of running things in a VM...
Like... I wasn't sold on this approach from the get go, and this pitch makes it sound like I was right all along?
Other non-starter "bonuses" include not installing developer tools on your laptop that you have for... drum roll... development. Why? It's sole purpose is to be used for development, why not install development tools on it? Just doesn't make any sense...
It is especially nice in corporate environment, where the host system is generally managed by IT and the devices are largely impersonal (standardized configuration, standardized software). You can carve out a corner to make your own and work there. <insert rant on ineffective corporate IT>
Disclosure: I work on this project
Likewise when Windows 7 came out, I stop bothering with dual booting hassles and using VMare Workstation instead for whatever Linux.
The exception being a netbook from the Asus Linux netbooks glory days, a price category nowadays replaced by tablets.