Security considerations for routines
Developing and deploying routines provides you with an opportunity to greatly improve the performance and effectiveness of your database applications. There can, however, be security risks if the deployment of routines is not managed correctly by the database administrator.
The following sections describe security risks and means by which you can mitigate these risks. The security risks are followed by a section on how to safely deploy routines whose security is unknown.
- NOT FENCED routines can access database manager resources
- NOT FENCED routines run in the same process as the database manager.
Because of their close proximity to the database engine, NOT FENCED
routines can accidentally or maliciously corrupt the database manager's
shared memory, or damage the database control structures. Either form
of damage will cause the database manager to fail. NOT FENCED routines
can also corrupt databases and their tables.
To ensure the integrity of the database manager and its databases, you must thoroughly screen routines you intend to register as NOT FENCED. These routines must be fully tested, debugged, and exhibit no unexpected side-effects. In the examination of the routine, pay close attention to memory management and the use of static variables. The greatest potential for corruption arises when code does not properly manage memory or incorrectly uses static variables. These problems are prevalent in languages other than Java™ and .NET programming languages.
In order to register a NOT FENCED routine, the CREATE_NOT_FENCED_ROUTINE authority is required. When granting the CREATE_NOT_FENCED_ROUTINE authority, be aware that the recipient can potentially gain unrestricted access to the database manager and all its resources.
- FENCED THREADSAFE routines can access memory in other FENCED THREADSAFE routines
- FENCED THREADSAFE routines run as threads inside a shared process.
Each of these routines are able to read the memory used by other routine
threads in the same process. Therefore, it is possible for one threaded
routine to collect sensitive data from other routines in the threaded
process. Another risk inherent in the sharing of a single process,
is that one routine thread with flawed memory management can corrupt
other routine threads, or cause the entire threaded process to crash.
To ensure the integrity of other FENCED THREADSAFE routines, you must thoroughly screen routines you intend to register as FENCED THREADSAFE. These routines must be fully tested, debugged, and exhibit no unexpected side-effects. In the examination of the routine, pay close attention to memory management and the use of static variables. This is where the greatest potential for corruption exists, particularly in languages other than Java.
In order to register a FENCED THREADSAFE routine, the CREATE_EXTERNAL_ROUTINE authority is required. When granting the CREATE_EXTERNAL_ROUTINE authority, be aware that the recipient can potentially monitor or corrupt the memory of other FENCED THREADSAFE routines.
- Write access to the database server by the owner of fenced processes can result in database manager corruption
- The user ID under which fenced processes run is defined by the db2icrt (create
instance) or db2iupdt (update instance) system
commands. This user ID must not have write access to the directory
where routine libraries and classes are stored (the function subpath
under the sqllib path). This user ID must
also not have read or write access to any database, operating system,
or otherwise critical files and directories on the database server.
If the owner of fenced processes does have write access to various critical resources on the database server, the potential for system corruption exists. For example, a database administrator registers a routine received from an unknown source as FENCED NOT THREADSAFE, thinking that any potential harm can be averted by isolating the routine in its own process. However, the user ID that owns fenced processes has write access to the sqllib/function directory. Users invoke this routine, and unbeknownst to them, it overwrites a library in sqllib/function with an alternate version of a routine body that is registered as NOT FENCED. This second routine has unrestricted access to the entire database manager, and can thereby distribute sensitive information from database tables, corrupt the databases, collect authentication information, or crash the database manager.
Ensure the user ID that owns fenced processes does not have write access to critical files or directories on the database server (especially sqllib/function and the database data directories).
- Vulnerability of routine libraries and classes
- If access to the directory where routine libraries and classes
are stored is not controlled, routine libraries and classes can be
deleted or overwritten. As discussed in the previous item, the replacement
of a NOT FENCED routine body with a malicious (or poorly coded) routine
can severely compromise the stability, integrity, and privacy of the
database server and its resources.
To protect the integrity of routines, you must manage access to the directory containing the routine libraries and classes. Ensure that the fewest possible number of users can access this directory and its files. When assigning write access to this directory, be aware that this privilege can provide the owner of the user ID unrestricted access to the database manager and all its resources.
Deploying potentially insecure routines
If you happen to acquire a routine from an unknown source, be sure you know exactly what it does before you build, register, and invoke it. It is recommended that you register it as FENCED and NOT THREADSAFE unless you have tested it thoroughly, and it exhibits no unexpected side-effects.
- Run in a separate process, shared with no other routines. If they abnormally terminate, the database manager will be unaffected.
- Use memory that is distinct from memory used by the database. An inadvertent mistake in a value assignment will not affect the database manager.