201–210 of 422 posts
Earlier quoted context omitted.
Another is running containers in read-only mode, assuming they support this configuration... will minimize a lot of potential attack surface.
Never looked into this. I would expect the majority of images would fail in this configuration. Or am I unduly pessimistic?
I'm not even sure what to say, or think, or even how to feel about the frontend ecosystem at this point. I've been debating on leaving the whole "web app" ecosystem as my main employment ventures and applying to some places requiring C++. C++ seems much easier to understand than what ever the latest frontend fad is. /rant
You have to define a firewall policy and attach it to the VM.
Earlier quoted context omitted.
Another is running containers in read-only mode, assuming they support this configuration... will minimize a lot of potential attack surface.
Never looked into this. I would expect the majority of images would fail in this configuration. Or am I unduly pessimistic?
Unfortunately, there is no way to specify those `emptyDir` volumes as `noexec` [1].
I think the docker equivalent is `--tmpfs` for the `emptyDir` volumes.
> 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 --…
> 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 --…
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow ssh
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw enable
Earlier quoted context omitted.
Yeah but why would somebody co-host military secrets or billions of dollars? Its a bit of a stretch
I think you’re missing the point, which was that high value targets adjacent to soft targets make escapes a legitimate target, but in low value scenarios vm escapes aren’t worth the R&D
Earlier quoted context omitted.
If the container is running in privileged mode you can just talk to the docker socket to the daemon on the host, spawn a new container with direct access to the root filesystem, and then change anything you want as root.
Notably, if you run docker-in-docker, Docker is probably not a security boundary. Try this inside any dind container (especially devcontainers): docker run -it --rm --pid=host --privileged -v /:/mnt alpine sh I disagree with other commenters here that Docker is not a security boundary. It's a fine one, as long as you don't disable the boundary, which is as easy as running a container with `--privileged`. I wrote abou…
The only serious company that I'm aware of which doesn't understand that is Microsoft, and the reason I know that is because they've been embarrassed again and again by vulnerabilities that only exist because they run multitenant systems with only containers for isolation
Yikes. I would still recommend a server rebuild. That is _not_ a safe configuration in 2025, whatsoever. You are very likely to have a much better engineered persistent infection on that system.