Carol describes security considerations one should make when deciding which profile will own IBM i objects.

By Carol Woodbury

We seem to always focus on the *PUBLIC authority of objects and whether they’re secured with an authorization list. But little is said about ownership. I thought you might find a brief tutorial and considerations that you’ll want to make helpful.

Ownership Facts

First, let’s look at some facts about object ownership on IBM i.

Fact #1: All objects must have an owner. In fact, this is the purpose of the IBM-supplied profile QDFTOWN. For example, when an object is restored to the system where the object on the media is owned by a profile that doesn’t exist on the system, the object is owned by QDFTOWN. You’ll often see vendor fixes owned by QDFTOWN because they’re developed one-off from their normal build process, so the developer who created or tested the fix owns the objects associated with the patch. But since that developer profile won’t exist on customer systems, when the fix is restored, the system changes the owner to be QDFTOWN.

Fact #2: When you own an object, you have *ALL authority to the object.

Fact #3: When a group owns an object, every member in effect owns the object. In other words, group members have *ALL authority to the objects owned by their group(s).

Fact #4: While you can remove the authority an owner has to its objects, the owner can always give it back to itself. (This is the only time you can give yourself authority you don’t have.)

Fact #5: Information about the object owner is stored in the object’s header, which means it’s saved and restored with the object.

When Can Ownership Make a Difference?

Probably the most obvious case where ownership makes a difference is when programs and service programs are configured to adopt authority—that is, the User Profile attribute of the program is set to *OWNER. Obviously, if a program is owned by and adopts QSECOFR, a user has significantly more power available when the program runs than when running a program owned by a profile that has no special authorities and owns no other objects. This is the most obvious example. Let’s look at some other, less-obvious examples.

Ownership also matters when the owner is a group profile. For example, the ownership of user profile objects requires consideration. As facts 2 and 3 state, the owner and the owner’s members have *ALL authority to the objects owned by the group. If an end-user group owns user profiles, for example, then it’s quite easy to run remote commands or submit jobs to masquerade (run as) a different user or even elevate your rights using someone else’s profile to do your dirty work.

When a group profile is the owner of an application and, to use the application, one has to be a member of this owner group profile, every user of the application has *ALL authority to all application objects. Stop and think about this for a moment (or two or ten until it really sinks in as to what this means). In the good ol’ green-screen days, this was not an issue. But today, our systems are accessed by many types of connections, such as FTP, ODBC, and DDM. In addition, remote commands can be run against the system via a Windows command line, rexec, DDM, etc. Users can easily discover how to download data into an Excel spreadsheet using ODBC or an Access Client Solutions (ACS) data transfer; a simple Internet search brings up step-by-step instructions. In this configuration (that application users are a member of the owning group), it doesn’t matter what the *PUBLIC authority setting is—even if it’s *EXCLUDE. The authority their group provides them will give the application users *ALL authority. With *ALL authority, they can (obviously) do anything with the data—download it, upload it, clear the file, replace a program. In other words, the application is not at all secure!

A far less obvious issue is when a group profile owns an authorization list. Often, users added to an authorization list have been carefully reviewed and only added when they have a business need to access the data secured by the list. When a group profile owns the authorization list, the group members have *ALL authority to everything secured by the list (not just *ALL to the authorization list). This access is usually quite unintended. I ran into this problem at a client’s company not long ago. An authorization list was securing some sensitive files. Users authorized to the authorization list were added only via an approved access request. However, the list wasn’t owned correctly and unbeknownst to the data owners, members of the owning group profile with no business need had access to the sensitive data secured by the authorization list.

When System-Supplied Profiles Own Objects

I am not a fan of having applications owned by system profiles because system-supplied profiles are often made to be group profiles. See discussion above for the dangers of having a group profile own an application! In addition—right or wrong—many vendors have used the system-supplied profiles to own their applications. QPGMR seems to be the most popular…and typically creates the most exposures. QPGMR tends to be the group profile for developers, so developers end up owning everything that QPGMR owns. When QPGMR owns vendor products, you have developers owning the vendor products. If nothing else, this causes separation-of-duty issues because the developers have *ALL authority to products that are used to log or control their access! Worse is when ownership allows developers to surreptitiously change configuration settings.

How Can I Tell What Objects a Group Owns?

If you’re thinking you should take a look to see what your group profiles own, I’d say that’s a good idea! A couple methods exist for listing the objects owned by a group. You may be familiar with the option on Display User Profile (DSPUSRPRF) that allows you to list the objects owned by a profile. The following lists the objects owned by GROUP_A:

DSPUSRPRF USRPRF(GROUP_A) TYPE(*OBJOWN)

The problem with using this command is that it doesn’t list objects that reside in the IFS. A better interface is the Work with Objects by Owner (WRKOBJOWN) command, which lists objects in both libraries and directories.

Summary

You may not have considered the ownership of objects to be a significant security setting prior to this, but I hope you’ll make ownership of objects a consideration going forward.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility