[staticassertion]

Right, RLS is great. What they are saying is this:

> every employee can access our main financial/back office SQL database

This means that there is no access gate other than RLS, which includes financial data. That is a lot of pressure on one control.

[zie]

Your SSO system is a lot of pressure on one control too. Nobody seems to have problems with Azure or Okta or whatever SSO system you use having every key to the kingdom.

RLS has been around a long time and is very stable and doesn't change much. SSO providers keep adding stuff ALL the time, and they regularly have issues. PG RLS is very boring in comparison.

I don't remember the last CVE or outage we had with PG that broke stuff. I can't remember a single instance of RLS causing us access control problems on a wide scale. Since we tied their job(s) to their access control many years ago, it's very rare that we even have the random fat-fingered access control issue for a single user anymore either. I think the last one was a year ago?

[staticassertion]

> Your SSO system is a lot of pressure on one control too. Nobody seems to have problems with Azure or Okta or whatever SSO system you use having every key to the kingdom.

Some do, which is why they want MFA on the target side as well as on their SSO. But yes, SSO is very scary and there's a ton of security pressure on it. I don't think that's a very good argument for why we should think that every system should only require one layer of defense.

I'm going to sort of skip over any comparison to SSO since I'm not going to defend the position of "SSO is fine as a single barrier", especially as SSO is rarely implemented with one policy - there's device attestation, 2FA, etc.

> RLS has been around a long time and is very stable and doesn't change much.

RLS is great, I'm a fan.

> I don't remember the last CVE or outage we had with PG that broke stuff.

It doesn't really matter. The fact is that you're one CVE away from every employee having access to arbitrary data, including financial data. I feel a bit like a broken record saying this.

[zie]

> It doesn't really matter. The fact is that you're one CVE away from every employee having access to arbitrary data, including financial data. I feel a bit like a broken record saying this.

Sure, but it's the same with pretty much any other app architecture.

Either your app has all the data access and you put your access control there, or you do the access control in the database. There really aren't other options here. There isn't access control defense in depth here. The best you can really do is do some data encryption of the data in the tables. We do some of that, but it's such a PITA that we relegate it to special stuff only.

> especially as SSO is rarely implemented with one policy - there's device attestation, 2FA, etc.

Sure but ALL of that relies on the SSO system behaving as advertised, so you think of it as separate policies, but it really isn't. It's once SSO CVE away from giving away the store. We use SSO with PG, that's how they authenticate to PG, we are fans of SSO too.

[staticassertion]

> Either your app has all the data access and you put your access control there, or you do the access control in the database. There really aren't other options here.

That's odd, I just clearly delineated an option in which this is not the case. The DB enforces RLS, users provide the RLS token, and an app gates access to the db.

[zie]

I must have missed that in the comment stream.

It's not really any different than using pgbouncer or something similar. All it buys you is not having to use the PG protocol on the client.

There is no extra security here though. One could even argue you lose security here, since now you have to rely on the app to not get tokens confused, since they hold and use the tokens on behalf of the user. A single bad CVE in the app and one can become any user the app currently knows about.

[staticassertion]

I think the conversation is suffering from trying to solve a problem that's underspecified, which is going to just lead to a lot of "what if" questions. I've explained my concern with relying on a single boundary, which should not be contentious and I have given multiple examples of potential additional controls.

[array_key_first]

Row level security is absolutely fine.

Most companies, or at least the ones I've worked at, don't use row level security at all. Instead, the application just accesses the multi tenant database.

It's absolutely littered with broken access control vulnerabilities. You have to remember to put the user key and group in every query across the entire application. And then there's dynamic queries and ORMs, which make everything worse. Now you cant even audit the source code, you have to observe behavior.

Most people don't know their applications have these vulnerabilities, but they're very common.

[staticassertion]

I have never suggested that there's something wrong with RLS nor that RLS and an application should be mutually exclusive, as I've pointed out multiple times now.

[array_key_first]

Right, I'm just saying that, in practice, most web applications don't use it. From what I've seen. So in a relative sense, this is an improvement. And I think that's generally how we should view security. Within the context of the threat model.