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.
LATEST COMMENTS
MC Press Online