Database Level Security - Functional Specification

Problem:

Briefly the problems which will be solved are as follows:

Plug hole caused by backup and restore through client use of server manager. One of the problems we will be trying to solve here is caused by the ability of a user to backup or restore a database to any file hence overwriting the original file. This problem is even more acute on NT as IBSERVER runs as privileged user (administrator or root) which could have permissions to write over many files including backup devices like tape drives.

Store password file in GDB file - or other technique - to defeat database "kidnappers". This is the problem caused by the capability of server manager to back up files remotely even if the user is not a privileged user or the owner of the database. In fact any user can back up a database on the server as long as the user exists in the "isc4.gdb" on the server. Consider the following scenario.

Normal user backs up foo.gdb as bar.gbk on the server, now the same user can restore this bar.gbk on his machine as any other database i.e.. restore the bar.gbk as "myhost:now_i_can_read_it.gdb".

An Implication of this problem is that one can take a backup of the isc4.gdb and then restore it on any other machine and access all the data in that database including the encrypted passwords.

While the SYSDBA password may be set by the vendor who deploys the InterBase software and database, the root/Administrator password is controlled by the end-user. The GDB file can be copied to another system with a fresh installation of InterBase software, with a known SYSDBA password. Then restricted data in the GDB file can be read freely by the end-user. What customers need is a way to protect the database from such kidnapping.

External Tables as Security Problems. Creating an external table does not overwrite a file or truncate its contents. But it does open a read/write file handle for the specified file. The end user cannot delete or update rows, but can select and insert rows. Like with the first problem described above, the ibserver executable has far-reaching privileges, at least on NT.

Solution:

The solution is to recommend to run the InterBase Server as "interbase" or "interbas" user instead of "Administrator" (on NT) or "root" (on Unix). We already have suggested that customers run InterBase as the "interbase" user on Unix, we will also need to make a similar recommendation on NT.

Further to avoid security issues with gbak, gfix and gstat a change will be made so that only "SYSDBA" or the owner of the database will be allowed to do backups and restores and make other modifications to the database using gfix and gstat. (This can be seen as a transition path to providing true database level security where in future versions we could provide special privileges on databases for backup, restore etc.).

Further after creating the backup file gbak will change the mode of that file to read only so that it cannot be overwritten by another user or accidentally.

While restoring we can confirm that if a file is being overwritten than the original file is a database file and it is owned by the same user or the restore is being done by privileged user.