Abstract

Continuing the series of seldom used commands lurking in the bin directory of your Informix installation directory, today we’re looking at onsecurity.

It is very important to keep your database server and associated files secure; as well as keeping your data safe, later versions of IDS will refuse to start should the base ownership and permissions be too insecure. If your installation has been moved or copied, or other files or directories been added over time, IDS may not be running in the most secure environment.

Shipped with IDS since version 11.50.FC4, the onsecurity utility can check a given directory path is secure, report on any issues found, and can even generate a script to remedy the situation.

Content

onsecurity does not need to run as root or informix, but the running user must have permission to access the directory structure being tested. The most basic form of the command is:

Copy to Clipboard

The above will analyse the given path, and report if it’s trusted or not. Should an issue be found, a report such as the following will be produced:

Copy to Clipboard


The –v option will cause the program to always print the report regardless of where a problem is found or not. Another useful option is –q, this causes the program to run silently, setting an exit status or 0 or 1 – useful should you want to run the program from a script.

If you wish the utility to generate a script with recommended commands to fix the issues, the –r parameter should be used. This will add the commands to the output:

Copy to Clipboard


As the above suggests, any remedy script would need to be run as root to ensure permission to fix the issue.

While onsecurity is aimed at Informix installations, it can be directed to run on any directory tree. There are numerous other parameters to set which users and should or should not be trusted by the utility.

If it turns out that your IDS installation directory is not secure, a script is supplied in ${INFORMIXDIR}/etc named make-informixdir-secure that can automatically fix permissions for the original installation files. Again, this needs to be run as root. This needs to be run with care though, it can potentially reset permission and ownerships that have been intentionally altered, and should only be run as a last resort.

Conclusion

Secure file permission and ownership are an essential part of overall database server security. Running onsecurity regularly on IDS and related files and directories should help flag up any unsecure permissions, and may prevent issue when restarting the database engine.

While important, file and directory permissions are only a small part of a much larger database security picture. For a full and extensive database security review, please see our Database Vulnerability Assessment here.

Disclaimer

The code fix suggested above is provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.