Security and DDM Files
May 26, 2004 Hey, Wayne
While implementing an “application-only access” security program, I ran into a problem with DDM files. The job running in the communications subsystem runs under user QUSER, which typically falls under *PUBLIC authority, so my DDM files cannot be set to *EXCLUDE, as recommended by the application-only-access security strategy.
Can the job be modified to run under a different profile, or is it best to give QUSER access to the desired DDM files? Or should we assign QPGMR as QUSER’s group profile, since the files are owned by QPGMR? QUSER has no password and cannot be signed on to.
–Doug
Application-only access is a security strategy I devised for protecting data, which can be implemented by all OS/400 installations. The strategy is so named because users do not have access to data outside of applications. The applications will adopt or swap user profiles to allow access while inside the application. More information can be found at www.woevans.com.
Now, to answer Doug’s questions. Yes, a job can be modified to run under a different profile, if you are an *ALLOBJ and *SECADM user and you can write and install an exit program to swap user profiles for a job.
OS/400 provides the system manager with two functions that can be used together to change the user profile for a DDM job. OS/400 includes two tools you will need in order to perform that task: they are security APIs that can swap the user of a job and exit points to run programs that will contain the swap-user-profile function.
A brief description of the tools follows.
EXIT POINTS AND EXIT PROGRAMS
Exit Points in OS/400 allow an installation-provided program to run before a request for data is processed. These programs are often called exit programs and are designed to allow an installation to screen remote requests. That is, exit programs decide whether a transaction passes or fails. Exit programs can use an API (application program interface) to modify the user profile of a job.
You specify exit programs to OS/400 using the Work Registration Information (WRKREGINF) CL command.
However, I do not recommend that you attempt to write exit programs. They are not easy to write. I recommend that you purchase exit programs from a vendor of exit programs. You should use exit programs to perform the swap, because if you simply did the swap for all DDM jobs, users other than those you intend could use DDM to access the files.
The vendor exit programs not only perform the swap but also let you specify conditions on the swap. This is an example:
IF the request came from our internal network (as opposed to the Internet) AND IF the file is PAYDAYHST OR PAYMNTHST THEN SWAP the profile of the to QPGMR. IF the file is not one of the valid files listed THEN REJECT the request.
To code this simple request, it would require several days to complete the research, write the programs, and check the code for errors. (It is not easy code). This is why I recommend using third-party vendor programs. Not all vendors offer object path selection, so be careful when you select an exit program vendor.
SECURITY API’S
OS/400 has an abundance of callable programs to perform system functions. There are many APIs, but the security APIs have just the tools you need. These are the three programs we will be using:
- QSYGETPH, or get profile handle (a profile handle is something that allows the swap of the user profile).
- QWSSETPH, or swap the user profile of a job.
- QSYRLSPH, or release profile handle (this frees the internal storage that IBM allocates for the swap).
(You will not be writing the code to perform the swap if you follow my advice about using vendor-written exit programs.)
Let me illustrate how to use the APIs to perform the swap. First the attached program must be owned by a user with *ALLOBJ and *SECADM special authority, and the program must adopt its owner’s user profile.
Here is the code:
PGM &NEW_USR DCL &NEW_USR *CHAR 10 DCL &HANDLE *CHAR 12 CALL QSYGETPH (&NEW_USR '*NOPWD' &HANDLE) CALL QWTSETP (&HANDLE) CALL QSYRLSPH (&HANDLE) ENDPGM
Using APIs is a snap if you know which ones to use. APIs are documented on IBM’s Information Center site. IBM’s documentation is a valuable tool for OS/400 programmers.
Doug mentioned two other ideas. He asked whether it would be best to give QUSER access to the desired DDM files or whether he should give QUSER the group profile QPGMR, since the profile QPGMR is the owner of the files.
Either technique would work, but swapping user profiles is the best solution. The alternatives Doug proposed are not good, from a security design standpoint, for several reasons.
If you grant QUSER access to the files, QUSER has access to the files all of the time, not just when using DDM. Granting QUSER such authority may allow users to edit or copy the files, which is a violation of the application-only-access strategy “do not give users access to data outside of the application.” The worst choice is to make QUSER the member of the group profile QPGMR, which owns production data, because doing so would allow users not only to modify the files but also to delete, rename, and even authorize other users to the files. This, again, violates the application-only -access strategy: “do not make a user a group member of the profile that owns objects.”
Users should not be members of the group profile that owns data or be authorized to the data outside of the application. When users are running an authorized application, the application should give access either through adoption or swapping of profiles.
I prefer the swap technique because adoption does not always work. In the case of the server DDM, you must swap.
ONE LAST RECOMMENDATION
Doug indicated that QPGMR is the owner of the production files. This will work, but I recommend having a user-created profile OWNMYDATA (or some other name) as the owner of production data. The user profile QPGMR is authorized to other IBM objects, and if users sign on to QPGMR, you probably won’t want them accessing production files.
If you have any additional questions, please contact me. You can read more about application-only access, exit programs, and user profile swapping at www.woevans.com.
Application-only access is a simple strategy, but you must not violate any of the points:
- Users have no access to data outside of the application.
- Users are not members of the group profile that owns data.
- Users get access via an application that adopts or swaps to give them access only while in the application (application-only access).
–Wayne O. Evans
Security articles authored by Wayne O. Evans can be found on his Web site, www.woevans.com. E-mail: woevans@aol.com
