I Have All Object Authority And I’m Not Afraid To Use It!

Lord Acton, a British historian, introduced us to the expression “Power tends to corrupt; absolute power corrupts absolutely!” While the true source of these words of wisdom is sometimes disputed, the gist is simple enough: Being in a position of supreme power or authority often leads to a person abusing that power. That’s certainly how most dictators got started!

When it comes to security on IBM Power Servers running IBM i, a common challenge for many organizations is the number of users with too much power. These users can potentially circumvent application controls, override security restrictions for themselves and others, change critical server configuration settings, and even cover their tracks while they do it.

As you’ll learn in this first part of a two-part article, “All Object” (*ALLOBJ) authority is probably the best known and most feared authority within the IBM i security and auditing community. However, there are many other way that users can exceed their appropriate level of access.

What are we afraid of?

Let’s start by defining what a “powerful” user is. While there’s no textbook definition, for our purposes, it’s any user that meets at least one of the following criteria:

• One or more of eight special authorities (administrator privileges)
• Excessive private authority to critical objects
• Command line privileges through one or more interfaces

This consolidation of authorities is represented in the following table:

If consolidated authority gives a user access beyond their business requirement, there’s an increased risk that they will view, change, or delete data.

In a recent Powertech State of IBM i Security Study, where 244 IBM i servers and partitions were audited, only 7 of the systems reviewed had 10 or fewer users with *ALLOBJ authority. This is "root" access with unrestricted authority to every object on the system. Almost as concerning, 40% of users were granted "Job Control" (*JOBCTL) and "Spool Control" (*SPLCTL). Job Control provides the ability to start and stop jobs and subsystems, and Spool Control enables users to fully access any spooled file in any output queue, regardless of imposed restrictions. 

Typically, command line privileges are required to invoke commands that allow data or server access. It’s often argued that there’s only a minimal risk if a user has authority to an object or function, but lacks the access to the commands to access the object or run the function.

One mistake many organizations make is thinking that the only way to enter commands is through the command line on a “green screen.” This is just one of several ways that users can enter commands. Some methods do not even require command line permissions—yes, you read that correctly!

There is also overlap with several system configuration controls, including:

• The security level (QSECURITY) of the server
• The level of *PUBLIC authority to critical objects
• The configuration of a command’s runtime setting for “allow limited users”

During the 15+ years that Powertech has tracked statistics, we’ve seen a shift towards servers attaining the minimum recommended security level of 40. (It’s likely that a good portion of those migrations originated from the change made by IBM in the default level on newer servers, but it’s still a good shift.)

Many people are surprised to learn that much of a user’s “hidden” power is not in the form of administrative privileges, but a result of permissive public authority. Unlike other platforms, where no authority granted means no access, IBM i provides users a default authority called *PUBLIC. Problems develop when public authority remains at its shipped default value of *CHANGE, which gives any user the ability to view, change, and delete data.

In every edition of the State of IBM i Security Study since 2004, permissible public access forces us to include average users in the definition of “powerful” users.

The study also identifies two alarming configuration vulnerabilities regarding public authority:

• Only 21% of libraries on the sampled systems restricted *PUBLIC access. This means that any user can access 79% of libraries and attempt to access the objects inside. If best-practices dictate that the public be given the least amount of access, we are falling far short of this goal.
• Only 4% of newly created objects are restricted from *PUBLIC access. Combine this with the open library authority and it’s obvious that data access is not being controlled.

Many components have to be configured correctly to control powerful users. Next, we’ll explore ways to identify, contain, and audit the activities of these users.

Read the second part of this article here.