Database Level Security - Functional Specification
The main intention of the features described in this document is to enhance the database security of InterBase, with regards to backup and restore and external files.
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.
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.
A major change which will affect gbak, gfix and gstat would be the inability of general users to take backup, restore or make other database modifications to the database. Only the owner of the database and the "SYSDBA" will be allowed to perform these activities.
When a non-owner (or non-sysdba) user tries to backup a file using gbak, thye will get the following error message, "Cannot backup/restore database must be sysdba or owner of the database".
In case of restoring a database over an existing database using gbak, and in case the old database is not owned by the person performing the restore the following error message will be returned, "Cannot restore over current database, must be sysdba or owner of the existing database."
Currently for NT customers starting the server as an application, after logging in as a user, the server will run as that user. However when InterBase is started as a service it runs under the "system" user. A change will be made during installation the customer will be asked to choose a user as which he wants to run the server. There is no change for Unix customers for this issue as we already recommend that they use "interbas" or "interbase" user to run the Server. All these original files will need to have a have their owners changed from the previous user to the new Interbase user.
Requirements and Constraints
These changes are going to be implemented on all InterBase Super server platforms (as file level permissions provide security on the classic platforms).
The major migration issue facing the user would be the incapacity of the normal user to use gfix, restore databases or take backups of any database not owned by that particular user. Another repercussion would also be the inability of the server to access files created earlier by the interbase server running as privileged user, which cannot be accessed by the new version of InterBase running as regular user.