CAPTIVE and RESTRICTED, and ckermit

[John Harney]

Greetings, fellow travelers!

We had occasion to configure one of our accounts (OpenVMS V8.3 on I64) with the RESTRICTED flag in the SYSUAF file yesterday.

Today a ckermit script failed with the error:
"This command cannot be executed. Your account is CAPTIVE."

The code returning this error is in the CKVFIO.C module of kermit, routine check_spawn.

The question: is my understanding of RESTRICTED wrong, or is the ckermit code wrong? The code checks for UAI$M_RESTRICTED with the comment:

/* for pre-V5.2 systems */

I believe that ckermit should not be checking the UAI$M_RESTRICTED flag; only the UAI$M_CAPTIVE one. (I even think that ckermit does not even need to make this check; the OS will enforce it, but I could be all wet here...)

If it seems to be a ckermit bug, I'm happy to report/assist in fixing it, and use our locally built one with new bits. If ckermit is right, then I need to re-adjust my thinking, and solve this another way.

Any thoughts are quite welcome! The code fragment is below, from ckvfio.c.

\john

#ifdef UAI$M_CAPTIVE
if (uaf_flags & UAI$M_CAPTIVE) {
printf(
"\nThis command cannot be executed. Your account is CAPTIVE.\n\n");
return(-1);
}
#endif /* UAI$M_CAPTIVE */
#ifdef UAI$M_RESTRICTED /* for pre-V5.2 systems */
if (uaf_flags & UAI$M_RESTRICTED) {
printf(
"\nThis command cannot be executed. Your account is CAPTIVE.\n\n");
return(-1);
}
#endif /* uai$v_restricted */
return(0);

[Hoff]

Restricted accounts can spawn and can get to DCL, so ckermit does look slightly confused here. CAPTIVE is (still) CAPTIVE, so it should be checking CAPTIVE whether under the old V5.2 less-restrictive definition of that concept or whether under the V5.2 and later and more-restrictive definition.

On any current OpenVMS version, the spawn processing manages this security all on its own and an application programmer can choose to override the system "decision" by adding the "trusted" setting to the spawn operation.

IIRC, the old bit values got shuffled, so that existing captive became restricted, and a new captive was added. (This could be the source of the confusion?)

No, I'd not expect ckermit to be rummaging in UAF. Applications want to stay out of the TCB where-ever and whenever they can. But you already knew that.

Of course what context you're operating in when you're activating ckermit also matters, and whether or not you want to allow the user to get to DCL.

Try some tests in the same (I assume) login context, replacing ckermit with MAIL and then using its SPAWN command.

Stephen Hoffman
HoffmanLabs LLC

[John Harney]

Thanks for the experiment.

I set the test account to /FLAG=RESTRICTED, and created a tiny LOGIN.COM that ran $ MAIL and then issued a spawn.

Upon login, mail runs, and dumps me into a spawned DCL prompt. Exactly as expected. Repeating the experiment with CAPTIVE instead of RESTRICTED has the expected result of ignoring the spawn with the error,
DCL-E-CAPTINT, captive account, interactive access denied

It does seem that kermit is broken.

Thanks!!
\john

[John Harney]

To the point about UAF, kermit makes a $GETJPIW call to get JPI$_UAF_FLAGS, rather than a $GETUAI call or otherwise touching SYSUAF itself.

This means any potential workarounds can include bigger hammers ($PERSONA_MODIFY!), not that I'd ever use such a thing.

:-)

\john

[Hoff]

For you, John, the persona system services are little more than tack hammers.

Now if you were to remap the page protections on the system service vectors and intercept the $getjpi call in flight, now that might count as a larger hammer.

But seriously, what might you be doing with ckermit here, anyway? xmodem-like file transfers?

[John Harney]

It talks to another kermit on the remote end, uploads some files, and then does stuff in that remote environment.

Turns out the failure has nothing to do with the actual transfer and execution, curiously enough; that all works just fine. It's that we use the PUSH command (based around SPAWN, apparently; not documented in the Using C-Kermit v6.0 book) to update things in the local environment.

Section 3.6 of the online C-Kermit docs for OpenVMS Installation makes reference to CAPTIVE and RESTRICTED accounts, and even says "Note that DEC says that RESTRICTED is only used 'to ensure users complete login processing without interruption'. DEC further states that they intend to modify VMS utilities to no longer prohibit spawning in a future release." But they are still stuck with their incorrect assertion: "In addition to CAPTIVE, accounts can also be set to RESTRICTED, to disable all types of spawning."

I have built the EXE again without the offending lines in the OP, both CAPTIVE and RESTRICTED, and run my small test; success.

With RESTRICTED on my account, I can execute the command as expected; with CAPTIVE the spawn request is handled by VMS, and VMS says NO.

Bottom Line: C-KERMIT should not have these checks for CAPTIVE or RESTRICTED in CKVFIO.C. I'll feed this back to the devos.

Thanks! I'm solved here.
\john