Admin Alert: Six Ways to Mess Up i5/OS User Profiles Security (And What To Do About It)

March 11, 2009 Joe Hertvik

Compared to other platforms, the i5/OS operating system is one of the more secure systems available today. However, that doesn’t mean there aren’t any security holes. This week, let’s look at some common user profile security problems that iSeries, System i, and Power i shops encounter and talk about how you can counter these issues.

Auditing Your User Profiles

To truly troubleshoot the issues I’m discussing here, you’ll need to create a user profile information file (UPIF). It’s easy to create a UPIF and once you have it, you can query individual user profiles to determine which profiles have which user profile problems. For step-by-step instructions on how to create a user profile information file, see an earlier article I wrote titled The Joys of Creating User Profile Information Files.

Now, let’s look at six of the more common user profile security issues you’ll face on an i5/OS system. These problems are:

Handing out *ALLOBJ authority to whomever asks for it, especially programmers
Giving *ALLOBJ authority to group profiles
Allowing user profiles to retain default passwords
Allowing default *PUBLIC access to newly created i5/OS objects
Passwords that never expire
Allowing users to create easily guessed passwords

While these aren’t the only security issues you’ll face, you’ll be able to improve your security exposure quite a bit if you get a handle on these problems.

Problem 1: Handing Out *ALLOBJ Authority To Whomever Asks For It, Especially Programmers

One of the worst things you can do is to indiscriminately provide all object (*ALLOBJ) authority to multiple users on your system. I’ve been in shops where administrators think that it’s okay to provide this authority to one or two power users or vendors, because “…they really can’t do their jobs without it.” I also worked in one horrendously brain-dead place where their solution to access issues was to give *ALLOBJ authority to every user profile in the shop. That was a bad move.

The problem with granting *ALLOBJ authority is that if the user has it, there is almost nothing inside i5/OS that the user cannot reach, corrupt, and destroy. If you really want to tempt fate, give *ALLOBJ authority to your programmers who can easily make innocent mistakes that corrupt data and destabilize your system But take faith, there are better alternatives to *ALLOBJ authority for programmers and this article from a few years back by Wayne O. Evans discusses some of the issues involved with *ALLOBJ programmer access to data.

For more information on the perils of *ALLOBJ access and how to scale it back, see the articles in the RELATED STORIES section below.

Problem 2: Giving *ALLOBJ Authority To Group Profiles

Providing a group profile with *ALLOBJ authority is more dangerous than giving it to an individual user. Because i5/OS authority checking will also grant access based on group profile membership, if you give *ALLOBJ authority to a group profile, that authority is automatically transferred to all the individual user profiles who are members of that group.

To understand better how i5/OS performs authority checking when a user tries to access an object, see this article on the seven levels of i5/OS and OS/400 authority checking. After reading it, check some of your more critical group profiles and make sure that they don’t have more access than is healthy for your shop.

Problem 3: Allowing User Profiles To Retain Default Passwords For Accessing The System

Default i5/OS and OS/400 passwords occur when a user profile’s password value is the same as its corresponding user profile name (i.e., a user profile called JOE has a password of JOE). Active default passwords are a security risk because external hackers as well as malicious internal users can easily guess their existence and use them to sign on and create mischief on your system. Setting up a zero tolerance policy to detect and remove default passwords is in your best interests as a system administrator.

To help you detect and deal with default passwords, I created two articles exploring the ramifications of default passwords and how to detect and prevent them. Check out part 1 and part 2 of this series for more information.

Problem 4: Allowing Default *PUBLIC Access To Newly Created i5/OS Objects

By default, the Create Default Public Authority (QCRAUT) system value is set to *CHANGE. This means that for any new system objects that reference QCRAUT for default authority settings, those objects will be assigned *CHANGE authority for the *PUBLIC user. *CHANGE authority allows a user to read, modify, and delete file records in a physical or logical file. For a program object, *CHANGE authority allows the user to execute or modify the object. To shore up i5/OS security, you can read my two-part article on limiting *PUBLIC access to i5/OS objects. Follow these links to read part 1 and part 2.

Problem 5: Passwords That Never Expire

Because user passwords are frequently discovered or given away, you need to force your users to periodically change their password values. By default, i5/OS user profiles take their password expiration time limit from a system value called the Password Expiration Interval (QPWDEXPITV). This is accomplished by setting the user profile Password Expiration Interval (PWDEXPITV) parameter to *SYSVAL, which instructs i5/OS to refer to the QPWDEXPITV system value for the user’s expiration interval. Be careful, however, because the shipped value for QPWDEXPITV is *NOMAX, which means that any user profiles referring to the password expiration system value will never be forced to change their password by the system. If you don’t change that system value, most of your user profiles will have passwords with an unlimited expiration interval. Lowering the QPWDEXPITV system value to something reasonable, say 90 days, will have an impact on most of the user profiles in your shop.

Also note that the password expiration interval value can be overridden in a user profile. So even if you set QPWDEXPITV to a lower value than *NOMAX, a user with security administrator (*SECADM) authority could override his own user profile password expiration value and set it back to *NOMAX. For more information about password expiration intervals, see Creating an i5/OS User Profile Architecture. You can also discover who has overridden their PWDEXPITV user profile values by querying your user profile information file.

Problem 6: Allowing Users To Create Easily Guessed Passwords

One of the most chronic i5/OS security problems is also one of the easiest problems to fix. Many shops allow users to define easily guessed passwords for themselves, including default passwords; passwords that include easily guessed words; passwords including common numbers that have meaning for the user; and passwords that are similar to older passwords used by the user. To explain how i5/OS can help you create sufficiently complex passwords that protect system security while preventing your users from being unduly restricted, check out this article on eliminating easy-to-guess user passwords.

The /QOpenSys Matryoshka Doll

My shop found an unusual AS/400 Integrated File System (AS/400 IFS) issue this week. We used the Work with Object Links (WRKLNK) command to open the /QOpenSys file system to check out an issue in the bin (binary object) sub-directory, when we spotted another directory under /QOpenSys, which was also called . . . /QOpenSys!!! And to make matters stranger, this /QOpenSys/QOpenSys folder contained all the same directories that were present in the regular /QOpenSys folder.

Sensing something wrong, we looked closer at the /QOpenSys/QOpenSys folder and to our amazement, we found and opened a third nested /QOpenSys folder, which made our current folder path /QOpenSys/QOpenSys/QOpenSys. And like the second /QOpenSys folder, the directory structure from the original /QOpenSys directory was also present in this sub-folder.

Like an i5/OS Matryoshka Doll, we kept exploring nested /QOpenSys folders until we got to the last /QOpenSys sub-folder, which was located 15 layers deep from the root directory (/) of the AS/400 IFS. What was strange about this final /QOpenSys folder was that its directory structure looked like this.

                             Work with Object Links

Directory  . . . . :
/QOpenSys/QOpenSys/QOpenSys/QOpenSys/QOpenSys/QOpenS >

 Type options, press Enter.
   2=Edit   3=Copy   4=Remove   5=Display   7=Rename   
   8=Display attributes  11=Change current directory ...

 Opt   Object link            Type     Attribute    Text
       bin                    SYMLNK
       etc                    DIR
       lib                    SYMLNK
       sbin                   DIR
       usr                    DIR
       var                    DIR
       ICHA1.PNR              STMF
       QIBM                   DIR
       QOpenSys               SYMLNK

When we tried to open the Symbolic Link version of this /QOpenSys directory (designated by the SYMNK attribute type), we received an error saying “Path name resolution causes looping.”

Contributing to the weirdness, we checked the /QOpenSys directories on the other five System i 550 partitions that are running in our shop. Four out of the five partitions that we checked had the same recursive /QOpenSys directory structure.

So I’ll direct this question to all the Admin Alert readers out there. Is this a common situation? If so, what causes it and what if anything should be done about it? It doesn’t seem to be affecting our applications, but I haven’t seen much written about this problem in the available literature. Let me know what you think by contacting me via the IT Jungle Contacts page. All responses will be tallied and printed in a future column. And in the spirit of this column, there may even be some no-prizes involved. 😉