With more organizations taking a ‘Secure by Design’ approach, one has to look at how the current security scheme is configured to determine if this objective is being met.
IBM i doesn’t make this easy.
Left at the system defaults, most objects – including database files – are created with the default, *PUBLIC authority set to *CHANGE. Obviously, this setting provides every profile with the ability to modify the data. Even worse is when the *PUBLIC authority is set to *ALL, allowing the entire table to be cleared or deleted. But even when *PUBLIC is set to *USE, there’s risk. While the data can’t be modified, the risk exists that files containing unencrypted Personally Identifiable Information (PII) or an organization’s intellectual property (IP) can be downloaded or viewed by anyone with access to the system.
The only authority setting that may be providing some protection in these scenarios is the *PUBLIC authority of the library containing the database. One must have *EXECUTE authority (a subset of *USE) to the library to access one of its objects. If a library is set to *EXCLUDE, users will not be able to access the objects in the library unless they have been explicitly authorized to the library or they have *ALLOBJ special authority. Unfortunately, most IBM i libraries are not set to *PUBLIC *EXCLUDE. Instead, most libraries’ *PUBLIC authority setting is either *USE or (the default) *CHANGE, leaving unsecured database files vulnerable.
Simply run the following SQL provided as an example in Access Client Solutions (ACS) Run SQL Scripts.
-- Database physical files that ANY user can (at least) read.
--
WITH libs (lib_name) AS (
SELECT object_name
FROM qsys2.object_privileges
WHERE system_object_schema = 'QSYS' AND object_type = '*LIB' AND
user_name = '*PUBLIC' AND
data_execute = 'YES' )
SELECT *
FROM libs, qsys2.object_privileges
WHERE system_object_schema = lib_name AND object_type = '*FILE' AND
user_name = '*PUBLIC' AND
data_read = 'YES' AND object_operational = 'YES' AND
('PF' = (SELECT objattribute
FROM TABLE (
qsys2.object_statistics(lib_name, '*FILE', object_name)
)));

Note that the authority listed in the highlighted Object Authority column in Figure 1 tells the true extent of the vulnerability. If the authority is *CHANGE, then everyone can, not just read or download the file, but update it as well. If the setting is *ALL, literally anything can be done to this file – query, copy, clear or delete.
If you find that you have vulnerable data on your system, we encourage you to use the IBM i Authority Collection feature to determine which profiles are accessing the data and what authority they need to successfully perform the access. Once this analysis is complete, you can authorize those profiles and then secure the data – that is, set *PUBLIC to *EXCLUDE. This way you are assured that processes needing access to the data can still do so while preventing access to the rest of the system.
Our IBM i Security Discovery services will reveal all the hidden risk in your system, including an analysis of unsecured data. In addition, our exit point software, SafeNet, is designed to prevent unauthorized access to unsecured data via network interfaces like ODBC, FTP, and others.
Contributed by:
Carol Woodbury
IBM i Security Advisor
Kisco Systems
RELATED POSTS
BROWSE KISCO U
PRODUCT CONTENT