3np

> "Write your own Dockerfiles" is not useful security advice.

I actually think it is. It makes you more intimate with the application and how it runs, and can mitigate one particular supply-chain security vector.

Agreeing that the reasoning is confused but that particular advice is still good I think.

Two paths:

- Configuration management (ansible, salt, chef, puppet)

- Preconfigured images (NixOS, packer, Guix, atomic stuffs)

For a one-off: pssh

Hey, thanks for taking the time to share your learnings and engage. I'm sure there are HN readers out there who will be better off for it alongside you!

(And good to hear you're leaving the LLMs out of the writing next time <3)

Thanks! Would be cool to have it packaged for alpine since firewalld requires D-Bus. There is awall but that's still on iptables and IMO at bit clunky to set up.

This affects podman too.

> I also enabled UFW (which I should have done ages ago)

I disrecommend UFW.

firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can.

    firewall-cmd --persistent --set-default-zone=block
    firewall-cmd --persistent --zone=block --add-service=ssh
    firewall-cmd --persistent --zone=block --add-service=https
    firewall-cmd --persistent --zone=block --add-port=80/tcp
    firewall-cmd --reload

Configuration is backed by xml files in /etc/firewalld and /usr/lib/firewalld instead of the brittle pile of sticks that is the ufw rules files. Use the nftables backend unless you have your own reasons for needing legacy iptables.

Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway. Depending on your configuration, those firewall rules in OP may not actually do anything to prevent docker from opening incoming ports.

Newer versions of firewalld gives an easy way to configure this via StrictForwardPorts=yes in /etc/firewalld/firewalld.conf.

As sibling mentioned, unless you or the runtime explicitly mount the docker socket, this particular scenario shouldn't affect you.

You might still want to tighten things up. Just adding on the "rootless" part - running the container runtime as an unprivileged user on the host instead of root - you also want to run npm/node as unprivileged user inside the container. I still see many defaulting to running as root inside the container since that's the default of most images. OP touches on this.

For rootless podman, this will run as a user with your current uid and map ownership of mounts/volumes:

    podman run -u$(id -u) --userns=keep-id

> > Onboarding is bad

> Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work.

This is a bit outrageous IMO. Actually breaking and deprecating the classic auth and requiring a new server component to keep the only actively supported client (which still can't properly manage keys or sessions on its own, like classic Element can, even as non-verified sessions are being disabled) is a bit rich.

The answer seems obvious but one that won't be spelled out in SCMP.

Great you found something that works for you and that you managed to dodge the parts of the community that somehow managed to turn this into identity politics.

Still, the gaps are there and don't seem to be filled anytime soon, despite the progress you mention.