Navigating the manuals - LGI_CALLOUT

[Richard W Hunt]

Jess, that might be very useful. I didn't see an attachment. Is there a way for me to get a copy of that module, at least as an example?

My idea is that once I ask the preliminary question (Do you accept the terms of use?) then I want ordinary login to proceed. Your "Are you a spy?" question would be just as good. (Except of course that the US Government is not known for a sense of humor. My reference for the latter statement is Agent K from "Men in Black".)

[Richard W Hunt]

Whoops! My bad. I guess I had a problem when I loaded that page the first time because I'll swear I didn't see the attachment. But I saw it the second time. Thanks, Jess!

[John Gillings]

Richard,

As you'll discover the LGI_CALLOUTS is a rather obscure and convoluted mechanism. Figuring out exactly how to do what you want can be a challenge. (Jess has done a fine job of coding a concise example).

There is another approach which at first sight will probably give your spooks apoplexy, BUT, stay with it and you'll see it has the potential to give you a much more flexible and secure environment.

I'm going to suggest using a CAPTIVE account with NO PASSWORD!

Here's how it works. You have a single central username through which ALL logins are made. Let's call it ACCESS, CAPTIVE with no password. When it logs in, you implement whatever questions or secret handshakes you want. If the user passes all the tests you then

$ SET HOST 0

to create the "real" process. Your user then sees their real username/password prompt. The login procedure checks that the source of the login is our ACCESS account, if not, the login is denied.

The advantage is you can implement anything you want without having to (force) fit it into the LGI model. Another advantage is you can add /LOG=logfile to the SET HOST command to get a complete keystroke log of the session. Since you're in a different username from the target, you can easily resolve privilege access issues for logs and audit trails. For an even higher level of security, you can put the ACCESS account on a different system, maybe structure your network so initial access is only possible through the "firewall" system which accepts on the ACCESS account. Use "SET HOST real-target" (obviously SET HOST could be replaced with TELNET, SSH or any other protocol you prefer).

The biggest RISK associated with LGI_CALLOUTS is in the timing of the installation of the image, definition of the logical name and setting of the SYSGEN parameter. DO NOT under any circumstances allow LGI_CALLOUTS to be set in your CURRENT parameter set. If it's set, and the logical name is undefined, or the image not correctly installed, then NO PROCESSES OF ANY TYPE CAN BE STARTED ON YOUR SYSTEM!!! This tends to break most system startups!

For anyone who hasn't seen it before, this situation can be very difficult to diagnose as there are no error messages indicating why you can't login. This is, to some extent, intentional. If you have security requirements, you may prefer a dead system over one which isn't enforcing your policies.

You should ensure LGI_CALLOUTS is clear when the system boots. Define your logical name, install the image and then only set LGI_CALLOUTS if you know it was successful. You then get control over what you do if for any reason you can't install LGI_CALLOUTS.

[Richard W Hunt]

Thanks for the advice, John. I'll probably use it to justify "leaving things as they are" within the current system. In other words, by showing that this code increases system risk, we get to balance the risk against the (minor) variation caused by asking the "Do you agree" question slightly later than mandated.

I never actually wanted to write this, but I AM required to research it and describe the level of effort and risk. One of the nasty little hoops that government contractors have to jump through, now and then.