[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: |
|
||||||||||||
| 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
|
| Comment by Mike Gorrell [ 13/Nov/20 ] |
|
Johannes Drexl the Security group would like to close this issue as a duplicate of
|
| Comment by Johannes Drexl [ 13/Nov/20 ] |
|
Material differences:
So, no, this is not a duplicate. |
| Comment by Craig McNally [ 13/Nov/20 ] |
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:
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. |