Blahaj.zone experienced a security breach and is handling it to properly reduce the risk of harm to their users. the current eta for their reture is in about 7 hours.

you are viewing a single comment's thread
view the rest of the comments

[–] WhyJiffie@sh.itjust.works 8 points 1 day ago (1 children)

Use a separate DBMS (that is, a separate postgres/mariasql/etc container) for each service. Give each one service unique passwords, which you can define in the docker compose.

unique passwords is good practice, but separate db server for each of the services is extreme. it brings much more resource consumption. the solution here is being subscribed to security releases and updating soon. those application kernels also sound like a good idea. and as I understand, postgres permissions were not at fault, the permission system had a bug.

Even if one application that connects to a database gets owned, it doesn't have access to other postgres databases, preventing data leaks/exfiltration.

except that because of the bug, anyone with query permission could have become postgres superuser.

[–] moonpiedumplings@programming.dev 4 points 22 hours ago* (last edited 22 hours ago) (1 children)

except that because of the bug, anyone with query permission could have become postgres superuser.

If a user can't log in to a DBMS, they don't have query permission.

separate db server for each of the services is extreme. it brings much more resource consumption.

Yes. It consumes more resources. But it's not that much more, and you can make it fit easily. Many users using docker compose unwittingly do this since docker composes often bring their own database containers. When done consciously, you make a trade off for peace of mind.

the solution here is being subscribed to security releases and updating soon.

I addressed takes like these in the last part of my previous comment. The linked comment also elaborates on my opinions about manual updates, manually watching security releases, and other forms of security toil.

[–] WhyJiffie@sh.itjust.works 1 points 10 hours ago (1 children)

If a user can't log in to a DBMS, they don't have query permission.

weren't they having access through peertube? you can't revoke access to something that needs it.

sure, they could run dedicated postgreses for each service, but I think this kind of bug is so rare that it is not worth wasting lots of RAM on that, and even then, it would rather just deter people from hosting services they want.
also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN. and the response is that it is unfeasible, and it was unfeasible even before the RAM shortage, unless you have enterprise hardware with 100+ GB RAM, consuming way too much power compared to a server made from desktop PC hardware, even when there is no meaningful CPU load.

But it's not that much more, and you can make it fit easily.

I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don't have time to merge them.

[–] moonpiedumplings@programming.dev 1 points 9 hours ago* (last edited 9 hours ago)

weren’t they having access through peertube? you can’t revoke access to something that needs it.

The peertube database did not have the vulnerable extension enabled. They got access but connecting to another database:

We did not have pgcrypto installed in the peertube database, but I overlooked that someone could connect to the main postgres database if they say had a nodejs plugin running.

From that database they escaped. So if they only had access to the peertube database, that path would have been cut off for the attackers.

also at that point, the question arises why not just run everything in qubes OS, each service in its own VM and its own VLAN.

VLAN's suck. They allow for traffic to travel within each VLAN them, unmonitored and unrestricted. Sometimes red teamers call that "hard outside, soft inside, like an eggshell".

Better, is a private VLAN. Private VLAN's enable the firewall to monitor or block all traffic within them. For many usecases, a single private VLAN can replace the complex, many VLAN setups that people spend so much effort setting up. You just block everything within itself from communicating with eachother, and then you can explicitly allow the stuff that actually needs to talk.

Often, there is no reason to allow devices with a VLAN to communicate with eachother. And even if you are allowing intra-pvlan communication within a private VLAN, you can now monitor the traffic, which you can't do with a regular VLAN.

Qubes OS

Yeah. That's basically what virtual machine or application kernel based runtimes are doing. The trick is that they are designed for this usecase, with the goal of making the isolation as cheap and performant as possible. Qubes runs full Linux VM's since it is designed for a desktop isolation usecase.

Anyway. It's a matter of threat model and effort. I like application containers/vm container runtimes due to how simple and easy they are to run, and the clear security benefits they provide. Install in < 30 min, configure the container runtime, restart your containers, done. Switching from a regular Linux desktop to Qubes is not as simple, so it's harder for me to recommend that, and it becomes a matter of threat model.

It's also common to separate services out in different Proxmox VM's, which offers isolation benefits akin to Qubes.

I run 3 separate database servers on the same OS because I made a bad decision at one point, and I regret it. I just don’t have time to merge them.

Congrats on the security isolation!

In all seriousness, you should be able to migrate them into the same database by dumping the database with pg_dump or a similar utility, and then loading them up using pg_restore. Other databases have equivalent tools. I used the Dbeaver open source database GUI to do this a few days ago.