How to SPAWN from OpenVMS CAPTIVE account in Perl

[Tan Yeok Joo]

Recently our customer has some of the accounts set to CAPTIVE for security reason. In C programs, they have bit 6 of CLI$M_TRUSTED flag set, to allow SPAWNing.

How to script that in Perl ?

Cheers,

[Heinz W Genhart]

Hi Tan

first of all welcome to ITRC OpenVMS Forum.

Within a captive account it's not possible to use the spawn command. See the OpenVMS System Manager Manual. ftp://ftp.hp.com/pub/openvms/doc/AA-PV5MH-TK.PDF

A person using a captive account is locked into the application software where access to the DCL level is denied.

Regards

Geni

[Tan Yeok Joo]

ThankS for the reply.

The customer has successfully made the lib$spawn call in their C programs, in those CAPTIVE accounts, by setting the TRUSTED.

#ifndef CLI$M_TRUSTED
#define CLI$M_TRUSTED 64


bit 6 TRUSTED If this bit is set, it indicates a SPAWN command on behalf of the application. If this bit is not set, it indicates that the SPAWN command originates from user. SPAWN commands originating from users are disallowed in captive accounts (DCL).

Right now, they are trying to figure out how to do that in Perl.

[Jan van den Ende]

Tan,

First, let me join Geni in welcoming you!

And his answer is correct.

The solution would be to change the CAPTIVE flag to RESTRICTED in the user's UAF record.

The confusion is understandable for older software:
The behavior of the Restricted flag used to belong to the CAPTIVE setting. Then (VMS V5 timeframe IIRC) it became desirable to have a MORE restricted set of limitations. As it was contra-intuitive to have CAPTIVE be less severe than the new-to-introduce term RESTRICTED, the behavior of the flag got the new name, and the behavior of CAPTIVE stayed the most limited, but got more constraints added.
But in older software it is not uncommon to find specifications named CAPTIVE while referring to the old captive behavior that should now be rightly termed RESTRICTED.

One more example of the really BAD aspects of re-branding products, functionalities, and whatever. MORE so if the old name lives on in a new meaning.

hth

Proost.

Have one on me.

jpe

[Karl Rohwedder]

Tan,

if really desired, you may try to change the perl source module (should be in VMS.C) to specify the CLI$M_TRUSTED bit, when performing the LIB$SPAWN for the system() call. Then create a special PERL version for those users.

But perhaps specifying restricted instead of captive is enough security.


regards Kalle

[Tan Yeok Joo]

Thanks everyone,

I have tried to take away the CAPTIVE flag, leaving only the RESTRICTED, I was able to SPAWN out from the Menu through TPU ( as quite a lot of the Menu options are written using TPU and other utilities that could spawn out within the utility itself).

Maybe I didn't describe the senerio well enough. The customer is trying to lock some very powerful accounts with a MENU, but still be able to SPAWN out within the option itself, performing some tasks, and back to the Menu again. But not able to do a "manual spawn" within a utility like TPU.

confused ? me too :-)

[Hoff · Accepted solution]

You described the scenario perfectly.

We understand.

Though not the answer you wanted, the answer you got was correct. You can't. Not directly. (Well, technically, you can -- but you can or will also end up owning the security holes you might open if you choose to do that.)

The approaches suggested previously are the correct and appropriate approaches. Fix the code to allow it to operate from within a trusted environment.

Rather than viewing this as a problem in the customer's configuration and something to be worked around or turned off, I'd suggest viewing this case as an opportunity to review and to improve your code, and to improve the safety and reliability and security of your code.

As for options, you can change the Perl spawn code itself to set the "trusted" flag (and rebuild perl), you can switch to and use "restricted" in place of "captive", you can call into an image which spawns for you (and be very careful to avoid introducing a security hole to do this), or such. Or you can move the Perl code into another process context (and particularly into a context not marked as captive), such as into a batch job you might SUBMIT or a detached process (running LOGINOUT) that's under another username, or into a server process that the untrusted process can send along a request.

If you really want to enable the SPAWN mechanism without resetting the account flags to allow it -- an approach which is kind of like leaving the back door, the side door, and all the windows in the house open, while locking the front door -- then look at setting bit 6 in the SECURITY_POLICY system parameter. This bit opens up everything everywhere, so you can end up opening a security hole elsewhere. And potentially owning the holes you might open. I do not recommend this approach, and -- if I were the customer here -- do recognize you could lose substantial credibility for suggesting this approach "incautiously".

Trying to mix together trusted operations and untrusted operations into the same context is difficult at best. I'd suggest up-rating the existing code, rather than risking exposing your customer.

[Tan Yeok Joo]

Thanks for all the replies. You all are very helpful and I have my question answered.I guess the customer has several options now.

Upgrade the code and disable the SPAWN mechanism.

Convert all Perl scripts to C, still enable the SPAWN mechanism. ( I think most of the codes are in C)

Rebuild Perl, still enable the SPAWN mechanism. But this will affect the future maintenance of the Perl module.

[Hoff]

:::Rebuild Perl, still enable the SPAWN mechanism. But this will affect the future maintenance of the Perl module.:::

True. Maybe. Sort of. True, if you make your code changes and do not contribute them back to the Perl repository, or if you do contribute the changes back out and the changes aren't accepted.

If you make a clean set of code changes to add this and you contribute them back out, you can easily see your changes accepted back into the Perl source pool.

[Craig A Berry]

If you want use CLI$M_TRUSTED from Perl, the right way to do it is build an XS extension that makes the complete feature set of lib$spawn available in a Perl program. You might call it VMS::Spawn or similar. You could use one of the existing VMS-specific extensions as a guide (e.g., VMS::System wraps $getsyi, VMS::ICC wraps intra-cluster communication services APIs, etc.). Once you have a way to specify CLI$M_TRUSTED only when you want it, then do exactly that: only specify it when necessary.

The wrong way to do it would be to modify the lib$spawn call within the safe_popen routine in [.vms]vms.c in the Perl sources. That would make all pipes, backticks, and system() calls in every Perl program ignore the default account settings.

[Tan Yeok Joo]

Got it.
Cheers !!