December 20, 2011 - Vol 1, Issue 6
Live Training from The 400 School
Security Workshop and Operations Workshops presented by The 400 School, Inc and SecureMyi.com


Security Compliance Automation Tools - Designed by Carol Woodbury - Security Policy Compliance - Vulnerability Assessments - Audit Journal Reporting - Register today for a FREE Trial! - Brought to you by SkyView Partners


Feature Article


The Problem With Too Many IBM i Private Authorities

By Dan Riehl

When an object is created, it is owned by either the user that created the object or by the user's primary group profile. Ownership depends on the OWNER attribute of the user profile. If the value is set to OWNER(*GRPPRF), objects created are owned by the user's primary group, if OWNER(*USRPRF) is specified, objects are owned by the user, not the group.

To view objects owned by a user profile you can use the command:

WRKOBJOWN USRPRF(DRIEHL)

In addition to ownership, a user can be assigned explicit private authority to an object using the command GRTOBJAUT(Grant Object Authority), or by adding a user from the EDTOBJAUT(Edit Object Authority) display.

Normally, we want to avoid adding private authorities to an object. We typically want all of our User objects to be secured by an authorization list containing group profile names, and not individual user names.

Once we start down the path of assigning private authorities at the user level, rather than at the group profile level, we begin to build an overly complex security scheme that will require constant maintenance as users come and go. Using Authorization Lists and Group Profiles in our authorization settings provides the least complex configuration, and requires the least amount of on-going maintenance. We do not have to make additions and changes every time a new user is added, or when a user's job function changes. In those cases, we simply assign the user to the correct group profile.

Read More.

In This Issue

Featured Article - Too many Private Authorities

Featured Video - Misconceptions - Limited Capabilities

Security Shorts - Stop Adoption of Authority

Industry News and Calendar

Security Resources


Quick Links

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home and Archives



Please Visit Our Sponsors


Platinum Sponsor
      The 400 School, Inc


Gold Sponsors
      Skyview Partners, Inc.


IBM i Security and Audit Resources

Free Security Videos from Securemyi.com

IBM i Security Reference - IBM i 6.1

IBM i Security Reference - IBM i 7.1

PCI SSC Data Security Standards

COBIT Framework - ISACA

HIPAA Resources

HITECH Enforcement

CISSP - Certification






Follow securemyi on Twitter




Follow securemyi on YouTube
Carol Woodbury gives you seven quick tips for passing your audit. Download her white paper now! Brought to you by SkyView Partners



Subscribe to the SecureMyi Security Newsletter - Get Dan Riehl's book PowerTips for IBM i Security

IBM i Security News Bytes

Raz-Lee's iSecurity Now Supports QSH and PASE Logging, Reporting & Alerting.
Logging of these environments is unique to iSecurity. Standard IBM 'CD' Command-string entries can now be written to QAUDJRN for command events in PASE and QSH.
More information on this added iSecurity Capability

IBM i and i5/OS Security and Compliance- A Practical Guide
This great book by Carol Woodbury is now available at The MC|Press Bookstore
Get your copy of the book online

Congratulations to Jeff A. of Indianapolis
Jeff won our "New Subscriber" prize of a $500 Best Buy Gift Card. Just in time for the holidays.

The 400 School, Inc. and SecureMyi.com
Live Online Security Workshop from The 400 School and SecureMyi.com
Dan Riehl presents his 4-Day Live Online Hands-on Security Workshop for the IBM i
Jan 17-20, 2012. Very limited seating. Register early to reserve your seat in the class.



IBM i Security Calendar of Events

Live Security Webcasts for IBM i

Natural Security - Lean and Practical Approaches to Security Projects
Presented by RJS Software Systems
January 12 - 11:00 a.m. CST
More Information and Register to Attend

Automating IBM i Security Administration Tasks including Compliance
with Carol Woodbury - Sponsored by Skyview Partners
January 25 - 10:00 a.m. PST
More Information and Register to Attend



More Security Events

Jan 17-20 - The 400 School - Live Online Security Workshop

May 6-9 - COMMON-A User Group - Annual Conference and Expo - Anaheim, CA


Security Workshop and Operations Workshops presented by The 400 School, Inc and SecureMyi.com


Vault/400 - Modernize your Backup and Recovery Plan

Featured YouTube Educational Video

IBM i Security

Popular Misconceptions on User Limited Capabilities

Featured Video - IBM i Security

Security Shorts
Stop Adoption of Authority in the Calling Program

IBM has provided the MI built-in function MODINVAU to modify the adopted authority attributes of a program's invocation level. In effect, it allows you to control the propagation of adopted authority from within a program.

The MODINVAU function has one argument that can contain one of two values:

  • Hex 00 = Don't suppress adopted authority
  • Hex 01 = Suppress adopted authority

If '00' is specified, normal propagation of adopted authority to called programs and subprograms occurs. If '01' is specified, adopted authority is not propagated to called programs and subprograms. Here's an example of using the function in a Control Language program.


 Pgm
    CallPrc    Prc( '_MODINVAU' )   Parm(x'01')
    /* Suppress Adopted Aut */
    Go Main
 EndPgm

This simple program uses the MODINVAU function to flip the invocation authority switch so that any adopted authority is not propagated to subsequent programs. In this case, the program takes us to the menu name MAIN, and adopted authority is not in effect at the MAIN menu. When we exit from the MAIN menu by using F3, we return to the calling program, where any adopted authority is still in effect.

I suggest using this MI function in your application development to achieve more granular control over adopted authority. If a program needs adopted authority, create the program to adopt. But then also use the MODINVAU function to block the adopted authority from traveling down the stack to other programs. It's a much more elegant design than trying to take control of all programs by using the USEADPAUT(Use Adopted Autority) program attribute.

If your adopting programs don't pass on their adopted authority, many security issues can be alleviated.

You can read more about MODINVAU in the IBM Information Center article on MODINVAU.

Sponsored Links

IBM i, iSeries and AS/400
Security Services from SecureMyi

Expert Level Security Consulting
IT Security and Compliance Group, LLC

In Depth Security Assessment of IBM i
Upgrade to QSECURITY level 40 or 50
Forensic Research and Analysis
Audit Assistance and Remediation
Security Training for IT and Audit Staff
Security Software Selection & Configuration
Customized Security/System Programming


Live Training from The 400 School, Inc

Live Online Hands-On Workshops

Now Accepting Credit Cards

Expanded Security Workshop-Jan 17-20
Interactive COBOL Programming - Jan 23-27 Sys Operations Workshops - Feb 27-Mar 2
Sys Administration and Control - Mar 12-16
Interactive RPG IV Programming - Mar 26-30


Classes at your offices. IBM i, iSeries AS/400?  The 400 School, Inc.

Subscribe to the SecureMyi Security Newsletter - Get Dan Riehl's book PowerTips for IBM i Security

Send your IBM i Security Related News and Events!           Advertise in SecureMyi.com Security Newsletter

Copyright 2011 - SecureMyi.com, all rights reserved

SecureMyi.com | St Louis MO 63017