Captive Logins?

[johnslayton1]

Hello,

Can someone please explain the command on how to escape out of a Group captive login process?

Is there any related docs I can read up on?

Thanks.

[Volker Halle]

John,

if the user account has /FLAGS=CAPTIVE set, you can not break out of the login-prcedure to the DCL prompt. The system will automatically log you out, if the login procedure (or any other DCL procedures called) would accidently exit back to DCL level.

Volker.

[Robert Gezelter]

John,

There is no generic definition for a "group captive login process" in OpenVMS.

If an account has been setup with the CAPTIVE flag, the answer is quite simple: NO. The CAPTIVE state is designed from the outset for use where it is desired that users NOT be able to gain control.

If a manager has (properly) set up a system-wide, group-wide, or similar process intending it to be mandatory, the answer is also NO.

If you can be more specific about what the problem is, perhaps the question can be clarified.

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

[Hoff]

Exiting out of a captive command procedure is indicative of either a bug in the particular local command procedure, or (far less commonly seen) a bug in OpenVMS and in DCL. Put another way, there is typically and intentionally no way out of a captive command procedure.

If seeking to create and to write a captive command procedure, documentation and materials are available on that topic. The DCL book I wrote a while back -- writing real programs in dcl, 2nd ed -- has coverage on creating captive command procedures (if you can find a copy; it's out of print), and the User's Guide and particularly the Security manuals are the center of documentation on captive command procedures within the manual set.

Most of the hacking documentation for OpenVMS is outdated (and whether approaching this area as a whitehat or a blackhat, still worth reading), and the exposures and the vulnerabilities discussed in these documents are (AFAIK) infrequently or no longer present, or are network-level and generic vulnerabilities. Start with the VMS Hack FAQ -- pointers to that are in the OpenVMS FAQ.

When defending against captive escapes and against security attacks in general, that subject area is far larger and far more complex than can be discussed in the little tiny text box here in ITRC. Start with the security manual.

If this is related to your previous questions on passwords and on captive login procedures, you might want to acquire formal assistance and to specifically look at the network or login-related failures that are leading to the lock-out.

[John Gillings]

John,
As others have said, captive is captive. If you do manage to break out OpenVMS will log you out immediately.

That said, if you're in a command procedure that contains a command loop or menu, and it hasn't been written properly, a fairly reliable way of breaking out is to enter:

'f$pid(goto)

at the prompt (the quote is required). This will work if the procedure uses the INQUIRE connand to prompt for input. Theory left as an exercise...

[Hoff]

INQUIRE has been locked out in command procedures for quite some years.

Access to INQUIRE was first locked out circa VAX/VMS V5.2, IIRC.

This INQUIRE restriction arrived around the same time as then-existing CAPTIVE accounts were demoted to RESTRICTED, and INQUIRE was locked out when attempted within a then-strengthened CAPTIVE command procedure with a CAPTINQ error.

[Wim Van den Wyngaert]

Not an escape but I found that task to task and rsh still works for captive accounts. You can use that for passing commands to be executed.
The commands you can obtain with read.

Fwiw

Wim

[Wim Van den Wyngaert]

Or in the procedcure you can do :
$ read sys$command xx
$ ''xx'

This would execute any command entered by the user.

Wim (now using captive for the first time)

[Robert Gezelter]

Wim,

Task-to-Task, RSH, use of raw input in substitution (and others) will, of course, work.

Captive merely ensures that the user cannot break out of the command procedure and application. It does not (nor could it) provide any guarantee that there is no way to misuse the code provided by the developer.

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

[Wim Van den Wyngaert]

Yes Bob. But if you are locked into a menu (if f$mode() .eqs. "INTERACTIVE" then @menu) just make sure that all other modes are blocked (not just exit in login.com).

Otherwise someone could abuse the account with rsh /us/pass.

I'm thinking of well known accounts for printer management, operator menu's, etc.

Wim

[Richard W Hunt]

The next question is, are you trying to evade your own site's security setup? Or are you trying to understand how to terminate a RESTRICTED login shell? If the former, I would advise you to not do that. Security managers get "ruffled feathers" if you try to bypass the security barriers they have worked so hard to get just right.

[DECxchange]

You can set flags = restricted and captive in the system authorization file. You can also put $ set nocontrol=(c,y) in the captive account's login command file at the very top of the DCL command procedure (or any account, for that matter, that you do not wish to access the DCL prompt).

But if you're talking captive or restricted, there's not a whole lot the account can do. It can only execute the program or command procedure that the login account has been setup to do.

If you're looking for a way to break out of it, there is no way unless you happen across a VMS operating system bug. I doubt there are any along these lines, as VMS has the highest security rating of ANY operating system.

But if you still want out of the captive account, you will have to talk to the system manager (or administrator if you're a windows or Unix type guy). Or there is a security manager, talk to him.