On Special Authorities

If you have ever done any System administration on an IBM i you have come across special authorities. Special authorities, when assigned to a user (profile), enable the user to perform particular classes of actions. By the way, if you stumbled onto this article by Chance and are a Windows-only person, read on, and just know that "authorities" is IBM for "permissions".

So: Special authorities allow users to perform certain classes of actions. Those classes of actions can be relatively narrow or broad, depending on how IBM created them. For instance I would call the *SPLCTL (Spool Control) special authority narrow in scope; it enables a user to view/modify/delete other users' print jobs. End of story. Other special authorities such as *SECADM (Security Administration) are broader, allow users to perform a wider set of actions.

The decision between creating a broad or a narrow class is one between control and convenience. A broad class is easy to administer, but easily results in capabilities being granted that are not needed to do a Job, violating the principle of granting the "least privilege necessary". A narrow class of activities provides much more fine-grained control, but at the same time it leads to more information having to be supplied by the user who grants the special authority and more decisions to be made.

Let's think outside the IBM i box for a minute so we can get a look at the wider picture. In Windows 10 and its sibling OS Windows Server 2016, Microsoft introduced a large set of fine-grained special authorities, under the Just Enough Administration (JEA) moniker. This is very good from a security perspective; having "narrow" authorities for things like creating a user, reading from the Windows Event Log or adding the local computer to a domain is obviously more fine-grained than having those things lumped together under an "Admin" super-authority. OK? Less comfort, but more control. Good stuff!

Then happened what had to happen. A Windows security expert looked at JEA in detail and found that even with the narrow special authorities that Microsoft had created, many had serious security side-effects. Example? Windows offers a feature called command logging; yes, that is what is named command auditing on IBM i. Commands that are executed are logged to a special place, the Security Audit Journal on IBM i, the Security Event Log on Windows. So where's the problem?

Well, some commands allow a username and password to be specified as command-line parameters. So if all Parameters are logged.... I leave it to the reader to work out the rest and see how the seemingly harmless capability to read from the Windows Event Log suddenly becomes a security liability.

What lesson to draw? A trite one, I am afraid: There are no silver bullets in IT security. Anything even remotely resembling a modern operating system is too complex for simple solutions. That holds Windows, for IBM i or for Unix. I am not saying that narrow special authorities does not Help. On the contrary, it does, for reasons sketched above. But it is still necessary to think of what could cause a security issue; then think of ways to fix that; then to fix it; and then to check and recheck whether it stays fixed. Thus toils Sisyphos.

But as a French man once wrote, Sisyphos enjoyed his work, too.