Navigating the manuals - LGI_CALLOUT

[Richard W Hunt]

Running OpenVMS for Alpha v 7.3-2, patched at least through mid-Nov. 2007. Using the OVMS documentation disk that came with the install kit.

I have been searching the manuals on my CD and I've done at least some web searching, but I'm having trouble finding documentation on how to write a login callout routine.

We have some DoD requirements to display a specific warning and ask a specific question BEFORE the user presents a username and password. While I disagree with this concept (because it means I don't yet know to whom I am speaking and therefore cannot truly audit a refusal to agree to usage terms), that is what the requirement says. You know what they say: "The right way, the wrong way, and the Navy way." Two guesses as to which way this isn't. Anyway, I thought a login callout might help me do this per exact requirements.

Considering the headache I had with the PASSWORD_POLICY module, I know I'm asking for trouble with a login callout. But I have to at least give management a risk/reward analysis. Without knowing what is involved, I don't know how to properly evaluate the risk. Or the cost in man-hours to make it work.

Where would I find more on implementing a LGI_CALLOUT routine?

BTW I have also searched SYS$EXAMPLES source code for references to the word CALLOUT and the parameter LGI_CALLOUT. I've also searched the .PDF docs on my "OpenVMS documentation for Windows" disks. And I've searched the forum for LGI_CALLOUT and login policy. So far, no joy for OVMS, though I did hit a couple of UNIX articles I might have to read later.

[Jan van den Ende]

Richard,

>>>
requirements to display a specific warning and ask a specific question BEFORE the user presents a username and password.
<<<

Well, more or less the same (in a police setting).

We use SYS$ANNOUNCE for that.
It displays a message before the Username: prompt.
Some wording like "<...> Continuing implies acceptance of the above terms."

Of course, your wording will have to follow your rules, but the concept will be clear.

Note that you can put in and leave out anything in SYS$ANNOUNCE.

hth

Proost.

Have one on me.

jpe

[Jim_McKinney]

The LGI callouts are documented in the VMS Utility Routines Manual - online, one place to find it is http://www.openvms-rocks.com/docs/OPSYS/VMSOS731/vmsos731/4493/4493pro_032.html#4493_lginout_chap .

[Richard Whalen]

There is also the system password, but from looking at the LOGINOUT sources it looks like the system password is requested before SYS$ANNOUNCE is displayed and from your description the request is for SYS$ANNOUNCE then sysetm password

SET

TERMINAL

/SYSPASSWORD

/SYSPASSWORD
/NOSYSPASSWORD (default)

Requires LOG_IO (logical I/O) privilege.

Determines whether the terminal requires that a system password
be entered before the Username: prompt.

[Richard W Hunt]

The specific requirement is not satisfied by use of the SYS$ANNOUNCE features.

Right now I am "close" to the requirement by putting something in the SYLOGIN.COM file to ask the "do you agree to the terms and conditions etc etc etc" question that is the requirement. But the exact requirement is that I must ask that question BEFORE the username and password are presented. While I deeply disagree with the security implications of running more code than minimally necessary in the context, the requirement is out there for all USA DoD systems. So if I CAN reach compliance, I need to do so or tell the government managers why I can't. And can you say "Pointy-haired bosses" Mr. Dilbert?

[Robert Gezelter]

Richard,

I would concur that the LGI_ callouts are not needed, as least to implement that requirement. SYS$ANNOUNCE (and its after login validation, SYS$WELCOME).

Note that the logicals need to be defined in the SYSTEM logical name table (ASSIGN/SYSTEM). To read the text string(s) from a file, the "@" must be the first character, to wit:

$ ASSIGN/SYSTEM "@SYS$MANAGER:WARNINGBANNER.TXT" SYS$ANNOUNCE

Should cause the referenced file to appear on the terminal before the Username prompt.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Richard,

The LGI$ callouts are documented in the Utility Routines Reference manual available online from the OpenVMS www site at http://www.hp.com/go/openvms

There is a related, but probably not relevant section of the System Services Reference Manual relating to the $ACME Credentials Management system service.

- Bob Gezelter, http://www.rlgsc.com

[Jim_McKinney]

Since your requirement involves interaction prior to LOGINOUT's password authentication you'll most likely want to take a look at the LGI$ICR_IACT_START and LGI$ICR_AUTHENTICATE LGI_CALLOUTs in the doc. The doc does have example code that could help you get started.

[Richard W Hunt]

I've looked into the ACME stuff. Doesn't seem to apply.

Once I found out where to look, I was indeed looking more closely at the IACT_INIT segment as a possible candidate for this requirement.

Thanks to all for the directions. The documentation I needed wasn't where I expected it and navigating the documentation CD is trickier than it looks if you are thinking in the wrong direction. Since this is a security-related action, I was looking all over the security stuff. But of course it wasn't there, was it?

In any case, I'll leave the thread open another day or two but I think I know enough to at least have a clue. USUALLY I'm clueless - but sometimes I get lucky.

[Jess Goodman · Accepted solution]

I made a quick modification to our loginout callout code to give you an example of how you could do this. See attachment.

After installing this code as a loginout callout image on a system, initiating login results in:

$ TELNET HOME
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host 127.0.0.1, port 23
-TELNET-I-ESCAPE, Escape character is ^]
Are you a spy? YES

%TELNET-S-REMCLOSED, Remote connection closed
-TELNET-I-SESSION, Session 01, host 127.0.0.1, port 23


$ TELNET HOME
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host 127.0.0.1, port 23
-TELNET-I-ESCAPE, Escape character is ^]
Are you a spy? NO

Username: barnold
Password:

[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.