Application Software Package Security

By Rich Loeber

I often hear from readers lamenting the deplorable state of security in the third party application software running on their IBM i.  Some products enforce the establishment of a standard group user profile along with a default password for that profile.  Others have their data files configured with all access to the public.  In this day and age, these situations are certainly inexcusable.  But, what can you do?

First, a little history is in order.  A lot of mature third party software has been around since before many of you were working in the IT field.  In those days, there were no PCs, no networks and little connectivity between systems.  Security was controlled at the application level.  By that, I mean that users were presented with menus and could only access data by choosing the right menu option.  If the user wasn’t authorized to use the data, the menu option would not be available to them.  For its day, it was a good security model.

But, today is very different, with FTP, ODBC, Access Client Solutions (ACS) and other such PC-based tools that are connected to your system via high speed network connections.  That old menu security model is not applicable to today’s environment.

In the modern IBM i implementation, if your data files have public access to all users, then someone can connect to your system with FTP and download to their heart’s content.  Granted, they will still need a user profile and password, but is that the security model that you want to enforce for your shop?  I don’t think so.

An even worse situation comes from users with ACS installed.  From their desktop, an adventurous user could easily browse around your system looking for interesting file names and libraries until they find just about everything on your system.

So, what’s the solution to this problem?

First, when you’re shopping for software, the product’s security implementation must be understood before you get too far down the road.  If the product is wide open, move on to another vendor.

If you’ve already got a product with this security model implemented, you probably are not in a position to just switch to another vendor.  In that case, the first thing you should do is contact the vendor and demand that the situation be corrected immediately.  There are lots of easy solutions that a responsible software vendor can implement to correct this problem.  Don’t take “No” for an answer.

If you get little cooperation from your software vendor, you should take matters into your own hands.  The quick solution is to implement exit point controls for the critical data in your system.  If you don’t have the know how or wherewithal to create your own exit point programs, there are quite a few general purpose products on the market today that are good which address this issue (I recommend SafeNet/i from my company!).

The worst thing you can do, however, is to just sit back and wait for your vendor to fix the problem.  In the interim, your data is exposed.  You may think you’re safe, but you just cannot guarantee the safety of your data in this environment.

If you have specific questions about this topic, you can reach me at rich at kisco.com,  All email messages will be answered.

Limiting Security Officer Access

By Rich Loeber

A reader recently posed the following question to me:

How can I limit the places a person can log on as QSECOFR? I don’t want someone to be able to log in from any desktop or workstation as QSECOFR other than the main console. Are there system values related to the QSECOFR profile?

The special user profiles on your system that are set up as security officers really do have the keys to the kingdom when it comes to accessing your system.  No files, programs, data objects, files in the IFS, and more are safe from access by someone who is logged onto your system from one of these user profiles.  Keeping these profiles limited to certain devices is a good objective so that someone using them will be under direct supervision.

The best way to approach this is through a combination of object security configuration on your terminal device descriptions along with a varied setting for the system value QLMTSECOFR.  Your system will come from the factory with this system value set to ’0′ which lets anyone with *ALLOBJ authority sign on to any terminal session.  Changing this to ’1′ will only let the security
officer signon to a terminal session where they have specific authority granted at the device description level.

But — WARNING WARNING WARNING — don’t go rushing off to make this change!  You must first get it set up and test it before adopting it as practice could result in your security officer profile getting permanently locked out of your system, and you don’t want that situation on your hands.

So, your first step is to identify the device description object for your system console and make sure that QSECOFR is expressly granted permission to use the object (ie: *ALL authority).   The device descriptions on your system are all stored in the QSYS library with object type of *DEVD.  You can make changes in the authorities for the object using the Edit Object Authority (EDTOBJAUT) command.  When your console device has been updated, find the backup console device description too (on most systems, it is called QCONSOLE) and do the same thing there.

To test this setup, first sign on as QSECOFR on a normal terminal session and leave that active for the duration of your test.  That way, if things go south on you, you still have an active security officer session to fall back on to make changes.  With this backup session active, make the changes to the system value and the device descriptions.  Vary the console device off and then back on too to make sure you’re using the updated authorities for the device.  Then, make sure that you can sign on from the console using the security officer profile.

Assuming that all is OK, you’ll need to scour your system for the other terminal device descriptions to make sure that the security officer profile is not authorized for any of them.  Once this is done, then try to sign on as the security officer on another terminal, it will be denied.

Only when you’re satisfied that everything is working as planned should you release the security officer session that you’ve been holding open as your back door.

If you have specific questions about this topic, you can reach me at rich at kisco.com.  All email messages will be answered.

Are All Of Your IBM i Doors Open? – Part 2

By Rich Loeber

In my last tip, I pondered the need to watch the doors into your system.  In the old days, there was a single door in the form of a display terminal.  Today, that is only one of many doors where users can get into your system.  While most users are trustworthy, there is always the opportunity for inadvertent damage to your data from someone who happens to get into your system through a door that should be closed to them.  Then, there are always those lurking in the shadows who are just looking for an unlocked door to gain access and wreak havoc in the process.

Last time, I talked about the most obvious doors and the most obvious solutions for those situations.  This week, we’ll take a closer look at the less obvious doors and how you can deal with them.

In addition to the obvious doors to your system like FTP and Telnet, IBM i has a variety of server functions included that provide network access points for a wide variety of host-client connectivity.  These includes the likes of a DRDA DDM server that can share data files on a record-by-record basis with a client; the File Server that allows files in the IFS to be directly accessed from desktop applications; the Remote Command server that allows a desktop system to issue IBM i commands directly from the desktop; and so on.  The list is quite comprehensive and many IBM i managers are not even aware of all of the possibilities.

So, my first recommendation for you out there is to educate yourselves about the doors that are there.  Play around with IBM Navigator For i (Navigator) on your system to see all of the server settings and whether or not they are running on your system.

To use Navigator (a component of IBM i Access Client Solutions [ACS]), it must be installed on your PC with all components.  Then, the Admin HTTP server must be active on your IBM i.  It runs in the QHTTPSVR subsystem and, if active, will show multiple jobs with names that start with ADMIN.  If you need to start the admin server, the command is:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

You start Navigator from ACS.  It will start a session in your browser and you will need to sign on with a user profile with security officer permission.  From your browser, select the “Network” tab.  This will present you with a short list of new tabs, open the “Servers” tab next.  To see what servers are actually up and running on your system, look at the tabs marked “TCP/IP Servers” and “IBM i Access Servers”.  These will each show you a list of server functions on your system with a brief description of the function being served and what its current status is on your system.  It behooves you to know about all of those that are showing as started.

Once you have identified all of the server functions that are running (each is a door into your system), then you will need to validate its use on your system.  Identify the application that is using it and check to make sure that security is in place to control what can be accessed through each of these doors.  Also, make sure you know what user profiles are in use for each server function.  If common user profiles are shared between different server functions, you could have a security risk due to contextual conflicts between uses.  This kind of exposure can happen when an FTP user profile needs access to different data than an ODBC user.  If the same profile is used in both contexts, you could end up with a security exposure.  Also, remember that when you open a door for one application, it ends up remaining open for all of the profiles on your system.  You need to have a plan in place to keep the wrong people away from doors that they should not be using.

In some instances, the only way you will be able to make sense out of what is going on will be to implement one or more exit point programs to allow you to see exactly what kind of network requests are happening.  You can either write your own or get one of the several commercially available exit point solutions.  I recommend SafeNet/i from Kisco Information Systems, my company.  This will tell you which profiles are getting into your system through each door and what they are doing when they are in there.  Without knowledge at this level, you’re only guessing at what’s going on.  Guessing at activity does not promote good security policy implementation.

If you have specific questions about this topic, you can reach me at rich at kisco.com.  All email messages will be answered.

The Case For Implementing Exit Points

By Rich Loeber

Someone recently asked me if there was someplace on the Internet where they could see a case made for implementing exit points on their IBM i system.  I was at a loss for a comprehensive source and this got me thinking that it might be a good idea to just create one here.

Security exit points on the IBM i (and its predecessor OS/400) have been in existence since the mid 1990′s.  When the system was opened up to network access, the need for additional security over and above the standard IBM i OS security was apparent.   IBM’s solution was to let their customers solve the issues on their own by giving them access to specific decision points in the various network server functions that were being rolled out.  Server functions were being added to the IBM i OS to support network access to the system like FTP, ODBC, SQL, mapped drives in the IFS, file upload and download, remote command calls and a lot more.  Since that time, even more network functions have been added along with related new exit points.

To be fair and above board, I must also disclose here that my company, Kisco Information Systems, jumped on the exit point bandwagon right away when the exit points were initially rolled out.  Since 1996 we have been selling a comprehensive general use exit point solution called SafeNet/i, now in its 11th release.

The question I was asked was “Why does my shop need to implement exit point controls?”.  That is what I want to address here.  I will do so by describing several cases where additional security is needed over and above the already excellent security features that are built into the IBM i OS.

Case #1:

The classic case for exit point implementation comes from the 5250 terminal application days.  If you have a Payroll Application that runs on your IBM i and is maintained by one or more clerks, OS security has to give access to the payroll files for those clerks, but the application and terminal menu system can easily be used to restrict what operations they can do on the payroll master files.  That access will probably grant then *USE access so they can update files and generate payroll checks and reports.

The above scenario is secure from an application perspective, but you would never want your payroll clerk to be able to download the payroll master files and take them home on a USB drive, would you?  An exit point implementation can prevent this access.  The exit point process runs on top of the IBM i OS and can be used to restrict server functions by user profile, source IP address and even by objects accessed.  This leaves the IBM i OS security in tact for the 5250 terminal application and also prevents unauthorized access via the network connection.

Case #2:

Many IBM i shops have one or more “regular users” defined with *ALLOBJ access in their user profile.  This can happen for lots of reasons and in many cases, it would take a very long time to correct.  I never recommend granting *ALLOBJ access to regular users, but if your system has evolved with this issue, it cannot be fixed overnight.  In many cases, the application itself is providing the security.  The issue, however, is that these users literally have access to ALL OBJECTS on your system.  With network access to your system, one of these users could easily download sensitive data from your system, including credit card information and customer identity information, and hide it on a USB drive and walk out the front door and nobody would be the wiser.

An exit point implementation can address this issue.  Using exit points, you can restrict object access by user profile even though the user is set up with *ALLOBJ.  In fact, object access can even be restricted for the QSECOFR security user profile.  This can help to protect your system from abuse by a user profile that has been granted more access rights than they really need.

Case #3:

Since the TCP/IP communications utility FTP was added to the IBM i OS, a very easy to use network application lets users interact with the IBM i system without using a 5250 interface.  The FTP user can browse objects on your system and upload or download them.  A talented FTP user and even execute IBM i commands through FTP.  For some shops, you want a user to have these capabilities, but you wouldn’t want them granted on a broad basis.

Exit points can help with this too.  First, you can easily restrict which user profiles are allowed to use FTP.  Then, you can further restrict which FTP commands they are allowed to use letting them do a PUT, for example, but disallowing a GET.  Then, you can even give the user contextual access rights by only allowing an FTP connection from a known and trusted IP address, such as an internal IP address.  Then, if the user’s credentials are compromised, the FTP connection will still have to be established from a trusted source.

To sum up:

These are just a few examples of why IBM i shops should consider exit point implementation for additional security on your IBM i system.  There are literally dozens of additional scenarios that can be described, but these should get you started on making a case for exit points.  It is my belief that every IBM i shop should have some form of exit point controls in place in order to be secure.  If you are interested, I can heartily recommend Kisco’s SafeNet/i software if you want to jump in and get started.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

Securing Your Programmers

By Rich Loeber

Updated December 11, 2018

If you are like most IBM i security officers, you probably cut your teeth in the IT field by doing some programming.  It might even be that you still get involved in programming and your role as security officer is a part-time role.  So, you have an appreciation of the special problem that programmers pose for system security in your environment.  This article will take a look at this issue and offer some suggestions.

The problems are many.  First, programmers know how things are handled internally in your systems and know how to get around in the system.  If a programmers wants to get at some secured information, they probably have the knowhow to do it.  Secondly, programmers have a regular need to access all of the data on your system in their testing role during project implementation.  Lastly, programmers tend to see security as a hindrance to getting their work done.  (I once knew a programmer who knew OS internals on a S370 I was working on and found a trick he could use to submit his program compiles so they would always go to the head of the line in the compilation job queue.  Nobody could figure out how he was getting so many compiles done while everyone else had to sit around and wait.)

Your responsibility as security officer is to create an environment for programmers that is secure yet lets them get their important work done effectively.  These are not always compatible goals.  Here are some ideas you can consider:

  • Even though they will tell you they need it, do not grant all special authorities to your programmers.  Only give them the special authorities that they need to get their work done.  Nobody except a security officer profile should have *ALLOBJ authority.
  • Set your programmers up in a group, but don’t associate them with the special QPGMR profile provided by IBM as that has some special qualities that you don’t want associated with your programmers.
  • Don’t let your programmers have direct access to your production libraries.  Set up test libraries and control the distribution of live data into these test libraries.
  • To create test data, set up a special copy program that adopts the necessary authority to create copies of production files in your test environment.  Monitor the use of that program including maintaining an internal log of when it is used and by whom.
  • Programmers often, like my friend from years ago, like to get their compiles right away by running them interactively.  This can wreak havoc on your system performance.  Consider changing the compile commands so that they will only run in batch.  Also, set up your programmers so that they default to the QPGMR subsystem and make sure that it is set to priority 30 so they aren’t stealing valuable CPU cycles from your production environment.  Consider restrict access to the CHGJOB command.
  • When you move an application from testing into production, review all of the data and program objects to make sure that programmer ownership has been removed and that the objects are now all owned by a profile that will be used to control production access.
  • Keep a separate set of source files for program source that is being worked on.  Do not give your programmers open access to the production version of the source code for a program they need to work on.  Move the source in and out of test mode in a controlled way and log when source members are moved in either direction.  You can do this from a special program that adopts the necessary authority to make the source member moves and logs use activity.
  • Don’t let your programmers have passwords that don’t expire.  Every programmer I’ve ever met has a favorite password that they just like to keep.  Don’t let them get away with that practice.  If you programmers don’t practice good password controls, how can you expect your end users to take this seriously.
  • If a programmer insists on *ALLOBJ and can make their case, consider adding security to their user profile by requiring a 2 Factor Authentication (2FA) logon protocol.  If you need a 2FA solution, take a look at Kisco’s i2Pass product.
  • Since IBM i OS 6.1, you can host a client LPAR on your system fairly easily.  Using this capability, you can create a separate partition on your system where the programmers can have full access while still restricting access in your production environment.  You can find an IBM document on how to set that up HERE.  If you are using data from the production environment for testing in your programmer’s partition, you will still need to guard the data.  But, if you only work with test data, then this is a good solution for you.

This list just scratches the surface.  If you have more ideas in this area, let me know so I can share them in a future tip.  You can reach me at rich at kisco.com,  I’ll try to answer your questions.  All email messages will be answered.

Securing IBM i Socket Connections

By Rich Loeber

IBM i has included security exit points for adding protection for platforms that work with connected systems.  These exit points have been included in the IBM i OS for years and have regularly expanded to provide for more and more network applications.  Using the exit points, you can add protection for FTP, ODBC, File Server, Remote Command submissions and much more.  This has gone a long way towards making the IBM i a truly secure platform.

For many years, however, there were a whole group of applications that could run under the radar on the IBM i and not get picked up by the existing exit point traps.  These are socket level communication applications.  The good news is that starting with IBM i 7.2, IBM has added three new exit points to address this issue.

The three exit points added let you control Socket Accepts, Socket Connects and Socket Listens.  Applications that use socket connections can sometimes also use other network services, like FTP or remote commands, which existing exit points will cover; but some applications bypass all other network services and work directly with data at the socket level.  Having control over socket connections is critical to having a secure environment on your IBM i.

The TCP Accept exit point watches for systems trying to establish a connection to your system at the socket level.  Using the exit point, you can control which IP addresses to accept or reject, what user profiles to allow use and even control what TCP/IP port numbers that the connection can use.

The TCP Connect does the same thing as Accept except it is for outward connections from your IBM i system to remote systems.  The same controls can be implemented controlling the IP address, user profile and port number.

The TCP Listen runs on your IBM i and watches for incoming TCP Connects from remote systems.  A typical socket connection starts with a Listen and then proceeds on to the Connect with subsequent Accept.  Following this sequence, socket communication can take place without any other network services being involved.

Some of the existing applications that run on the IBM i and use these socket connections include the Apache HTTP server which does not have any additional exit point control available.  If you want to control who can use a browser on your system, this is a way to approach this issue.

Another area where this can help improve security on your system is by denying that initial contact with your system.  By denying the initial contact, a potential hacker is denied information about the system they are attempting to connect with.  For example, when you try to sign on to your system via FTP and before you even attempt to enter a user profile, the following is what you see for your FTP session:
This clearly identifies your system as IBM i by virtue of the reference to the QTCP user profile.  A savvy hacker will know that and this information will inform their future attempts to gain access to your system.  Many of the other TCP network services on the IBM i return this kind of identifying information in response to connection requests even when an invalid user profile is used.

When you implement socket level controls on your IBM i, you can deny access to all but approved IP addresses and port numbers.  When you do this, then this is what that same FTP access attempt looks like to a hacker:
Denying this connection at the socket level stops the session before any information is sent back to the requester.

Adding implementation of the socket exit points on your system can help you achieve your security goals for the IBM i.  The good news is that you don’t need to code your own solution if you don’t have the time or the talent.  Kisco’s SafeNet/i software, in its recently announced Release 11 of the product, now includes general use implementations of all three of these exit points along with all other security exit points available in the IBM i OS.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

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.