On Thu, 9 Sep 2010 07:34:23 -0700, Charles Mills <charl...@mcn.org> wrote:
>YES! That's it! Exactly. > >Charles > >...snipped... > >This looks pretty good: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/1.6 > ><quote> >The authorized program facility (APF) allows your installation to identify >system or user programs that can use sensitive system functions. To be >APF-authorized, programs must reside in APF-authorized libraries, and be >link-edited with authorization code AC=1. The system maintains a list of >APF-authorized libraries that contains the following information for each >library: ></quote> That may have made you happy, Charles, but technically it's wrong. A program is only APF-authorized if it's running. It only becomes APF-authorized while running only if: (a) it resides in an APF-authorized library and is link-edited with AC(1) and when it's started it comes from that APF-authorized library and (some other stuff here omitted for simplicity, such as some UNIX aspects, tasklibs, etc.) -and- (a1) it's run by the initiator directly; or (a2) it's run by some other mechanism that supports starting APF-authorized programs, such as IKJEFTSR, or execmvs(), or ATTACH with RSAPF=YES; -or- (b) it resides in an APF-authorized library and it's loaded by a program already running APF-authorized. The fact that it's in an APF-authorized library and link-edited with AC(1) does not make it APF-authorized. It merely makes it possible to run APF-authorized, subject to some other conditions. The fact that it's in an APF-authorized library and -not- linked AC(1) does not make it not APF-authorized. It merely means that when it runs it won't be APF-authorized by default. But it might be APF-authorized if run by something that's already running APF-authorized. And all this ignores programs that run in supervisor state or system key, which is very closely related to running APF-authorized. But wasn't your question more about what a program running APF-authorized can do? That has a very simple answer, in a z/OS context: Basically, anythying it wants to. In the most simple terms it can issue MODESET to switch to supervisor state or system key, and that's really what APF-authorization means. But in slightly more complex terms it can also use privileged system macros that honor APF-authorization as one means of control. But the important thing is that "anything it wants to." It can bypass all security in the system, access any data in the system, and hide all traces that it has done that. I'm not sure we have any documentation that says that all in one place, and little (if any) of the documentation properly distinguishes between "being APF-authorized" and "having the capability of becoming APF-authorized". We even have (or had?) documentation in the z/OS UNIX System Services books stating that having the +a extended attribute makes a UNIX executable "APF-authorized", and that's also wrong. It really means "consider this program as residing in an APF-authorized library". It seems to be a hard concept to understand, and to describe properly. -- Walt Farrell IBM STSM, z/OS Security Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
