Whenever I help a client improve systems security, one of the areas of focus is usually queries. Queries can cause a few headaches, so let's discuss why they are problematic and how to secure them.

A Mixed Bag

Why is securing queries so problematic? All queries do is read database files, apply the criteria of the query, and produce a printed report, right? What's so difficult about that? If producing a report was the only thing a query ever did, it wouldn't be that difficult. But one of the options of a query is to produce a file rather than a printed report. If the same person always runs the query, things are fine. But if one person runs the query on Tuesday and another on Thursday, problems can start. Why? Because the query is often written to delete and re-create the file produced by the query. Ms. Tuesday owns the file after running the query, so if the *PUBLIC authority of the file isn't *ALL, when Mr. Thursday goes to run the query, he doesn't have sufficient authority to delete and re-create the file. Compounding the problem is that the query file is often being created into the same file as all production data.

Recommendations

I highly recommend moving the query files into a separate library from your production data. This provides options for securing the files that you don't have if you leave them in the same library. I also recommend that you don't lump all of the system's query files into the same library, because the query file is usually downloaded to a PC or sent to a server. When downloading to a PC, the user running a query to gather inventory information is most likely not the same person running a query about your organization's financial data. And for that reason, they shouldn't have the ability to see—or download—the other person's data. If all query files are in the same library, it becomes much more difficult to secure files to ensure that the appropriate people see the appropriate data.

Another reason to separate the queries out of the production data file is because of the authority required to the library. If the file is being deleted and re-created, the users need *CHANGE authority to the library. You typically don't want to have your production data library set to *CHANGE. For query libraries, you can set the *PUBLIC authority to *EXCLUDE (to prevent unauthorized access of the data) and authorize the user or group with *CHANGE authority.

Options

Option 1: Have the query file owned by the application owner, call the query from a program that adopts the application owner's authority, and specify on the query to replace the member rather than the file. This technique doesn't change the ownership of the file, and since the query runs with adopted authority of the file's owner, there will be no problems.

Option 2: If the users running the same query are in the same group profile, consider configuring the users' profile so that any new objects created are owned by the users' group profile. In other words, set the Owner parameter to *GRPPRF. Note: This option will not work if the query is run by users in different group profiles.

Option 3: Once you've separated the queries into different libraries, you can specify the Create authority parameter on the library. In this case, you can specify an authorization list for that parameter so that any new object created into the library is secured with the authorization list. You typically authorize the users or groups running the query with *ALL authority and set *PUBLIC authority to *EXCLUDE. This option works well when users in different groups need access to the query files.

How Policy Minder Can Help

If you aren't aware of all of the query definitions you have on the system, you can "discover" them by creating an object template that includes the object type of *QRYDFN. When you run a compliance check, all queries will be listed as part of this template.

Also, once you decide how you're going to secure the query files, you can use Policy Minder's FixIt function to set the authority based on one of the configuration options described above, including moving users into a new group profile, configuring the profiles' owner parameter, and configuring the Create authority attribute on the query libraries. Finally, you can run a regular compliance check on the template to ensure the user profiles and files stay configured properly.

Carol Woodbury is president and co-founder of SkyView Partners Inc., a company specializing in security policy and compliance software and services. Carol is a system security expert, a noted author, and an award-winning presenter. Along with Pat Botz, Carol is the author of Experts' Guide to OS/400 and i5/OS Security.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale