Just like IBM i 7.5 brought many new IBM i Security features and a re-emphasis on IBM’s commitment to secure by design, so does IBM’s recent announcement of version 7.6. Here, Carol Woodbury explores the highlights of what’s new and changed in the area of IBM i Security.
New Password System Value Defaults for New Installs
Setting the tone for their commitment to secure by design, IBM has changed the default settings for two password system values:
Note that these changes only apply to new installations. Your system value settings will not be changed on an upgrade or if you restore your system value settings from another system.
Authority Requirements Realigned and Increased Use of Function Usage
While IBM i 7.5 brought many resets of objects’ *PUBLIC authority, IBM i 7.6 brings several re-alignments of the authorities required to run several functions. First and foremost, the authorities required to list information using an SQL view now match the authority requirements of the corresponding CL command. Some views allowed users to display information without having the appropriate authority and that’s been fixed.
In addition, many of the network configuration attributes now need *IOSYSCFG special authority to manage and *IOSYSCFG or authority to the QIBM_IOSYSCFG_VIEW function ID (newly defined in IBM i 7.6 and available in the Function Usage under the Security category in Navigator for i) to view. Other views also require additional access but the area of network configuration (think lines, controllers and devices as well as remote databases and DDM) has the most extensive changes. The new QIBM_IOSYSCFG_VIEW function ID allows you to provide access to users that need to view network configuration information but do not need to manage it nor do they need the full capability that *IOSYSCFG special authority provides.
File Share Management Becomes Easier
IBM i 7.6 also introduces the QIBM_QZLS_NETSVR_SHARE function ID. The NETSVR_SHARE function provides the ability to control who can create file shares. Prior to this, anyone with *IOSYSCFG special authority could create a file share. In addition, the owner of the object could create a file share for any of their owned objects. Now, to create a file share, users will require either *IOSYSCFG special authority or authority to the QIBM_QZLS_NETSVR_SHARE function.
Then, to make file share clean up easier, a new object auditing value has been created. *NETSMBSVR can be specified only for the QAUDLVL system value (not at the user level). This new action generates a VP entry and provides connection details when a user maps a drive to a file share. Hooray! This is one of my favorite additions to IBM i 7.6! While you can piece the information together using Authority Collection starting in IBM i 7.4, it’s not easy to analyze which file shares are in use, when they’re used and which profiles are using them. By having an audit entry that logs the connect and disconnect, the user and the share name, this analysis becomes a snap. Simply add *NETSMBSVR to QAUDLVL, wait a few days, retrieve the VP entries and do the analysis!
New IBM-supplied User Profiles and An Important Special Authority Adjustment
Six new IBM-supplied profiles will be created when you install IBM i 7.6:
The profiles named ‘_NC’ are the counterpart to the non-NC version (QPGMR, QSECOFR, QSYSOPR and QUSER) but in this case, the profile can’t be changed (for example, to give it additional special authorities) nor can it be given a password. Many processes that used to run as the non-NC version are now running as the _NC profile. For example, ODBC pre-start jobs that used to start up as QUSER now start as QUSER_NC. I applaud this move. I’ve seen many organizations overload IBM-supplied profiles with additional special authorities causing system processes to run with excess capabilities, potentially giving users unintended access.
Another very important change is to the QPGMR profile. When IBM i 7.6 is installed *SAVSYS will be removed, leaving it with only *JOBCTL. This is a fantastic change! Zero reasons exist for someone in the programmer role to have the capabilities that *SAVSYS special authority provides. So appropriately, the QPGMR_NC profile will also only have *JOBCTL.
New View for Analyzing Authority Collection for IFS Objects
I’m particularly excited about this enhancement. My colleague Steve Riedmueller and I were invited to provide input into the improvement of how the Authority Collection information is reported for IFS objects. The initial view for IFS objects (QSYS2.AUTHORITY_COLLECTION_FSOBJ) provided authority settings using the terminology for objects in libraries. For example, the Detailed Required Authorities showed the authorities as *OBJOPR, *ADD, *UPDATE, *READ, etc. Different terminology is used for authorities in the IFS so this was highly confusing and made it very difficult to implement the actual authorities required. In addition, some of the fields in the view have no meaning for IFS objects. A new view, QSYS.AUTHORITY_COLLECTION_IFS is being provided that will report all authorities using the IFS authority nomenclature (e.g., *R, *W, *X), list only the fields of the Authority Collection record that make sense for IFS objects and omit some records that don’t need to be analyzed. Bonus … it will be provided in IBM 7.6 and will also be provided in 7.5 via TR 9. Woo Hoo!
Profile Protection
One of the exposures of granting users *ALLOBJ special authority is that the operating system considers them to have *ALL authority to every object on the system – including other user profiles – including user profiles that have more special authorities beyond *ALLOBJ. This provides the opportunity for the profile with only *ALLOBJ to exploit profiles with more special authorities. For example, a profile with just *ALLOBJ could submit a job to run as a service profile you’ve configured to have all special authorities and create a new profile with all special authorities, then sign on with this newly created profile and perform any task they want, including deleting profiles, changing the ownership of objects, modifying programs to adopt the newly created profile, turn off auditing, create a share to root (‘/’), etc. Of course, the best option is to remove the users’ *ALLOBJ but what if you can’t?
To protect powerful profiles from being exploited, the QIBM_RUN_UNDER_USER_NO_AUTH function ID has been created. (Don’t try to make sense of the function name ... just focus on what it can do!) To use this new function ID, log into Navigator for i, then go to Security-> Function Usage, right click on QIBM_RUN_UNDER_USER_NO_AUTH and choose Change. Add the profiles you want to protect from exploitation to the Access Denied column. Profiles listed as Denied cannot be used by any process that allows elevation of authority (think SBMJOB to run as another profile or doing a profile swap. For the complete list of processes that will check this function ID, see Appendix H in the IBM i Security Reference manual.)
Your natural instinct may be to add all of your powerful profiles to this function ID to prevent them from being exploited. I don’t know about you, but before I configure something that has the potential to break existing processes, I like to do a bit of research. Fortunately, IBM has added a new user audit action that will allow us to find out if any of the processes listed in Appendix H use any of the profiles you want to protect. Simply run the Change User Auditing (CHGUSRAUD) command specifying AUDLVL(*AUTWARN) for each of the profiles you intend to protect. (Note: this value can only be specified at the user level, not in QAUDLVL.) Then, after a period of time, pull the GR audit entries, looking for the Usage Warning entries. This SQL should give you what you need:
SELECT entry_timestamp,
qualified_job_name,
user_name as user,
user_profile_name AS profile_to_protect,
function_name,
function_registration_operation,
usage_setting,
previous_usage
FROM TABLE (
systools.audit_journal_GR(starting_timestamp =>
CURRENT TIMESTAMP - 7 DAYS) )
WHERE function_name LIKE ('QIBM_RUN_UNDER%');
stop;
When you add the profile you’re protecting to the QIBM_RUN_UNDER_USER_NO_AUTH function ID, you’ll see a GR entry for the addition. You’ll also see a failure entry if someone subsequently attempts to use the protected profile.
How would I use this new feature? I’d look to protect all of my system and security administrators’ profiles along with QSECOFR (after I’ve audited the profile) and the owner profiles of the major applications running on my system. ‘Power’ comes in many forms and application owners own and therefore, have all authority to, the application data. I’d say that’s a lot of power (!)
New Appendix H Documenting Function ID Controls
The Function Usage feature found under Security in Navigator for i is being used more and more but how does one determine what each of the function IDs do or enable? Appendix H has been added to the IBM i Security Reference manual and it lists each function ID and what it controls. Hallelujah! Prior to this it was almost impossible to understand the ramifications of granting a user or group access to these functions. Thank you to the IBM Rochester Security team for creating this documentation! This is one of my favorite security features of IBM i 7.6 and it can (and should) be used even prior to upgrading to 7.6 as a reference to what the functions control (that is, what access they prevent or allow.)
Emphasis on Encryption Technologies
From the ability to encrypt *SYSBASE to updating the Crypto services APIs to sending warning messages when using Navigator for i regarding the use of unsecure ports and unsecured (non https) connections, IBM is emphasizing the need and making it easier to use encryption as one of our layers of defense. For example, the Web Admin interface is now part of Navigator for i. As such, when Navigator detects that it’s running over an unencrypted connection, it will put up a warning message with a link that, if followed will help you assign a digital certificate and configure the server to use an encrypted session. Another Navigator feature that I find incredibly helpful is found under Network -> Servers-> TLS Configuration which will help you configure TLS for the Host Servers as well as deactivate the corresponding unsecure port.
Clean up!
I have long asserted that one needs to clean up their systems and not keep inactive profiles, applications, previous versions of vendor products, etc on their systems. IBM agrees with this strategy and in IBM i 7.6 has cleaned up (removed) technology no longer in use. For example, because the technology has been removed, the Start TCP Server (STRTCPSVR) command no longer supports the following servers: *BOOTP, *DHCP, *DNS, *MGTC, *QOS, and *ROUTED. Another example: the IBM-supplied user profiles QMGTC, QIBMHELP, and QPM400 will be deleted along with any objects that they own when IBM i 7.6 is installed. For the complete list of technologies no longer supported, see the Memo to Users.
But wait, there’s more!
You might notice a glaring omission of the biggest and arguably the most important new security feature of IBM i 7.6 and that’s the addition of Multi-Factor Authentication (MFA). MFA is so important that it deserves its own article so please subscribe to KiscoU and stay tuned!
Besides MFA, even more features than I’ve described have been added to IBM i 7.6 – I’ve just hit some of the highlights. Please do yourselves a favor. Even if you don’t plan to install IBM 7.6 in the near future, I encourage you to review the additions and changes so you can plan for and implement them as soon as you do upgrade.
RELATED POSTS
BROWSE KISCO U
PRODUCT CONTENT
