|
||
|
August 1, 2012 - Vol 2, Issue 14
|
||
|
||
|
Feature Article
Carsten's Security Code for IBM iWork with Command Security - WRKCMDSEC
By Carsten Flensburg The IBM i Operating System includes several hundred Control Language(CL) commands, many of which provide access to critical and sensitive system and security functions. IBM puts a lot of effort into restricting access to these commands by setting public authority adequately and, if necessary, requires additional user profile special authority in order to successfully execute sensitive commands. The command’s public or private authority could however for some reason be changed at a later point and so could the command’s Allow limited user attribute, which normally excludes end-users from running most CL commands. Add to this the number of user created commands and 3rd party vendor supplied commands that exist on most systems and you’re looking at quite a challenge in order to manage, monitor and audit access to the CL commands. Are the CL Commands Created by IBM?We often assume that all commands in the main operating system library QSYS were supplied to us by IBM. But, how can you be sure? User created commands possibly masquerading as legitimate IBM supplied commands may be implementing malware on your system. WRKCMDSEC can help you detect commands that were not created by IBM. And the Validity Checking Program(VCP)?Another area of Security/Audit concern is that a Validity Checking Program(VCP) may have been added to an IBM or Vendor supplied command. This method is used by some to enforce additional command rules or to add some additional logic to a CL command when it is used. A Validity Checking Program may also be used as an insertion point for potential malware. The WRKCMDSEC command can help you determine if a command has a Validity Checking Program. Commands for Limited UsersEach CL command(*CMD) definition contains an attribute named ALWLMTUSR(Allow Limited User) that determines if the command can be run at a command line by users that have been created as Limited Capabilities Users (i.e. LMTCPB(*YES)). IBM ships certain non-intrusive commands like DSPMSG(Display Message) and DSPJOBLOG(Display Job log) as ALWLMTUSR(*YES), thereby allowing Limited Capabilities users to run these commands at a command line. But, for protection, IBM ships almost all CL commands with the setting ALWLMTUSR(*NO), in which Limited Capabilities Users cannot run the commands at a command line. CL Commands like DLTLIB(Delete Library) and DLTF(Delete File) would be very dangerous in the hands of an end-user, but thankfully these are two of the commands that are shipped from IBM with the attribute ALWLMTUSR(*NO). For more information on the Misconceptions on User Limited Capabilities and Command Line access, see Dan Riehl's article in the July 10, 2012 issue of the SecureMyi Newsletter. |
|
In This Issue
Quick Links
Thank You! To Our Great Sponsors
Platinum Sponsor |
IBM i Security and Audit ResourcesIBM i Security Videos from SecureMyi.com SecureMyi Newsletter Home and ArchivesSearch Security Site for IBM i and i5/OS IBM i Security Reference - IBM i 6.1 IBM i Security Reference - IBM i 7.1 QAUDJRN Audit Types By AUDLVL 6.1 QAUDJRN Entry Type Record Layout 6.1 RedBook - Security Guide for IBM i 6.1 PCI SSC Data Security Standards 
|
|
IBM i Security News Bytes
SkyView Partners and Vision Solutions ink Product Integration Deal IBM i Security Calendar of Events
|
|
|
|
||
Featured YouTube Educational VideoIBM i Security - Common Misconceptions - Using Authorization Lists
Cannot Access YouTube from your office? Download the video in wmv format. 
|
||
|
||
Security Shorts -
By Dan Riehl 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? 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 DeviceTo 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:
Work with Objects
Type options, press Enter.
2=Edit authority 3=Copy 4=Delete 5=Display authority 7=Rename
8=Display description 13=Change description
Opt Object Type Library Attribute Text
_ QSAVALLUSR *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
_ QSAVCFG *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
_ QSAVIBM *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
_ QSAVLIBALL *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
_ QSAVSTG *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
_ QSAVSYS *DTAARA QSYS S/R DIRECTORY INFO FOR SAVE
8 QSAVUSRPRF *DTAARA QSYS S/R DIRECTORY INFO FOR REST
Place option 8(DSPOBJD) next to one of the data areas. In the example, we chose QSAVUSRPRF to see when we last saved our security data (including user profiles). Scroll through the resulting list to see the last Save Date, and Save Volume. If you simply want to examine one of the special SAVE data areas, you can use the command DSPOBJD. Here's an example that can be used to display the information on the last time we did a SAVSECDTA. DSPOBJD OBJ(QSAVUSRPRF) OBJTYPE(*DTAARA) While We're Here: Where IS Your SAVSYS?While we're here discussing saving the system and its different pieces, check to make sure you're routinely saving your user profiles and system configuration data. Also check to make sure you have a good SAVSYS backup media handy. You probably did a SAVSYS operation the last time you made a major change to the operating system, like an OS upgrade, or after applying a cumulative PTF package. If you don't have these backups available (SAVSYS, SAVSECDTA, SAVCFG), plan to do a the needed backups as soon as you can. You don't want to be stuck in a recovery scenario needing to go back to the original IBM distribution media. That would be a disaster on top of a disaster. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
|
Send your IBM i Security Related News and Events! Advertise in SecureMyi.com Security Newsletter Copyright 2012 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |
||