Commented by: @AlexPeshkoff

An attack on a database on the server specifying database being it's own security one in DPB:
1. Server's security.db is used and nobody is going to use multiple security databases.
2. User BadUser is granted a right to create tables in database. (That's required for some software - they create some tables for own use.)
3. BadUser creates PLG$SRP table with appropriate fields - why not, he is granted right to create tables. And adds a record for SYSDBA with known to him password (just copies from his own db).
4. Next he adds new item into DPB, logins as sysdba and had privilege escalation in target database.

ANY attempt to control security settings of server from CLIENT will add BIG hole in security for other people. Valid solution for systems where you want to have self-referencing databases is to make task installer to edit firebird configuration on server. Giving it such rights on particular box will not badly affect people who can provide good administration and normal security level on there systems.

One problems looks reasonable:
> Also for some workloads it would be great to give regular users ability to create/fork databases, without giving them root/admin grants over the server machine itself to edit database.conf
I tend to learn databases.conf (in fb4) to set non-default parameters not for individual files only but also for groups of files. What shoudl it be - directories, subtrees, something else?

Commented by: @hvlad

Alex,

what if that new tag will be removed from DPB by remote layers (same as we did for trusted auth, iirc) ?
I assume the feature is dedicated for embedded usage.

Commented by: @AlexPeshkoff

If it will be removed by network server (like trusted auth) it will make almost no sense. The only way it may be used in that case is to manage users in local database when attached to it embedded - because for embedded attachment there is no need in security database, one can specify any user name w/o password.

Commented by: Arioch (arioch)

AS: in the prior discussions I suggested that database explicitly mentioned in databases.conf would have settings from databases.conf pre-empt override any DPB values, thus efficiently prohibiting self-security mode for databases that explicitly are mentioned in databases.conf.

-----

> User BadUser is granted a right to create tables in database

direct modification of system tables is extensively being prohibited in FB3
that should include tables used by auth plugins

auth plugins (either all loaded by server instance or the one selected for that DB in RDB$Database) should advertise the data objects they use and consequently block their update by any means than plugins themselves..

there can also be a granularity like on mon$attachments: users which are not rdb$admin already can only access the rows about themselves, and for most columns would have r/o access

> An attack on a database on the server specifying database being it's own security one in DPB:

This attack should equally apply to ANY self-security database, including ones which are set to be self-security in databases.conf
There seems to be nothing specific to DPB.
Login with one auth-plugin, use direct modification of its system tables to update settings for this - or for another - auth-plugin, reconnect using updated credentials.

There is no need to copy PLG$SRP data from another database on the same server - he can install FB3 at home and create and copy the needed rows from there, with pen and paper if need be.

Also that attack would be impossible if a self-secured database could only have one active auth-plugin and that should be pre-selected in a special column in RDB$Database, which would only be possible to do by RDB$ADMIN

Commented by: Arioch (arioch)

> ANY attempt to control security settings of server from CLIENT will add BIG hole in security for other people.

Overstatement. List of users and their passwords is a "security setting" too. So following that line all SQL commands to manipulate users should be banned.

Dangerous is mix of database accesses in internal/external security modes. Database files should better be isolated into ones with self-security and ones getting security from outside. And only switched from one class to another explicitly. That is true. That is being discussed.

> to make task installer to edit firebird configuration on server

an ad hoc service running on the server with local_system/root permission, waiting to requests to modify databases.conf

Now THAT would be the security hole waiting to happen.
Just remember how antivirus engines implementing stealth techniques were used by viruses to hide themselves too.
Remember how copy-protection services with custom kernel-level drivers were being exploited to run shellcode.

You demand ad hoc self-made services made by application developers not experienced in writing hardened exploits-proof code to manipulate database.conf by ad hoc non-systemic not-configurable not-auditable DSL. And now that suddenly is secure.

Okay, what would happen when two such services installed by different box software packages simultaneously apply different changes to database.conf?
Maybe iot is time that Firebird would provide ACID API to database.conf editing ???

Commented by: Arioch (arioch)

> I tend to learn databases.conf (in fb4) to set non-default parameters not for individual files only but also for groups of files. What shoudl it be - directories, subtrees, something else?

Maybe there can be something like those /etc/xxxx.d folders in Linux where different clients could install their partial config files for the service they need

That way each application would be only editing its own little conf-file solving the problem of simultaneous non-atomic updates by two writers.
That also would provide for fine-grained rights control when different software packages would only be given a right to edit their own partial config file by OS means.

However I feel like the discussion of configuration changes for FB4 are outside of this ticket, here they would have little public exposure and would be lost.

Commented by: @hvlad

Alex,

first, i fully agree with you that client must not affect security on server (in the means discussed above).
Therefore i don't think we should add such abilities in DPB.

But... what if we would change common\default rules a bit:
- if database marked (*see below) as containing self-security data, AND
- if server configuration is not overrides security database for this database
- then use this database as security db for itself

As for
> 3. BadUser creates PLG$SRP table with appropriate fields
yes, but such table will not be marked as system and auth plugin should not use it

* To mark database as containing self-security data we could introduce new tag on header page
which will be set(reset) when such security data is created (dropped) by special SQL statement.

Commented by: @AlexPeshkoff

Vlad, your suggestion appears to be OK from security POV but I want to point to some purely tech issues.

> if server configuration is not overrides security database for this database
What means overrides here? Security database may be specified in firebird.conf (overrides default value for all databases), next this value maybe overriden for particular database in databases.conf. If security database is explicitly specified in firebird.conf - is default value overridden? Next issue with this that our config stuff initially does not make difference between source of parameter's value - is it default or its it set in firebird.conf. Certainly I can add particular call to check for 'was SecurityDatabase set explicitly at desired for us level' but may be it's time to review all .conf file processing to be able to know was some value set explicitly or not?

Second problem is purely performance one - we will have to open somewhere (sooner of all right before invoking auth plugin to provide to it correct SecDb info) target DB file and read it's header which will add small additional delay for all connects to server. Not too awful but wanted to point to it.

If we decide about this issues such feature can be added to fb4 plan.

As for
> such table will not be marked as system and auth plugin should not use it
this is wrong. PLG$ tables are regular, not system tables. They are created by plugin at first CREATE USER command and therefore can be created by any user having appropriate rights.

Commented by: @AlexPeshkoff

Arioch, re

> Maybe there can be something like those /etc/xxxx.d folders in Linux where different clients could install their partial config files for the service they need

Yes, and this feature is present in FB3, moreover - exactly in mentioned style. One can add a line
include /some/path/*.conf
to any config file and all .conf files from given folder will be included in this place.

Almost like in xinetd.conf:
includedir /etc/xinetd.d
May be even more flexible :)

Certainly it's preferred way to enable installers to modify configuration.

Commented by: Arioch (arioch)

I wonder if fb 4 engine could introduce namespaces for security checks, so that there would be no problems like "BadUser creates PLG$SRP table"

RDB$xxx, MON$xxx, PLG$xxx if needed - would be just out of reach for general SQL except for access explicitly implemented by the namespace provider

Commented by: @AlexPeshkoff

Yes, there are plans to introduce namespaces in FB4.

Commented by: Arioch (arioch)

>Yes, and this feature is present in FB3, moreover - exactly in mentioned style.

No it is different. The folders name I mentioned are fixed and well known for any Linux distro, thus and package in its repository knows exactly WHERE to put there partial configs too

> One can add a line include /some/path/*.conf

That means the retail box software should add that line to the default config. Even if some other software already added one - the 2nd software would not have a way to know if the said folder is designed for everyone's repository or if that globbing include was added for some another intention.

It is like with FB2 users - every program is free to add/delete users but when there are several retail-box programs they may start to delete each other's users instead.

When a retail box sees "include /some/path/*.conf " line it can make no assumption about why that line was added and what was the intention and how it can or can not use that folder.
You still think in in-house paradigm. There is a department dedicated to FireBird and there are ten servers and ten admins that only work b maintaining firebird and all firebird using apps.

What if there are not ? And user can not even find Any Key?

How can a retail box software without asking users any questions learn where to put its own partial database.conf to without risk of overlapping with another program?

----

Actually, I suggest that *.conf be a bit more formalized.

I suggest every but the top-tier databases.conf file should advertise the folders it manages, be it DB folders, or - if applicable - UDF/UDR, ET, TEMP, backup/restore/ whatever folders.

Then

1) the partial conf file can only describe/manage resources positioned in the advertised folders
2) the siblings can not overlap in the folders they manage. if FBConfig/layer2/prog_A.conf advertises it would put databases into c:\prog_A then FBConfig/layer2/prog_B.conf wold be prohibited to advertise it gonna put databses into c:\prog_A\something - that namespace is already reserved for another conf. Server should reject it.
3) however FBConfig/layer3/prog_A_component_x.conf can advertise putting DBs into c:\prog_A\something if - and only if - it was linked from FBConfig/layer2/prog_A.conf

That way the tree of partial conf files would be mapped to the tree of disk namespaces and so there would be no loophole when... ahem... baduser would install two programs that would want to manage the same folder and would interfere to one another

Every sub-conf should be limited to its own exclusive sub-folder(s).
Otherwise we are back to the "Open database, create PLG$SRP, reopen that very database as self-secure using another partial conf"

Think In terms of retail box software - they typically can not ask user techy questions and they can have no prior knowledge about each other. So they should be componentised. So there should be
1) a fixed well-known place where they should put their partial configs for FB without interfering with other apps
2) a boundary that would isolate different applications so they would not make mess of each other's folders

Commented by: Arioch (arioch)

> PLG$ tables are regular, not system tables. They are created by plugin at first CREATE USER command and therefore can be created

I guess there SHOULD be difference.

Since those plugins are security-critical to the point they only are installed/enabled by system administrator, they should create their data in some way clearly distinguishable from general user.

Maybe plugins should be given interface to mark their object as system ones after creation.
Maybe they should be created by specific hardcoded user that users can not log in. Like the user name being the plugin name prefixed with space or \0 character, that regular users can not create and log in.

Commented by: Arioch (arioch)

> we could introduce new tag on header page which will be set(reset) when such security data is created

Vlad, take in mind there can be different auth-plugins

The mere flag "there is SOME security data" is not enough nor needed - the mere presence of authentication tables in users-denied namespace would be euogh to tell it.

The problem is when a user
1) logs into a database using auth-plugin-1 and his normal grants
2) creates/modifies his credentials in the tables of auth-plugin-2 with unlawful grants for himself like the aforementioned "SYSDBA"
3) logs into the database using auth-plugin-2

---------------------

Actually, since SYSDBA name is hardcoded and server-global perhaps auth-plugins should be prohibited from working with it.
If you use SYSDBA you demand exclusive access on the server-global level, thus only security3.fdb should allow that user to log in.