Comment by nathan_compton
4 days ago
I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container.
I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.
Probably because it’s fine 99.99% of the time and humans aren’t intuitively good at handling risk that functions like that. Besides, security is something handed off to specialists to free the devs up to focus on building things in most companies. We’re not going to change that no matter how much it represents some ideal.
It's like seatbelts/car seats.
Indeed!
> if I am going to run some code from somewhere and I haven't read it, it goes in a container
How does this work? Every single npm package has tons of dependency tree nodes
Everything runs in the container and cannot escape it. Its like a sandbox.
You have to make sure you're not putting any secrets in the container environment.
You are just reducing the blast radius with use of podman; you will likely need secrets for your app to work, which will be exposed regardless of the podman approach.
3 replies →
>You have to make sure you're not putting any secrets in the container environment.
How does this work exactly? containers still need env vars and access to databases and cloud environments. Without these the container is just useless isolated pod.
3 replies →
All right then, keep your secrets.
No it is not.
I didn't read this as separate containers.
How are you doing this in practice? These are npm packages. I don't see how could reasonably pull in Posthog's SDK in a container.
What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?
I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates.
I don't run much on the root OS of my dev machine, basically everything is in a container or VM of some kind, but that's more so that I can reproduce my environment by copying a VMDK than in an effort to limit what the container can do to itself and data it has access to. Yeah, even with root access to a VM guest, an attacker they won't get my password manager, personal credit card, socials, etc. that I only use from the host OS... But they'll get everything that the container contains or has access to, which is often a lot of data!
5 replies →
Because you need your application code to interact with Posthog's code. But if they're running in separate containers...how are you doing that. Surely you are not writing an api layer for every npm dependency you use.
This is smart and a good first step. Everyone can't be trusted to do the security dance flawlessly, though. We need sane defaults. Least privilege by default for 3rd-party code. Deno's headed in the right direction with this. But I think the solution needs to exist deeper in the stack. The surge in popularity of `curl -fsSL https://my-cool-ai-starup.ai/install.sh | bash` style installers is particularly concerning to me in this regard.
I ssh into a second local user and do development there instead with tmux.
I send mail to a demon which runs MsBuild and mails the output back to me.
You could still leak API keys
The same podman that had three new CVE breakouts not even two weeks ago?
Containers do not contain.
Security is oft done in layers. Podman is just another layer that might fail. There's no such thing as the perfect solution.
Another effective strategy I learned of recently that seems like it would have avoided this is to wait months before using new versions of packages.
Most attacks on popular packages last at most a few months before detection.
Using Podman over Docker is probably an even safer bet in that regard. But QEMU or something for an extra layer of safety and paranoia is probably the next best thing.
Would it have prevented this attack? It would still have published the secrets from your container to github.
the whole point of doing such things in ephemeral containers is to not have your secrets accessible from said container