Network Attributes and IBM i Security

By Rich Loeber

Protecting your IBM i system from network users can be a daunting and challenging task.  This tip will give you a few basics about it and, hopefully, get you thinking about this issue.

In the good old days, the IBM i (then called AS/400) was a closed system with the only connections to other systems being dedicated telephone lines running IBM’s SNA protocol.  Control over access from remote users was pretty easy given this environment.  Then, along came networks and the Internet and this all changed.  Soon, every IBM i on the block came with an Ethernet card and TCP/IP enabled.  PCs running PC Support (aka: iSeries Access) replaced dumb terminals and emulation cards and the IBM i became a much more open system.

Now, many users with iSeries Access, can use upload and download utilities to access data on your system and even do entry and updates directly from these utilities.  In fact, many installations have embraced these technology changes and implemented solutions with these capabilities in mind.

But, with the opening up of the system, new security considerations come into play.  Consider the classic situation of a payroll clerk running your company’s payroll application from their trusty old green screen application.  Using secure menu design, you can implement a system that easily restricts this user’s access to the payroll files.  However, the IBM i security for these files will probably be *USE or *CHANGE to allow this user to process updates.  If this user were to experiment with the iSeries Access utilities for download, that level of permission would allow them to quickly and easily download the entire payroll file to their PC, make changes and then upload it back to your system.  That is most probably something that you never had in mind when security was first envisioned for this application.

So, as the security officer, what’s a person to do?

For starters, there are some simple network attribute settings that you can use to implement  controls.  You can view the network attribute settings on your system using the Display Network Attributes (DSPNETA) command and make changes using the Change Network Attributes (CHGNETA) command.  The three network attributes that I want to direct you to in this tip are:

  •     Job action (JOBACN)
  •     Client request access (PCSACC)
  •     DDM request access (DDMACC)

The Job action setting controls how the system will process remote requests to run jobs.  It has three settings which are *REJECT, *FILE and *SEARCH.  The default setting from the factory is *FILE.  If you are concerned about this, just change the default setting to *REJECT and you’re safe.  When it is set to *FILE, the incoming request is queued to a network file for the designated user and the job must then be reviewed and started by the user. *SEARCH sets up a search of the network job table, but that is a topic for an entire tip by itself.

The PCSACC parameter (which has its roots in PC/Support, the early version of Client Access/iSeries Access or whatever name it goes by today), controls how a PC will have access to objects on your system.  This has no bearing at all on the use of the workstation emulator, it is just for object access for the various iSeries Access functions like download, etc.

The possible values for PCSACC are:

  • *REJECT – all object requests are rejected regardless of what they are.
  • *OBJAUT – OS/400 object authority is checked and supported (the default setting).
  •  *REJFAC – the system checks for a registered exit program and passes authentication to the exit program for processing.
  •   program name – the registered program name is called to verify authentication.

If you just don’t want anyone to have object access, then change this parameter to the *REJECT setting.  In this day and age of platform integration, this will often not work for you, so you’ll have to explore the other options. On the surface, *OBJAUT sounds like a good choice, and for many shops it will work nicely.  However, this means that any user profile that is authorized to process and/or update files from an interactive application could also have full access from the iSeries Access side, which may not be ideal for maximum security.  Using a program name or a registered exit point is the best method, but implementing exit point processing is a daunting challenge and much too much for a simple tip article.  I’d recommend that rather than create your own exit programs, you consider purchasing one of the many good third party solutions that are available in today’s market including SafeNet/i from Kisco Information Systems.

The DDM Request Access setting decides how to handle security from remote systems requesting data using the Distributed Data Management functions.  These can be from PCs or from other DDM compatible platforms such as other IBM i systems or even mainframes.

The possible values for the DDMACC are similar to those for PCSACC with the exception that *REJFAC is not offered.  The same advice for this applies as for PCSACC.  The program name option provides the only “exit point” available to control DDM access.

If you have any specific questions about this topic, you can reach me at rich at kisco.com.  I’ll try to answer your questions.  All email messages will be answered.

Library List Security – Part 2

By Rich Loeber

As discussed in my last tip, controlling the library list and the list environment on your system is important to running a secure application.  Abusing the library list environment could easily cause a wrong (and possibly malicious) program to run or to access an incorrect data file.  In fact, in my work doing software support, I am often be presented with an inexplicable scenario only to find that wrong programs or data have been processed because a wrong object was referenced.

In the previous tip, I talked about the system library list component.  The library list environment also includes a user library list and two specific libraries, the current library and the production library.

The user library list is maintained as system value QUSRLIBL.  This is a list of libraries that will always be present for all users of your system at signon time.  The user library list can also be modified by the Job Description in effect at processing time.  This list should be kept to a minimum.  Most shops that I’ve seen have the QGPL and QTEMP libraries in this list which may be helpful.  The QTEMP library is often used by applications for work files and objects and the QGPL library is often used by system applications.  Shops that are very concerned about security issues will often leave these libraries off the list.  Just as with the system library list, you should take steps necessary to restrict users from making changes to the system values and job descriptions that can update how the user library list environment is set.

The only other candidates for inclusion in the user library list should be libraries that all users will need access to.  This might include a general use utility library or some other such library that all users need access to.  Unfortunately, because of ignorance of how library lists work, many shops load these up with lots of application library names just to get their applications to run and then they just leave the lists cluttered up leaving lots of room for problems down the road.  If you have specific application requirements, it is best to include them in the Job Description and not in user library list system value.

Once you have settled on your system library list and user library list, there are still two more ways to add library control to your jobs.  These are the Product Library and the Current Library.  When the IBM i OS searches for objects, it searches the system library list first, then the product library, current library and finally the user library list.

The Product Library and Current Library are controlled by the IBM i command object or by the menu from which they are run.  When you create your applications, you should take care to make sure that the users who have access to create command objects and menu objects are limited to trusted users.  There are a small number of IBM i commands that can be used to create and modify *CMD objects; make certain that access to these IBM i commands is limited.  The same is true for creating and maintaining menus on your system.

When you create commands and/or menus, you should take some time to consider how you want the Product and Current libraries set up.  It is an easy way to make sure that your application library is available for processing without cluttering up your user library list with unnecessary entries that apply to everyone.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

 

Library List Security – Part 1

By Rich Loeber

The library list on your IBM i controls how the IBM i OS searches for objects when no specific library has been coded.  Changes to the library list could easily be used to execute a rogue program or cause your processing to run against an incorrect set of data.  Controlling how your library lists are set up on your system can mean the difference between secure and insecure processing.

The library list has four main components.  These are the system library list, the current library, the product library and the user library list.  When an object access is requested by a program and the request is not library specific, the IBM i OS will search the system for the object requested in this sequence.  The first object found with the right name and object type will be used.  This could be to satisfy a program-to-program call, a request for a data file object or any other object access request.

The best and most secure solution is to always code your object requests as library specific.  For testing and other reasons, using the search capabilities of the library list can be a very handy solution.  But, as you can see, it poses security risks.

The easiest illustration of a security risk is interposing an alternate (and malicious) program so that it gets called in place of the actual program object you really want to call.  The alternate program could, for example, do the same processing but store credit card information in a private file for later access and abuse.  Your user has no knowledge that anything unusual is going on but information from their processing is being hijacked.

To limit the possibilities it is important that you specifically limit the number of libraries that appear in your library lists.  You must also control who is allowed to make changes and you must have a clear business case made to add new libraries to either the system or user library list.

The system library list is maintained as a system value and should be kept to a minimum.  The entry for the IBM i library, QSYS, is a requirement for IBM i OS functions to run properly.  In many shops, the QSYS2 library is also needed as it contains objects required for many system APIs.  If your code, or a software vendor’s code, uses any IBM i  OS APIs, you’ll need this library in the system list.  From the factory, you will normally also find the QHLPSYS and QUSRSYS libraries.  The QHLPSYS library contains the help text panel groups for the IBM i OS and should be left in the list, but you should make sure that public only has *USE access to objects in the library.  Leaving QUSRSYS in the list is another matter.  It should also have a public setting of *USE, but you should examine other special authorities set up for the library to make sure that the ability to create and add objects to this library is severely limited.  If you find any other libraries in the system library list, you must check their availability to the public and make sure they are restricted.  You should also validate the business reason for having non-IBM libraries in the system library list on your system.

In a future tip, I’ll take a look at controlling the user library list and the current and production library entries.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Securing the Save/Restore Function

By Rich Loeber

On today’s open IBM i system, the save/restore function can be used to transfer critical files and programs between systems.  With this comes the specter of data and program theft, so it is important to make sure that this avenue of data transfer is secure.

Most IBM i installations run a scheduled save of their system to transfer files, programs and other objects to tape or other media for safe keeping.  Saving the system on a scheduled basis is just good practice since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system.  Since introduction, IBM has hounded its customers (and rightly so) to do a regular save on your system.  Once objects have been saved, you can also use IBM i/OS functions to restore objects from the saved media.  This can be part of either a full system restore or to recover objects that get damaged or corrupted in any number of ways.

The problem, from a security viewpoint, is that once data and programs have been saved to offline media, they can then be transported to another system and restored.  Mission critical information must be guarded to prevent theft from occurring.  Physical security on the media is critical for this, but I want to talk more about securing the save/restore function on your system.

Today, with an open TCP/IP world in which we work, you can save a critical file to a save file and then FTP or SNDNETF it to any system in the world.  IBM i software developers regularly use the FTP save file to transfer program updates onto customer systems.  With the ease of data transfer that this provides, restricting the use of the save/restore functions on your system is more critical than ever.

The first line of defense for this is found in the user profile.  Before someone can use the Save/Restore commands in the IBM i/OS, they must have *SAVSYS special authority in their user profile.  If you have not done so, I recommend that you review your user profile base to find out which user profiles have *SAVSYS configured and make sure that they have a real business reason for it.  Certainly, your operator(s) will need this authority, as will anyone who runs the scheduled backup or restore functions.  But, I would be hard pressed to think of any other users in a regular environment (including programmers) who really need to have this ability.  I know some programmers are going to howl at this, but they will have to be able to make their business case before you give them these keys to the kingdom, so to speak.  You can always look at granting them this authority on an as needed basis, revoking it once the task to be done has been completed.  Some shops even keep a special user profile around for this use.  When needed, they activate it temporarily and the deactivate it with full documentation kept on how it was used.

The next place to look for restricting Save/Restore use on your system is the IBM i/OS authority setup for the the RSTxxx and SAVxxx commands.  The RSTxxx commands are shipped from IBM with public *EXCLUDE, but the SAVxxx commands have a public setting of *USE.  You might want to consider setting up an authorization list for these commands and then listing the users that you want to be able to use them in the list.  Once the list is built, associate it to the commands and then change the SAVxxx commands to be public *EXCLUDE.  (You can also do this with direct authority, but having the authorization list will make IBM i/OS upgrades easier to implement.)

There are several system values that you should take a look at too.  The QALWOBJRST value lets you restrict certain objects at restore time.  These include system-state programs, programs that adopt authority and objects with validation errors.  QVFYOBJRST controls restoring signed objects.  QFRCCVNRST wil force object recreation on certain objects at restore time.  Lastly, you can specify *SAVRST in the QAUDLVL command to audit save restore operations on your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Standardize Security Across Multiple Systems

By Rich Loeber

Nothing supports the popularity of the IBM i as much as the number of customers with multiple systems installed.  These can be either multiple partitions on a single box or separate boxes.  For security officers, this can easily mean a lot of extra work keeping each system setup and configured for company security policies.

While this can be a complex task, IBM has provided an little known capability in the IBM i OS for quite a while now that can help you to enforce standard security configuration setup rules across separate systems.  This is through the use of the CFGSYSSEC (Configure System Security) command.  This command, which has no parameters, calls a CL program named QSECCFGS in the QSYS library.  This program sets the security related system values to standard settings recommended by IBM.

The good news for the security officer with multiple systems to control is that this CL program can be changed to meet your unique setup requirements.  The base program as shipped with IBM i can be retrieved and then modified for your unique needs (not unlike the way the system startup program QSTRUPPGM works).

To retrieve the CL program, just run the following command on your system:

RTVCLSRC PGM(QSYS/QSECCFGS) SRCFILE(mylib/QCLSRC)

This will place a source member in your QCLSRC source physical file named QSECCFGS.  To be on the safe side, you should probably rename this and, when you recompile it, place the new compiled program into QUSRSYS.  Once this is done, just change the IBM i CFGSYSSEC command to run the your modified program from QUSRSYS with the following command:

CHGCMD CMD(QSYS/CFGSYSSEC) PGM(QUSRSYS/myseccfgs)

When you review the CL program source that has been retrieved, there is some housekeeping that takes place early in the program.  You can review the settings imposed by the program after the housekeeping to see how IBM recommends your security setup and make changes that will implement standard security settings for your own requirements.

To implement the standard security setup across your multiple system environment, simply install your custom setup program on each system in your network and modify the CFGSYSSEC command on each system to call your modified program in place of the IBM default program.  To guard against possible changes being made to the setup, you can even add this to your automatic schedule to run on a weekly or even daily basis to keep these setting enforced.

The retrieve CL program is a little tough to read, but perseverance will prevail.  If you need help with it, let me know what you need specifically and I’ll see if I can help.  If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Securing Your IBM i Production Files

By Rich Loeber

You will find a lot written about advanced topics in security for your IBM i, but if you don’t have basic object level security in place, all the advanced topics in the world may be a complete waste of time.  This tip will explore the basics of how to best secure native objects, including your data files, on your IBM i.

Before you attempt to secure your system at the object level, you have to check a system setting.  Using the Display System Value (DSPSYSVAL) command, check the following system value on your system:

QSECURITY

If it is set to a level lower than 30, then you cannot implement object level security on your system.  In this case, the first thing you need to do is increase the security level setting for your system.  If this is your situation, I recommend moving to a minimum level of 40.  If you are at level 30, you should also consider a move to level 40 as it will help with an extra level of protection for the integrity of your system.

When you have finished this task, there are two more tasks that you need to check before moving on to the meat of object security.  If a lot of users on your system have special authority on their user profile set to include the all object (*ALLOBJ) authority, then these need to also be changed.  On a secure system, only a limited number of profiles should have all object authority to your system.  Typically, this is limited to the system security profile (QSECOFR) and any other security officers that are defined to your system.  All such profiles should have a documented business reason for having this special privilege assigned.  You can identify the profiles that are set this way by running the Display User Profile (DSPUSRPRF) command for *BASIC information to an *OUTFILE.  Scan the database file created for the *ALLOBJ string; this will show you how many profiles have this setting and which profiles they are.

Lastly, before you implement access rules on your system, you will need to determine an access policy.  This policy will define how you grant or restrict access.  The policy should be defined along application lines and have the support and approval of your organization’s management.

Now that we have these basics out of the way, it is time to implement security at the object level.  If you are really doing this for the first time, you have a choice of implementing security with private authorities on each object or by using an authorization list.  I recommend the latter.  When you have to make changes to security settings on the fly, having your security set in authorization lists lets you make changes at any time.  If your security access is stored with each object, then the object has to be available (ie: not in use) to make changes to it.

Security is specified at the object level and at the library level.  You also define public authority for general access controls and then you can grant specific greater access at the individual user profile or group profile level.  Public authority is best enforced at the library level, but it can vary also at the object level.  If, for example, you do not want just anyone accessing objects in a library, set the public authority for the library to exclude (*EXCLUDE).  As a first step, I recommend that you identify all user libraries on your system and get the public and private authorities set up for them.  Implementing security at the library level will take you a long way to having your system properly locked down.

Once your libraries have been configured for access rules, you can then go on to secure individual objects in the libraries.  You can customize access rules using system default settings as follows:

  • *EXCLUDE – the object cannot be used by anyone
  • *USE – the object can be read by anyone but cannot be changed
  • *CHANGE – the object can be read and updated by anyone, but not managed
  • *ALL – the object can be read, updated and managed by anyone
  • *AUTL – the object access definition of the authorization list is used

If you have very customized requirements, you can also carry this down to a more granular level by using specific settings available on the system.

This tip just scratches the surface.  If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Recovering Your IBM i Security Configuration

By Rich Loeber

I once worked, many years ago, with a company that had a disaster recovery plan in place and actually tested it once or twice.  The plan called for us to arrive at the recovery center and then, almost immediately, turn security on the recovery box OFF to make things easier during the recovery.  There was no corresponding step later in the recovery to reactivate security, so for the duration of any disaster, the backup system was exposed to security violations.  Now, to give them some credit, this was in the days before networks and the Internet, so their exposure was probably pretty limited.  In today’s world, however, when you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.

To understand how best to do this, you first have to understand what the different security objects and settings are on your system along with how and where they are saved.

System values make up a large component of your security policy implementation.  The system values are all stored in the QSYS library.  They are saved when you run a SAVSYS, the “Entire system” or “System data only” options on the SAVE menu or when you save your entire system using the “Run Backup” (RUNBCKUP) command.  When you get to your recovery site and restore your OS from one of these, your system values will get restored in the process.  Keep in mind that these settings will be restored the way they existed when your SAVSYS was created.

User profiles, including group profiles, are also stored in the QSYS library and are saved when you save the OS.  Since these can change more frequently than the OS, you can also save them using the “Save Security Data” (SAVSECDTA) command.  When you restore your OS, you will get the profiles as they existed when that backup was taken.  If you have saved the the profiles separately, make sure that you restore them again as soon as the OS has been restored so that you get the most current set of passwords available.

Job Descriptions can also have an important affect on how jobs run and how security is enforced on your system.  IBM generally recommends that you create your job descriptions in the QGPL library where they keep theirs, but a job description can be created and stored in any library on your system, especially if you are running any third party software.  When you backup a library using the “Save Library” (SAVLIB) or “Save Object” (SAVOBJ) command, the job descriptions will travel along and will be restored when those libraries are restored.

Finally we get to your resource security setup.  This, by its very nature, is a bit more complicated than the above items, but certainly manageable.  The good news is that a lot of the resource security information is stored directly with the object.  This includes its public authority setting, its object audit setting, the profile of the object’s owner, the primary group and the link, if any, to an authorization list.  So, when you save the objects in your library, you will also be saving these security items.  The two resource security pieces that are not included are the authorization list itself and the private authority configuration.

All authorization lists are stored in the QSYS library.  They are saved when you save your OS and they are also saved when you run the SAVSECDTA command.  As with the user profiles already mentioned, these can change more dynamically than the OS, so having a separate SAVSECDTA is a good idea.  After you restore your OS, make sure to include a restore of your security data to get the most recent versions of your authorization lists.

Private authorities are also stored in the QSYS library and are included as a part of the user profile data.  So, when you save the most recent profile information, you are also saving the most recent private authorities.  When you recover your profiles, you are also recovering the private authorities.  But …. there is a catch.  After your system has been recovered, including the most recent profiles and ALL application libraries, you will also have to run the “Restore Authority” (RSTAUT) command for *ALL users.  This will restore the private authorities to objects and to authorization lists.  This is a step that can be overlooked with dire consequences as far as your security implementation is concerned.

There is more information about all of this in IBM’s Security Manual for the OS.  I recommend you review the manual for more details.

If you have any questions about anything included in this tip, you can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.

Setting and Locking Your System Values

By Rich Loeber

When you implement your company’s security policy on your IBM i, often the first thing you do is review your system values.  System values define global, system-wide settings on your IBM i platform.  Many of these system values pertain to how you want to implement system security.  This tip will review how to look at these settings and then, how to lock them in place so that they cannot be changed.

So many of these system values are security related that the OS designers provided an easy way for you to review and work with the security settings.  This is by using the “Work with System Values” command (WRKSYSVAL) with the “System value” (SYSVAL) parameter set to the special value of *SEC.

WRKSYSVAL SYSVAL(*SEC)

Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values for you.  Or, you can just run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review.  A similar review function is available from IBM i Access, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2.  The list of system values displayed shows the name of the value and a text description.  Often, this is not enough information for you to determine exactly what you’re looking at.  When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP (or F1) key.  The help text that comes with this command is quite comprehensive and very helpful.

Changing any of your security system values should not be done on a whim.  Planning and preparation are the watchwords for this process.  It is all too easy to shoot yourself in the foot by making a security change on the fly and then losing, for example, the ability to log into your system.  All security changes should be researched in advance to determine the exact impact on your system.  If you’re not sure, do the work to find out rather than just trying it out without knowing the impact.

Once you have your security system values set along with the other system value (and there are loads of them), it is a good idea to lock them in place.  On too many systems, there are just too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.  By locking the system values, this will prevent casual changes to the system values and thereby preserve the security policies that you’ve designed and implemented.

To lock your system values in place, you can use the System Service Tools.  To lock the settings, start up the System Service Tools from a display session using the Start System Service Tools (STRSST) command.  You will need to supply your service tools user ID and password to complete the start of the tools.  Once completed, choose option #7 from the menu (Work with system security).  Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by first going back into the System Service Tools and unlocking them from the same screen where you locked them.  The unlock option is done by entering option 1.  These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST).  Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about anything included in this tip, you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Custom Password Validation Program

By Rich Loeber

While the IBM i operating system has very good features for controlling password selection, sometimes your password policy just can’t be enforced without additional checking.  You may have a list of reserved words that you specifically do not want anyone using as a password.  Or, you may have some very stringent requirements that are just not covered by the system values that control password assignment in IBM’s i/OS.

When this happens, the only solution is to code your own password validation routine.  This can be coded in any high level language.  The operating system passes four parameters to your program, one of which is a single character return code.  Once you’ve had a chance to complete your validation testing, just set the return code to the value you want and exit your program.  If you set the return code to zero (‘0′), then the operating system will assume that your password is acceptable and the password is updated.  The parameters passed are, in order, the new password, the old password, the return code and the user profile for a total of 31 characters.

To tell the operating system that you now have your own password validation program in place, you need to update the system value “Password validation program” (QPWDVLDPGM).  It is shipped from the factory set to *NONE.  To use your own program, just change this value to your program name and library name.  It is recommended that you store this program object in the QSYS library so that it is always saved when you backup your operating system.

Once your program is in place, test it to make sure that it is getting called.  Use the CHGPWD command and intentionally use a password that will cause your routine to fail.  You will see that a message is displayed indicating that the password rules are not met along with the value of the return code that you used.  By varying the return code for different situations, you can give your support team a heads up as to the exact reason for the password failure.  While you’re completing your testing, make sure that you process a valid password change to make sure that normal changes are not adversely affected by your new validation routine.

Registering your specific program with the QPWDVLDPGM system value will only work if you are using default 10 character user profiles and passwords.  If you are using the newer long passwords, then you will have to write an exit program and register it using the exit point registration facility.  If you take this path, then the QPWDVLDPGM system value must get set to the special setting of *REGFAC and the exit program is registered by the WRKREGINF command.  Beware, however, that the parameters for the exit point are very different.  There is a good example of the format needed for this exit program in the IBM security guide.

One thing to watch out for in this process is that the passwords, both old and new, are passed to your program without any encryption.  So, do not store any values received in a database file as this will compromise security on your system.  In fact, you should periodically check this system value to make sure that it does not change and that the program processing additional validation rules remains unchanged.  This could easily be abused on your system, so lock up the program object.

If you’d be interested in receiving a sample program for default 10 character password validation, I’ve written one just to test how this works on my system.  Let me know and I’ll send the program shell to you.  If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Lock Up Your System Values

By Rich Loeber

When you implement your company’s security policy on your IBM i, often the first thing you do is review your system values.  System values define global, system-wide settings on your IBM i platform.  Many of these system values pertain to how you want to implement system security.  This tip will review how to look at these settings and then, how to lock them in place so that they cannot be changed.

So many of these system values are security related that the OS designers provided an easy way for you to review and work with the security settings.  This is by using the “Work with System Values” command (WRKSYSVAL) with the “System value” (SYSVAL) parameter set to the special value of *SEC.  Like this:

WRKSYSVAL SYSVAL(*SEC)

Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values for you.  Or, you can just run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review.  A similar review function is available from iSeries Navigator, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2.  The list of system values displayed shows the name of the value and a text description.  Often, this is not enough information for you to determine exactly what you’re looking at.  When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP (or F1) key.  The help text that comes with this command is quite comprehensive and very helpful.

Changing any of your security system values should not be done on a whim.  Planning and preparation are the watchwords for this process.  It is all too easy to shoot yourself in the foot by making a security change in the fly and then losing, for example, the ability to log into your system.  All security changes should be researched in advance to determine the exact impact on your system.  If you’re not sure, do the work to find out rather than just trying it out without knowing the impact.

Once you have your security system values set along with the other system values (and there are loads of them), it is a good idea to lock them in place.  On too many systems, there are just too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.  By locking the system values, this will prevent casual changes to the system values and thereby preserve the security policies that you’ve designed and implemented.

To lock your security system values in place, you can use the System Service Tools.  To lock the settings, start up the System Service Tools from a display session using the Start System Service Tools (STRSST) command.  You will need to supply your service tools user ID and password to complete the start of the tools.  Once started, choose option #7 from the menu (Work with system security).  Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by first going back into the System Service Tools and unlocking them from the same screen where you locked them.  The unlock option is done by entering option 1.  These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST).  Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.