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.

More About Controlling Access to Spool Files

By Rich Loeber

In my last tip, I talked about controlling access to spool files through implementation of IBM i OS object authority at the output queue level.  In this tip, I’ll be taking a look at three additional parameters that are associated with IBM i output queues that can extend the level of control you have over sensitive reports on your system.

The three parameters in question are:

  • Display any file (DSPAUT)
  • Operator controlled (OPRCTL)
  • Authority to check (AUTCHK)

These three work to give you more control over access to spool files beyond what is available through object level controls on the output queue.

One thing to keep in mind is the proliferation of user profiles with special authority of *SPLCTL.  This is the equivalent of the evil *ALLOBJ authority, but as applied to spool files.  You should restrict granting of *SPLCTL to only those user profiles where it is absolutely required.  As you read on in this tip, remember that if a user profile has *SPLCTL authority, then they can cut through these restrictions as they will not apply (with one exception as noted).

“Display any file” (DSPDTA) is intended to protect the contents of a spool file by setting authority requirements.  There are three values available, *YES, *NO and *OWNER.  Each of these provides progressively increased levels of authority requirements to view, copy or send spool files in the output queue. *YES allows anyone with READ authority to work with files in the output queue. *NO restricts that to the owner, those with *CHANGE authority and those with *SPLCTL special authority. *OWNER further limits this to just the owner profile and any profile with *SPLCTL authority.

“Operator controlled” (OPRCTL) controls whether or not a user with *SPLCTL special authority is allowed open access to this output queue.  The default value on the Create Output Queue (CRTOUTQ) command in the IBM i OS is *YES which is why most output queues are open season for users with *SPLCTL authority.  Changing this value to *NO will force normal object authority rules to control access to the output queue.  If you have an output queue with sensitive information stored and you are concerned about *SPLCTL users gaining access, this is the key parameter value that can save the day for you.

“Authority to check” (AUTCHK) controls how users with *CHANGE authority to the output queue will be given access to change, delete or copy spool files in the queue.  When this is set to *OWNER, only the owner profile of the spool file can change or delete spool files.  Using the value of  *DTAAUT changes this control so that it looks at object level controls for the output queue.

Using these parameters intelligently can give you much added control over how users access (or don’t access) spool files on your system.  Using them in combination can be a little confusing, but if you look in your IBM i OS Security Reference manual under the Work Management section on Securing Spool Files, you will find a full page chart for this set of parameters and how they can be used in combination to achieve your specific objectives.

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.

Controlling Access to Spool Files

By Rich Loeber

A nice feature of the IBM i OS lets you view the contents of spool files before they have been printed or distributed electronically.  For a lot of users, this saves time and paper and provides a lot of convenience.  But, not all spool files should be able to be viewed by every user.  This tip will take a look at some ways to control who is allowed to see which spool files on your system.

Print spool files are special objects on your system that are stored in the QSPL library.  You cannot control access at the spool file level on your IBM i system.  Access to the spool files must be controlled through the output queue that is associated with each spool file.

If you have sensitive or confidential information that is being stored in a print spool file, the best way to secure it is to create a special output queue (or set of output queues) that are secure to a known set of users.  To direct the spool file into the right output queue can sometimes be tricky.  IBM i generally checks the following sequence of things to direct the output from a job:

  • the printer file
  • job attributes
  • user profile
  • workstation device description
  • system print device (QPRTDEV) system value

To direct your sensitive output to the right output queue, your best bet is to specify it in the printer file being used by your application.

Output queues can be created in any library on your system.  Output queues for printer devices generally get created in the QUSRSYS library, but you are not limited by that.  To improve security, create your secure output queue in a separate library that has limited access at the library level.

Once the output queue has been created, you can then limit access to it using the Grant Object Authority (GRTOBJAUT) command and Edit Object Authority (EDTOBJAUT) command.  To specifically limit general access to the output queue, the PUBLIC setting for the *OUTQ object must be set to *EXCLUDE.  Then, in the individual user authorities, you can provide for access for specific user profiles or (better yet) group profiles.

You should also note that user profiles with the special authority of *SPLCTL will be able to view and work with spool files regardless of their access control limitations to your secure output queue.  This is a form of all object authority, but only applied to spool files.  You should limit the number of profiles on your system that have the *SPLCTL authority in order to maintain the security of your sensitive output queues.

There is also a special setting on the output queue called the “Display Data” (DSPDTA) parameter that can be used to control viewing spool files.  When you set this to *NO, then only the spool file owner profile can view the contents of the spool files in the output queue.  You can check the value of this parameter using the Work with Output Queue Description (WRKOUTQD) command to see how it is set up for your secure output queue.

There are some other intricacies that are covered in the IBM i security manual.

If you have any 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.

Command Line Security – Part 2

By Rich Loeber

Last time, in part one of this two part series, we talked about limiting access to the use of the IBM i OS command line.  For some installations, however, you may have some good business reasons for providing command line access.  In part two, we’ll take a look at how you can restrict access to specific commands in IBM i OS.

Every command in the OS exists as an object on the system with object type *CMD.  The best way to control access to use of the commands is through IBM i  object security.  Command objects can exist in any library.  The OS commands are generally all found in the QSYS library.  Command objects can be part of the IBM i OS and they can also be part of application programs installed on your system either from your own homegrown applications or from software providers other than IBM.

Most OS commands are shipped from IBM with the public authority set to *USE.  This means that anyone on your system can run any command.  To restrict a command, change the public authority to *EXCLUDE.  When you make this change, then only users with all object authority (generally a no-no in a security conscious installation) will be able to run the command.  Then, using either an authorization list or by granting specific user profile access, you can control who can run the command.

For example, suppose that you decide that you want to restrict the use of the Work with Output Queue (WRKOUTQ) command.  This is one of the commands that is shipped with public authority of *USE.  To change the public authority to *EXCLUDE, run the following Grant Object Authority (GRTOBJAUT) command:

GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*EXCLUDE)

Now, if you have a set of users that you specifically want to allow access to the command, you can grant them individual access using the following command format:

GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(MYPROFILE) AUT(*USE)

The USER parameter can point to a specific user profile or to a group profile.  If you have implemented group profile security, this is the better way to approach this issue.

When setting up command security using this method, you can use wildcard characters for the object name in the Grant Object Authority command.  Using this method, you can update the public and private authority for many related commands all at the same time.  The IBM i OS Security Guide suggests controlling all of the commands that change device configurations as an example.  Using that example, the following command would do the trick:

GRTOBJAUT OBJ(QSYS/CHGDEV*) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*EXCLUDE)

Your best approach is still to limit user’s ability to run commands directly from the command line.  But, if you absolutely have to allow it, then make sure that an inquisitive users doesn’t accidentally (or purposefully) run a command that you don’t want them running.

If you have any 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.

 

Command Line Security – Part 1

By Rich Loeber

When a user on your IBM i system signs on to a terminal session, they will be presented with a command line.  Given enough security permissions, a user can do just about anything from that command line, if they are inquisitive enough.  This article will discuss several options for controlling what a user can, and more importantly what they cannot do, when they are presented with a command line.

Controlling use of the command line begins with the way your user profile is set up.  Specifically, the option to “Limit capabilities” (LMTCPB).  This will define what, if any, controls the system will impose over use of the command line.  Unfortunately, many systems just use the default “*NO” setting for this value and that leaves the command line wide open for use (and abuse).

There are three possibilities for the LMTCPB parameter in the user profile:

 

  • *NO – means there are NO limits on the user of the command line.  In addition to processing commands from the command line, the user can also make certain changes to their user profile that you might not want them making.
  • *PARTIAL – this is a little better than the *NO option and it limits certain actions that the user can take at signon and from the command line, but they can still run commands.
  • *YES – this is the best option for most of your users.  The user cannot specify different parameters for menu and library from the signon screen and they cannot change the setup for their user profile.  The user also is not permitted to run any IBM i OS commands from the command line.

“But,” your user says, “I need to be able to check my output reports using the WRKSPLF or WRKOUTQ command!”  This is a common issue in some shops, but setting the LMTCPB for the user profile to *NO or *PARTIAL is not the answer.  If a user needs to use a very limited set of IBM i OS commands, the best way to solve that issue is by creating menu options for them to use.  They can continue to run the commands from the menu option with no problem.

One thing to also be careful about is the starting menu that you present to your user.  Again, the default that comes from IBM is to give your users access to the IBM i OS “MAIN” menu in QSYS.  This menu can easily lead an inquisitive user to options and capabilities that you probably don’t want them seeing or using.  If you follow the menu options, you can easily get into areas where a user just does not belong.  So, make sure that you specify a starting menu that strictly limits where the user can go.  Spend some time testing your menu structures to make sure that they do not lead a user to capabilities that they should not be granted.

Next time around, in Part 2 of this article, I’ll take a look at how to effectively limit how users use of commands in the IBM i OS when you absolutely have to let users have access to the command line.

If you have any 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.

Changing Your Signon Screen – A Good Idea

By Rich Loeber

The classic IBM i signon screen has been around since forever.  I first saw it in 1988 when I took delivery of my first AS/400 system, a lowly B10.  In the old days, the appearance of the signon screen made no difference since the system was a closed system.  With the advent of networks, this situation changed dramatically.

Today, all IBM i systems are networked and users connect via that network connection.  The signon screen is projected to terminal emulation software throughout the network and even over the Internet for users that are accessing the system from remote locations.  Because of this, the signon screen standard context can be easily recognized by people with malicious intent and scrubbed (sniffed) for user id and password information.

Granted, for many users, this information is encrypted.  But, with the proliferation of open access protocols, there are many emulators that do not encrypt this information.  Examples of this are hand-held devices (tablets and phones) and the Telnet capabilities of Windows platforms.  For my own system, I access it when traveling via my Android smartphone and no encryption is taking place.

A second reason is that the classic signon screen presents a field that could provide a saavy user with a way to bypass your intended signon process sequence.  Next time you sign on using this screen, just type QCMD in the “Program/procedure” field and you will get a demonstration of what I mean.

For these reasons, it is probably a good idea to design your own signon screen and that you change the standard terminology used to identify the User and Password fields and disallowing the “Program/procedure” field.  Making the change is fairly easy, but you need to be careful and you need to test your new screen before rolling it out for general use.

IBM ships the source code for the standard signon screen in a source physical file named QAWTSSRC in library QSYS.  In this source file, you will find two sets of code for the two possible standard screens on your system, QDSIGNON and QDSIGNON2.  The first is used when you have standard 10 character passwords configured and the latter is used when you have set your system up for long (128 character) passwords/pass-phrases.  I recommend that you move the source that you want to use into a separate library, thereby preserving the original source in case you get in trouble.

Once you have the source moved into your own library, you can then use Screen Design Aid (SDA, PDM option #17) to make your changes.  When working on your screen, make sure that you observe the following:

  • Do not delete any of the input capable fields that are on the signon screen.
  • Do not change the sequence of any of the input capable fields.  You can move them around on the screen, but keep their sequence in tact.
  • Do not change the characteristics, especially field lengths, for any of the input capable fields.
  • Do not attempt to use any DDS HELP capabilities for the signon screen.

Since one objective is to change the reference to “User” and “Password”, pick out suitable replacements for these and make sure to change the text for those areas.  I would suggest alternatives here, but that could just start a new default standard which would defeat the objective of this tip.

The second objective can be accomplished by removing the text field for the “Program/procedure” field and then changing the PROGRAM field so that it is non-display.  This will keep the integrity of the signon screen while preventing this field from being used.

When you are all done, compile the screen into a library other than QSYS.  To implement the new screen, you will need to update the subsystem description.  You can use the Change Subsystem Description (CHGSBSD) command; press the F10 key to display all parameters and you’ll find one that controls the signon screen in use.  Test your new screen in the QPGMR subsystem to make sure it works as desired before rolling it out to QINTER and other production subsystems.  I strongly recommend that you NOT use an alternate signon screen for your system console which is typically associated with the QCTL subsystem.

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.

IBM i SMTP Relay Controls

By Rich Loeber

Many IBM i shops keep the SMTP server active on their system to support host-based applications that format and send e-mail messages directly from their IBM i system.  With the SMTP server active, you could leave your system open to spammers who could take over the SMTP server to relay their spam messages.  This tip describes how to control SMTP relay on your system.  You can check to see if SMTP is active on your system by running the following command:

WRKACTJOB SBS(QSYSWRK) JOB(QTSM*)

If there are any tasks displayed, then the SMTP server is active on your system.

Controlling SMTP mail relay involves two processes.  First, you have to set the ALWRLY parameter in the SMTP Attributes on your SMTP server.  This is updated using the CHGSMTPA (Change SMTP Attributes) command.  Keep in mind that your user profile must have the *IOSYSCFG special authority to be able to use the CHGSMTPA command.

If you just want to deny all mail relays, set this value to *NONE and you’re all set, you can stop reading now and move on with your life.  However, if you are sending mail from your IBM i using the SNDDST command, SNDSMTPEMM command or other program-controlled methods, you cannot leave this setting at *NONE as it will block mail being sent from your system.  Simply changing this setting to *ALL is not a good idea either as this will allow anyone to relay mail through your system.  The best choices are one of the following:

•    *LIST – only IP addresses that match an *ACCEPT SMTP list entry will be allowed or denied
•    *NEAR – only IP addresses that match a *NEAR SMTP list entry will be allowed
•    *BOTH – the system will look at both the *LIST and *NEAR entries

Once you have this part configured and have specified one of the three recommended settings, you will then have to update the SMTP list to indicate who can relay mail.  This is done using the ADDMSTPLE (Add SMTP List Entry) command.  There are a lot of options for this, but as a simple example let’s set up an entry that will permit mail to be relayed from your IBM i.  If you system has an IP address of 10.100.2.1, then you would add a relay accept transaction that looks like the following:

ADDSMTPLE TYPE(*ACCEPT) INTNETADR(’10.100.1.2′)
SUBNETMASK(’255.255.255.255′)

This entry will accept all SMTP mail that is sent from the specific IP address indicated in the INTNETADR parameter.  The subnet mask used here is coded so that only the specific IP address will be processed.  You can also use this command to post a *REJECT or *NEAR entry to the SMTP list to indicate specific IP addresses to be rejected or to define a system to be considered as a *NEAR system.  Varying the subnet mask can let you define ranges of IP addresses and if you need help on how to code these entries, feel free to contact me.  Once entries have been added to the SMTP list, you can delete them using the RMVSMTPLE (Remove SMTP List Entry) command.  It would be nice if IBM provided a WRKSMTPLE command too, but the test system I work on has no sign of this feature.

If you have been using SMTP list entries for a while, you may need to know what entries are already established on your system but IBM i provides no support for a review function.  You can, however, review what is already set up by examining the various members in the file anmed QATMADRLST in library QUSRSYS.  Each member, which you will find appropriately named, contains the list entries for that type.  I simple query report can list the entries and you can remove unwanted entries as needed.

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.

Security and Performance Issues

By Rich Loeber

Normally, you would not think of system performance in terms of a security issue.  But, if someone with the right know-how is abusing privileges on your system, then it becomes a security issue.  This tip will help you to identify some performance issues that fall into this category.

A performance issue that has security implications can happen when someone with the right special authorities on their user profile abuses those and consumes excessive system resource in their own interest.  This can happen, for example, when programmers boost the execution priority for their jobs at the expense of interactive processing.  It can also happen when someone runs a batch job interactively, thereby bringing other interactive users to a crawl.  When this occurs, it is clearly a security issue as the user or users in question are abusing their assigned privileges.

Controlling the execution priority of a job is a function of the Job Priority.  This is set by the Job Description that is used for the job.  It can also be changed on the fly by someone with *JOBCTL special authority associated with their user profile.  If you see this happening, you might want to just remove *JOBCTL from their user profile.  Restricting access to the CHGJOB command can also help.  The CHGJOB command is shipped from IBM with public access set to *USE, so any user profile can use the command.  Restricting access could affect applications running on your system, so you should consider this change carefully.

To restrict access to the CHGJOB command, run the following command on your system:

GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(*PUBLIC)
AUT(*EXCLUDE)

This will change the command so that only authorized user profiles can use it.  To add a user profile to those allowed access to this command, use the following command:

GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(MYUSRPRF)
AUT(*USE)

This will allow the profile MYUSRPRF to use this command while excluding all others.  Of course, any user profile with All Object Authority (*ALLOBJ) will still have access, so that wrinkle also has to be allowed for.

Limiting access to command objects on your system is a good way to control who can do what.  Another command that you should consider for similar treatment is the Change Shared Storage Pool (CHGSHRPOOL) command.  This command can be used to control performance characteristics for jobs running on your system through the allocation of memory resources and processing time slices.

If you still have problems with performance issues preventing production from getting done efficiently, there may be a problem of users running batch jobs interactively.  If your applications are running from IBM i OS commands, you can change the commands so that they will not function when called in an interactive environment.  You can do this using the Change Command (CHGCMD) command, setting the ALLOW parameter to remove the *INTERACT, *IPGM and *REXX options.

If you make changes to any IBM i OS commands, you should keep a list of the commands changed and the specific changes made.  Installing PTFs or OS upgrades from IBM could change them back, so you should keep your list with your IBM i OS documentation to serve as a reminder to check the commands following a PTF install or OS upgrade.

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 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.