| ▲ | nathan_compton an hour 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. |
|
| ▲ | netdevphoenix an hour ago | parent | next [-] |
| > 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 |
| |
| ▲ | Lutger an hour ago | parent | next [-] | | 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. | | |
| ▲ | roozbeh18 21 minutes ago | parent | next [-] | | 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. | | | |
| ▲ | mlnj 35 minutes ago | parent | prev | next [-] | | >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. | | |
| ▲ | lbhdc 9 minutes ago | parent | next [-] | | Not who you asked, but I have a similar setup. I can run everything I need for local development in that image (db, message queue emulator, cache, other services). So, setting things like environment variables or running postgres work the same as they do outside the container. The image itself isn't the same image that the app gets deployed in, but is a portable dev environment with everything needed to build and run my apps baked in. This comes with some nice side effects like being able to instantly spin up clean work environments on my laptop, someone elses, or a remote vm. | |
| ▲ | jack_pp 25 minutes ago | parent | prev [-] | | Maybe don't use JavaScript on the backend. |
| |
| ▲ | moffkalast 42 minutes ago | parent | prev [-] | | All right then, keep your secrets. |
| |
| ▲ | swsieber an hour ago | parent | prev [-] | | I didn't read this as separate containers. |
|
|
| ▲ | myaccountonhn an hour ago | parent | prev | next [-] |
| I ssh into a second local user and do development there instead with tmux. |
| |
| ▲ | n4r9 43 minutes ago | parent [-] | | I send mail to a demon which runs MsBuild and mails the output back to me. |
|
|
| ▲ | rco8786 an hour ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | christophilus an hour ago | parent [-] | | 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? | | |
| ▲ | LeifCarrotson an hour ago | parent [-] | | 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! | | |
| ▲ | Lutger 41 minutes ago | parent | next [-] | | You're severely limiting the blast radius. This malware works by exfiltrating secrets during installation, if I understood it correctly. If you would properly containerize your app and limit permissions to what is absolutely required, you could be compromised and still suffer little to no consequences. Of course, this is not a real defense on its own, its just good practice to limit blast radius, much like not giving everybody admin rights. | |
| ▲ | amazingman 20 minutes ago | parent | prev [-] | | Sure, but only the container is affected and it is always your responsibility to grant as little access as possible to the various credentials you may need to supply that environment. AFAICT with this worm, if you don't supply write-level GitHub credentials to the container (and you shouldn't!) and you install infected packages, the exploit goes no further. |
|
|
|
|
| ▲ | echelon 39 minutes ago | parent | prev [-] |
| 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. |
