Admin Alert: Limiting *PUBLIC Access to i5/OS Objects, Part 2
January 11, 2006 Joe Hertvik
|
In last week’s column, I discussed how the default security settings in i5/OS allow *PUBLIC users to automatically modify data and run programs on an i5, iSeries, or AS/400 machine. Left unchanged, these settings can undermine system security and expose sensitive data and programs to unwanted access. This week, I’ll look at some of the cures for this problem and their potential pitfalls. Recapping the problem, the i5/OS operating system–by default–automatically sets *PUBLIC authority for new libraries and most objects created in them to *CHANGE, according to the following sequence.
For more details on how this process works, see Part 1 of this article series. You should also note that this process is in effect not only for the i5/OS operating system, but also for most earlier versions of the OS/400 operating system. So what can an administrator do to modify this slightly crazy scheme where anybody can automatically modify or run anything in a library? Here’s my checklist for determining if or how you can negate the effect of this *PUBLIC access problem. Does your software package demand that library objects have *CHANGE *PUBLIC authority? Many older packages rely on menu security (where data access is determined by which menu item you can access) rather than on object security (where access is determined by a user’s authority to use that object). In these packages, update and run access for *PUBLIC users must be set to *CHANGE (or even *ALL) because the package is built on the assumption that anyone who is able to reach an option can run that option. One option in these situations is to change your database files to *EXCLUDE access for *PUBLIC users (which totally prevents a public user from accessing an object) and then changing your application program to adopt the authority of the user who owns the data. (see Controlling PC Access.) By doing this, whenever a user runs the program, he is automatically authorized to all the files that the owner of the program is authorized to. Application-only access is a big job to implement, but it is worthwhile in that users can only modify data within the confines of an application program. And once they exit the program, they are not able to access those files again from another source, such as the AS/400 Data File Utility (DFU), ODBC, JDBC, or SQL. Your data is secured with your applications. Other options you can try to limit *PUBLIC access are Client Access Application Administration, custom-written exit point programs, and third party exit programs, which are also described in the article mentioned above. Can you change the QCRTAUT system value? You might reason that, if you change the QCRTAUT system value to a more restrictive setting (like *USE or *EXCLUDE), you will automatically affect the public authority assigned to all new objects in your system. This is a worthwhile goal but it does contain a few pitfalls. First, it does not affect current existing objects in a library. When referenced, i5/OS only uses the QCRTAUT value when creating public authority for new objects; it does not retroactively change authority for older objects in a library. So if you want to change the *PUBLIC authority for all your objects in a library, you will have to change it manually or by creating an automated routine. The second problem with changing your QCRTAUT system value is that it will also restrict access to other newly created objects that reference it for public user authority, such as devices. When new devices are created on your system by using either the Create Device Description command (CRTDEVDSP) or i5/OS automatic configuration, i5/OS uses the QCRTAUT system value to assign *PUBLIC authority for that device. This means that if you set QCRTAUT to *USE or *EXCLUDE, most users will not be able to sign on to that new device because i5/OS also requires *CHANGE authority to a device description before it will let a user sign on to the system. In this case, you would have to explicitly change *PUBLIC access on newly created devices to *CHANGE, so that your users can sign on with the new device. While this adds another layer of overhead in providing device access to your system, it could also shore up system security in that all new objects have to be explicitly configured for system sign-on. Can you change the Create Authority values for your system’s CRTLIB command and for your existing libraries? This solution works in a similar fashion to changing your QCRTAUT system value, but it avoids the pitfalls of changing *PUBLIC authority for newly created device descriptions. To change the Create Authority parameter (CRTAUT) for a library, you can issue the following Change Library command (CHGLIB): CHGLIB LIB(library_name) CRTAUT(*USE or *EXCLUDE) This would override the QCRTAUT value and use your intended *PUBLIC authority for any new objects that you want to create in this library. Like changing the QCRTAUT system value, you would also need to change the object authorities for any older library objects that you want to restrict access to in your library. Besides changing the CRTAUT value for individual libraries, you could also change the default value assigned to the CRTLIB command’s CRTAUT parameter. Last week, I noted that the default values for the Create Library command (CRTLIB) were the following: CRTLIB LIB(libname) TYPE(*TEST or *PROD) TEXT(‘text description’) AUT(*LIBCRTAUT) CRTAUT(*SYSVAL) CRTOBJAUD(*SYSVAL) If you want to change the CRTAUT parameter so that it has a default parameter of *USE, rather than *SYSVAL, you could create a copy of the CRTLIB command, change its default value for CRTAUT to *USE or *EXCLUDE, and then place it in a system library that is higher in your library list than the QSYS library where all commands currently reside. By doing this, you would automatically use the new CRTLIB command whenever you create a new library, and that library would then have the new CRTAUT value. Instructions for changing default parameter values can be found in an article I wrote on How to Change OS/400 Command Default Parameters Alternatively, you could also change the command defaults on your most frequently used Create commands (CRTRPGMOD, etc) to use your preferred *PUBLIC authority value. However, since most of these commands already use the target library’s CRTAUT value for *PUBLIC access–it is more efficient to change the CRTLIB command and the values in your existing libraries, because these values will ripple down to your Create commands. RELATED STORIES |
