Carol discusses why you should understand the features of IBM i Access Client Solutions (ACS) and why you may not want all users to have access to all features.

By Carol Woodbury

Don’t get me wrong: I am a huge fan of ACS and all the features it provides. But what you may have never done is think about those features from the point of view of an end user. In other words, put yourself in the shoes of some of your end users and examine exactly what parts of ACS they can access and what they can do with those features. Then ask yourself: is that access appropriate for those roles?

The short answer is that, if you do nothing, all users (including end users) can access every feature of ACS. That statement, in and of itself, may spur you into action. But if it doesn’t, let’s dive a bit deeper. Figure 1 shows a default installation of ACS. Take a look at the last two categories: Console and Management.

Figure 1: The default installation of Access Client Solutions (ACS)

Would you ever want your end users to have access to this functionality? I can hear several responses to this question.

One is, “No, of course not, but there’s no way my end users would ever know what do to with this function.” Did you just hear yourself? Isn’t it scary to think that you’re giving access to users who have no idea what it does? But that’s exactly what you’ve done by leaving the options available to them. Just like end users should only have access to the green-screen menu options or web application features that correspond to their job functions, the same applies to ACS.

Another reaction is this, “It doesn’t matter what they have access to; they won’t have sufficient authority to do any damage.” To you I say, “Bravo!” You have made sure your users only have sufficient authority to do their jobs. Unfortunately, you are the exception and not the rule.

I was reminded by someone at IBM the other day that neither New Nav nor ACS allows any functions that the user isn’t authorized to. True statement! Unfortunately, most organizations have given more authority than is necessary to their users and have not secured their data. Therefore, ACS is an excellent method for exploiting an organization’s wide-open security configuration. Once again, there is no fault here with ACS. This is strictly on organizations for not taking proper action.

If you still aren’t convinced, let me show you what an end user can do with Run SQL Scripts functionality. Once it’s launched and a connection to your IBM i is made, end users can run CL commands. “But wait,” you say, “their profile’s configured with Limited Capabilities set to *YES, so they can’t run commands.” While the limited capability setting applies to a command line, it does not apply to Run SQL Scripts. See Figure 2 for an example.

Figure 2: Users with limited capabilities can run commands in ACS.

The first command creates a library. Not a big deal or security risk. But the next statement is to delete the library. So yes, I deleted the library I just created. But what if JOE (the profile I used for this example) tried deleting one of your production libraries or files? Would he have sufficient authority to do that? Finally, he displayed the contents of the PROD_LIB, and it went to a spooled file. No harm there, right? Right, except for the fact he can use the Printed Output feature of ACS to view the spooled file, so, depending on the DSPxxx command run, he may easily be able to use this feature to view confidential data.

In addition, he doesn’t need to know all of the parameters of a command as the F4 prompt is available in Run SQL Scripts just like it is in green-screen. The following commands can easily be entered by an end user.

cl: dspobjd prod_lib/*all *all output(*outfile) outfile(qtemp/testing);

select * from qtemp.testing;

select * from prod_lib.sales;

Of course, Run SQL Scripts does not give JOE additional authority, so he will only be able to run commands to which he’s authorized. Remember, however, he can also run SQL against any file he’s authorized to. If you tell me that your users don’t know how to run SQL, I’ll tell you that I didn’t know how to run SQL either until I started to look at online examples. End users may not know how to run SQL right now, but that’s an easily discoverable skill.

ACS and the Integrated File System

Next take a look at the Integrated File System (IFS) feature. Initially, it will launch the users into their /home directory, but if they don’t have one, they’re launched directly into the /root directory. Or they can use the Up arrow to walk up the directory structure and then click on whatever directory they want to open and explore. Or they can simply type in the name of the path if they know it, giving them the ability to list the contents of a library if they use the /qsys.lib/library_name.lib/ naming convention.

What can they do with these views? Well, in many organizations, listing the contents of the /home directory produces a list of at least some of the profiles on the system. If users have malicious intent, they now have a list of profiles for which they can attempt a logon since they now have half of the equation. Recognizing that most individuals aren’t purposefully destructive, let’s look at what they can do by accident. If you haven’t taken action to secure the directories containing private or company-critical information, they could simply right-click on the object and delete it (if *PUBLIC is set to DTAAUT(*RWX) OBJAUT(*ALL). Or, with just DTAAUT(*RX) authority, they could choose Download and view the contents. See Figure 3. Again, think of these functions in the hands of your end users! What you and I view as really handy features could prove to be a huge problem in the hands of end users. They could take actions that you don’t want them to take or perhaps worse, view data they have no business need to see or even delete objects.

Figure 3: Options in ACS’s Integrated File Systems feature

Limiting End User Access to ACS

Now that you’ve realized that you don’t want all ACS features available to all users, what are your options for limiting user access? At the very least, you’ll want to take advantage of Application Administration in Heritage (old) Navigator or Function Usage in New Nav. The Client functions allow you to select which pieces of ACS users are allowed to access. In New Nav, click on the padlock icon and choose Function Usage. To see the functions that pertain to ACS, slide the display over until you see the Category column and type “Client (ACS)” in the search field. The resulting list of functions are the ones that will help you control ACS features. Select the function you wish to control and click Change. If you want to deny all users except for those with *ALLOBJ special authority, simply change the default setting from Allowed to Denied. If you need to add some users, simply add those names or their group name to the Profile(s) field and click on Add under the Allowed column. For example, you may want to add your developer’s group so they can access the system via ODBC. (See Figure 4 for an example.)

Figure 4: Change Function Usage modifying ACS access

Another thing you can do is customize which pieces of ACS that are distributed to users’ desktops. This technique is explained in the section called Customized Packages in the Getting Started documentation that comes with ACS. Finally, if you ever go to a conference such as COMMON, check to see if Wayne Bowers from IBM is speaking. He does a fantastic job of explaining all of the methods of customizing ACS distributions as well as registry settings that can be implemented to ensure none of these methods can be bypassed.

Summary

I encourage you to create a test profile that mimics an end user profile, launch ACS, and see what you can do (making sure you have to sign on using this profile when you launch ACS or else you’ve just signed on again with your own profile). I’ve found that when I’ve done penetration testing against IBM i using profiles that represent typical end user roles and then show management the results, they finally understand how exposed their data is. By showing actual examples of how end users can access data and perform tasks that are outside of their job responsibilities, management can see the issues and it’s no longer just theory. Please don’t believe or disbelieve me based on this article. Perform your own test and see for yourself!

Whether you choose to implement every possible method to restrict access to ACS, or just one or two, or only object-level security, the choice is yours. But you must do something or understand that your data is accessible by all users on your system via ACS.