[FOLIO-2862] Stop using superuser rights on the database Created: 04/Nov/20  Updated: 07/Jul/22

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Epic Priority: TBD
Reporter: Johannes Drexl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: security, security-reviewed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1935 Service creating ROLE and SCHEMA on t... Draft
relates to RMB-651 Change Database objects ownership pol... Open
Epic Name: Database security
Sprint: CP: Non-roadmap backlog
Development Team: Core: Platform

 Description   

At the moment every tenant gets a bunch of (hopefully) unique users in the database, one for almost every module, if not for every. Therefore FOLIO has to hold superuser rights on the database.

This is bad design. Serious botched, Cisco-level fuckup, with major security implications that should have never seen the light of day. With this model the database server has to be dedicated for Folio, nobody is able to use any non-dedicated database server because a single error/security bug within Folio compromises everything.

Here's a thread of a German hacker who analyzed the German Corona tracking app and gives advise how to do it properly with Postgres:

https://twitter.com/alvar_f/status/1267705319280586753

One database user per module, one database per module, tables within prefixed with the tenant. And then handle security on this level, taking Alvars tips into consideration.

And if you're on it - rework the database to use a relational model instead of a JSON trash heap.



 Comments   
Comment by Julian Ladisch [ 10/Nov/20 ]

Is this a duplicate of FOLIO-1935 Draft ? If not what is the difference?

Comment by Mike Gorrell [ 13/Nov/20 ]

Johannes Drexl the Security group would like to close this issue as a duplicate of FOLIO-1935 Draft , unless you can identify material differences.

Comment by Johannes Drexl [ 13/Nov/20 ]

Material differences:

  • 1935 talks about granting superuser privilege to a service. This is is a security issue. NO service whatsoever should ever have superuser privileges on a database server. Superuser privileges on databases are for administrators only. My proposal only increases the initial work for the admin a bit, but preserves database server security.
  • 1935 still tries to work with one database for all modules. This is botched. One module, one database, no exceptions. Doing it this way also increases portability.
  • 1935 still wants to create users for tenants. No such thing should occur. A module may as well use tenant-named tables within its own database structure to split tenants without the need to call into the database with a different user. Since the module harbors all database credentials anyway, the security gained by different users for the same module is null and void, the administrative overhead on the other hand increases exponentially.

So, no, this is not a duplicate.

Comment by Craig McNally [ 13/Nov/20 ]

This is bad design. Serious botched, Cisco-level fuckup
...elided...
instead of a JSON trash heap.

Johannes Drexl please refrain from these types of remarks and/or language, it's not helpful and violates the project code of conduct.

Comment by Johannes Drexl [ 16/Nov/20 ]

Craig McNally Tell me how it is good design to:

  • Assume superuser rights on an exposed system, any system, during normal operations (actively violating POLP and rendering pg_hba.conf useless)
  • have every module that was ever created registered within the database (a mass of over 70 MB of JSON files, 99.9% of it being trash because outdated and never gonna being used)
  • Using a relational database as file storage

I get it, you don't like the language. You did your best to implement new functions, because those are being rated by libraries, and security is not seen until the whole cardboard house comes crashing down. So you're all 'function predates security'. I get that. This is why stuff like https://folio-org.atlassian.net/browse/FOLIO-2411 and https://folio-org.atlassian.net/browse/OKAPI-709 is not being solved. The latter being marked as such, albeit it's still prominent in the 3.1.2-1 Debian package used for the single server installation, and I take that as a personal insult from dev to sysop, especially (apart from the notion of 'here's the config we give you, but to secure stuff you have to write the config again, and in worst imaginable config format') since I've solved that after a futile wait for over a year and one just has to accept the git pull request done in June, with maybe some little tweaks to make Jenkins tug along.

So since I've told you over the course of 2 years that you have to get rid of the botched stuff that even breaks updates (remember when I tried a model for this whole reference data mess, separating between user, example and system input?), what kind of language is actually the proper one to get things moving and make some people grab a book on proper IT security? I mean, it's not like Folio is a game server, the worst outcome being lost match statistics. Libraries are the storage of mankinds knowledge. They deserve better.

Comment by Craig McNally [ 07/Jul/22 ]

The Security Team has revisited this and think it deserves some more thought, and probably an RFC. It will be good to get more eyes and varied perspectives on this problem.

Generated at Thu Feb 08 23:23:47 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.