Q:My question deals with the IBM-supplied library QGPL which ships with public
authority of *CHANGE. Since we put certain production programs in the library,
and it is controlled by our change control software, I would like to change the
public access for library QGPL to *USE. Will I have problems (e.g., system
functions having an authority problem) if I make this change?
A:You can change the authority for the library QGPL from *CHANGE to *USE. IBM
shipped library QGPL with public authority of *CHANGE because it is the default
library for creating objects. If you do change the authority, users who attempt
to insert objects will receive an error message. To prevent objects from being
created into library QGPL, be sure the user's current library (CURLIB) is not
*CRTDFT and does not explicitly name QGPL.
Q: I suspect that one of the programmers in our installation has a program that
adopts access as a security officer. I have changed the QSECOFR password to
prevent the use of the profile.
I used the Display Program Adopt (DSPPGMADP) command to list the programs that
adopt the user profile QSECOFR and the other profiles that have *ALLOBJ and
*SECADM authority. It is difficult, however, to isolate which program the
programmer may be using because the program list is large.
Is there some wayùother than asking the programmerùto determine if the
programmer is calling a program that adopts access as a security officer?
A:An alternative to using the DSPPGMADP command to find programs that adopt
authority is to use the auditing features of OS/400. You can audit events for
individual users or system wide. If you turn on auditing for the individual
programmer, you will be able to see which programs he uses that adopt
authority. Use these steps to record when programs that adopt authority are
used.
1. If you are not already auditing, create the objects needed to start auditing
with these commands.
CRTJRNRCV JRNRCV(jrnlib/AUDJRN0000) +
AUT(*EXCLUDE)
CRTJRN JRN(QSYS/QAUDJRN) +
JRNRCV(jrnlib/AUDJRN0000) +
AUT(*EXCLUDE)
2. Then set the audit control system value to record object and user-level
auditing events, such as authority obtained through authority adoption.
CHGSYSVAL SYSVAL(QAUDCTL) +
VALUE(*AUDLVL)
3. Change the programmer's user profile to record the use of programs that
adopt authority.
CHGUSRAUD USRPRF(programmer) +
AUDLVL(*PGMADP)
I recommend specifying the *PGMADP option only for the individual programmer.
Specifying the *PGMADP option in the Security Auditing Level (QAUDLVL) system
value would record the use of programs that adopt for all users.
When the programmer signs on and uses programs that adopt authority, the system
records the names of these programs. From this list of programs, you should be
able to find the one that is being used to adopt the security officer
authority.
Follow these steps to retrieve the information from the audit journal.
1. Extract the program adopt entries from the audit journal.
DSPJRN JRN(QAUDJRN) +
ENTTYP(AP) OUTPUT(*OUTFILE) +
OUTFILFMT(*TYPE2) +
OUTFILE(yourlib/QASYAPJE)
2. Use Query or another report tool to view the data. In the sample report in
1, the program name is listed twice: once when the program that adopts
Figure 1, the program name is listed twice: once when the program that adopts
authority starts and again when the program ends (as indicated by the S and E
entry types).
Q: I have been reprimanded for accessing a file on the system with *PUBLIC
authority. I work for a company that does not have a security policy. It is my
understanding from the AS/400 Security - Basic manual that IBM strongly
recommends a security policy be communicated verbally, but preferably in
writing.
The system has been installed for several years and has no security. If a
company has public files and has never communicated any policy as to the
responsibility of authorized users of the system, would it be fair to say that
the authorized users of the system have the authority to access any file on the
system?
A: This is not the normal technical issue that I discuss in this column. This
is a business conduct and professional ethics issue. Here are my personal
feelings about the responsibilities of individuals and companies regarding
access to information.
The security policy should be written and communicated to all system users. The
written security policy can clarify the responsibility of users relative to
data access and can strongly deter users from performing questionable
activities.
I agree with you that the security policy should be a written document. I feel
that the individual employee, however, must act responsibly even when there is
no formal security policy. I consider the information stored in a computer to
be like the information stored in the desks of your fellow employees. Even if
they leave their desks unlocked, it is not proper for another person to rummage
through the unlocked desks. The lack of a security policy does not give
individuals the right to access files outside the scope of their job
responsibility.
I have seen many installations that do not have a security policy and do not
use the available security controls. In some systems, the public has the
authority not only to view the files but also to delete the data. I am sure
that you would agree that system users do not have the right to delete the
files. Having the authority to perform an operation does not give an individual
the right to perform the operation.
In the business environment, the employee is expected to protect the
information of the company, including the confidentiality of the information.
The information in the computer files is the property of the company even if it
has been lax in protecting the information.
For those readers who do not have a security policy, this would be an excellent
time to produce one.
Security Patrol: Security Questions & Answers
Figure 1Sample Audit Journal Report
ENTRY OBJECT LIBRARY OBJECT OBJECT TYPE NAME NAME TYPE OWNER S SECOFR WOE *PGM QSECOFR E SECOFR WOE *PGM QSECOFR
LATEST COMMENTS
MC Press Online