SecureMyi.com Security and Systems Management Newsletter for the IBM i             February 22, 2017 Issue
Security Training from SecureMyi.com

Security Training from SecureMyi.com




Training from The 400 School



Training from The 400 School



Training from The 400 School

Feature Article

When was your Last SAVSECDTA, SAVSYS, SAVCFG?

         And Where are They?

By Dan Riehl - SecureMyi.com

Backup and Recovery is an area that is critical to the security and integrity of our systems. If someone accidentally wipes out a file, or in the event of a large scale disaster, it's critical we have all of the pieces needed to recover the file, or the entire system.

We typically have a pretty good handle on when we last backed up our User Libraries, our Document Library objects, and the root '/' file system. But what about the last save of the operating system? And what about our user profiles and security data and our system configuration objects? When was that data last backed up? And what tape or other media contains the last backup?

If you need to recover your system, and the Last Save of Security Data(Including User Profiles) was 3 months ago, that is your recovery point for User Profiles and Passwords, Authorization Lists and Private Authorities. Can you recall what your password was 3 months ago? And your End-Users Passwords? You potentially have a real mess on your hands.

When we save a library using the SAVLIB command, objects are marked with the save date and save device information, as long as we specify UPDHST(*YES). But when we save the operating system, the objects that are saved are not marked with the save information. The same is true when we save user profiles and configuration data. The saved objects are not updated with the last save date.

IBM has supplied some special purpose data areas in the QSYS library that are updated with the save date and save device information when we perform certain save operations.

When we save our security data (including user profiles) using the command Save Security Data (SAVSECDTA), the special data area QSAVUSRPRF in QSYS is updated to reflect the save date and time and save device information.

Below is a list of various SAVE commands and the associated QSYS data area. Upon execution of the command, the data area is updated.

Save Command          Data Area Updated 
SAVCFG		      QSAVCFG	
SAVLIB *ALLUSR	      QSAVALLUSR
SAVLIB *IBM	      QSAVIBM	
SAVLIB *NONSYS	      QSAVLIBALL
SAVSECDTA	      QSAVUSRPRF
SAVSTG		      QSAVSTG	
SAVSYS		      QSAVSYS, QSAVUSRPRF, QSAVCFG
SAVSYSINF 	      QSYSINF

Viewing the Last Save Date and Save Device Information

To view the last save information, you display the object description (DSPOBJD), you don't display the content of the data area. You can start with the command Work with Objects (WRKOBJ), as shown here:

WRKOBJ OBJ(QSYS/QSAV*) OBJTYPE(*DTAARA)

This command allows you to work with all the data areas in the QSYS library that start with the characters QSAV. This results in the following display:

Read More . .


In This Issue


Featured Article - Last SAVSYS SAVCFG?

Featured Video - Hijack a User Profile

Security Shorts - *SECOFR User Class?

Industry News and Calendar

Security Resources

Quick Links


Search Security Site for IBM i and i5/OS

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home/Archives




Our Newsletter Sponsors


Platinum Sponsor

    The 400 School, Inc


IBM i Security Resources

IBM i Security Videos - SecureMyi

SecureMyi Newsletter Archives

Search Security for IBM i

IBM i Security Ref - 6.1

IBM i Security Ref - 7.1

IBM i Security Ref - 7.2

QAUDJRN Entries By AUDLVL

QAUDJRN Entry Layouts

RedBook - Security Guide IBM i


Open Security Foundation - DataLoss DB

National Vulnerability Database - NIST

PCI Data Security Standard

COBIT - ISACA

HIPAA Resources

HITECH Enforcement

CISSP - Certification


Follow SecureMyi on Twitter
Follow SecureMyi on LinkedIn=
Follow SecureMyi on YouTube


Training from The 400 School


Training from The 400 School

Featured YouTube Educational Video

IBM i Security

Are your User Profiles Vulnerable to Profile Hijacking?

Featured Video - HiJack User Profile
Security news and Events


Live Security Related Webcasts and Training for IBM i

March Events

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl

Training Workshop - Mar 13-17 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Concepts and CL Programming Workshop
with Dan Riehl

Training Workshop - Mar 20-24 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Expanded Security Workshop
with Dan Riehl

Training Workshop - Mar 27-30 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

April Events

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl

Training Workshop - Apr 24-28 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

May Events

Live Hands-On - IBM i (iSeries, AS/400) Security Audit
                               and Vulnerability Assessment Workshop
with Dan Riehl

Training Workshop - May 9-12 - Presented by The 400 School, Inc.
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend






Training from The 400 School


Training from The 400 School
Training from The 400 School

*SECOFR User Class Does Not Make A User Powerful

By Dan Riehl

When we create user accounts on the IBM i, we use the command CRTUSRPRF(Create User Profile). One of the attributes of a user profile is the User Class. The choices are *SECOFR, *SECADM, *SYSOPR, *PGMR or *USER. The Security Officer(*SECOFR) user class does not make the user powerful, just as the user class of System Operator(*SYSOPR) does not convey any power to the user to manage the operations of the system.

The user class assigned to a user does one major thing. It determines what menu options are displayed on IBM supplied menus. You can easily see the result of user class and menus on the MAIN menu. If a user runs the command GO MAIN, some menu options will be shown, others may not be shown, all based upon the user's assigned user class.

In another example, consider the IBM supplied menu named SECURITY. To access the menu the user runs the command GO SECURITY. If the user has a user class of *USER, only one menu option is shown, "Change your Password". On the other hand, if the user has a user class of *SECOFR, all options on the SECURITY menu are displayed. But, just because a menu option is shown, does not mean the user has the authority to exercise the menu option. Option 8 from the SECURITY menu runs the command, GO SECTOOLS. Unless the user has *ALLOBJ special authority, or is specifically granted a private authority to the SECTOOLS menu, selecting option 8 from the menu will result in an error message "Not Authorized to object SECTOOLS".

The user profile attribute that provides *ALLOBJ, and other special abilities is NOT the User Class, it is the attribute Special Authority(SPCAUT).

When we create user profiles we typically specify the command as follows:

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*USRCLS)

Here we create a powerful user by specifying that the user has all of the special authorities(SPCAUT) of the *SECOFR User Class(USRCLS). We could have just as easily specified the command as:

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*NONE)

In this example, the user would be able to see all of the menu options on the SECURITY menu, but would not be able to run most of them. This is because the user was not granted any special authorities.

I know that this is a somewhat goofy example. We would never create a user profile as a *SECOFR class with no special authorities, but I wanted to illustrate the point, that the User Class alone, does not provide any capabilities to the user, except the ability to see menu options on IBM supplied Menus.

When we consider the command again,

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*USRCLS)

The default value for the SPCAUT parameter is *USRCLS. So, unless we override the SPCAUT value *USRCLS, the user will have special authorities assigned according to the user's user class.

Assuming you are running QSECURITY level 30 or higher, here are the default special authorities assigned by user class.

  • *SECOFR – All special authorities
  • *SECADM - *SECADM special authority
  • *SYSOPR - *SAVSYS and *JOBCTL special authority
  • *PGMR – No special authorities
  • *USER – No special authorities

(Note: The User Class can also be specified in the CRITMSGUSR parameter of the CHGSRVA(Change Service Attributes) command, to cause users of a particular User Class to receive critical system break messages.)


Sponsored Links

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


IT Security and Compliance Group


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
Software Selection & Configuration
Security and Systems Programming



LIVE Training from The 400 School, Inc


Customized IBM i (iSeries, AS/400) Training -
    Presented Live at your offices


LIVE Online Hands-On Workshops

ILE RPG IV Programming
ILE COBOL Programming
Interactive Programming Workshops
System Operations Workshops
System Administration and Control
Security and Auditing Workshops
Control Language Programming
IBM i Concepts and Facilities
Query Workshop



Training from The 400 School
Security Training from The 400 School

Send your IBM i Security and Systems Management News and Events!           Send your Questions, Comments, Tips and Stories

Copyright 2014-2017 - SecureMyi.com, all rights reserved

SecureMyi.com | St Louis MO 63017