SEPostgres

Just to be clear, for a sysadmin managing an SELinux system it isn't that hard to work with and so it very likely provides a useful protection that is worth the effort. For the sysadmin who just needs to tweak policies or write rules for home-grown software I did not find it nearly as difficult as one would be led to believe. I think more effort has been spent in complaining about it than in learning how to use it.

If I attack the application, I might subvert just one instance, for example by hijacking the web client that has site-level "super user" privileges to access data I shouldn't see or by using a code exploit that depends on invalid/unsafe data stored in that application instance. Neither RBAC nor SEPostgres helps here, because it still looks like the application code accessing its normal database content.

If I find an exploit in the web application code, not depending on the site-specific data content, I can repeat the attack on whichever site I want, and I can also access whatever data that Postgres would normally supply to that application instance. This is no different than if the "site" instances were each on physically separate servers with completely independent Postgres servers too. We see these sorts of exploits published all the time, due to the many layers of libraries and frameworks used for convenience on the web.

To do fine-grained restrictions, you would need to assign roles and/or context to each remote web user. This is a bootstrapping problem of getting from Internet-originated TCP stream containing an HTTP request to a restricted context suitable for evaluating the request. This means trusting Apache httpd and whatever web application components are involved in authentication and context establishment, much as we trust sshd today in establishing SE-Linux context for remote users.

To make SEPostgres "more mandatory", it would require pushing the access enforcement back into the kernel, e.g. by applying different SE-Linux contexts to different filesystem objects storing portions of the data, and having the query engine run in a more limited context for each client/query and making it tolerate refusals to access some elements of the data store. For example, each table is a separate file that could be protected to different levels, but you'd have to change the storage format to support column or row-level protections. You could then have the query engine act as if denied data does not exist. But this would probably require relaxing certain data integrity constraints, since they require a unified, global view of the existing data to validate them. But, you are still trusting parts of Postgres to act like sshd in establishing the right process context for clients.