[Info-vax] Unexpected DECnet Phase IV functionality with possible captive account implications

[Dave Froble]

On 5/10/2021 2:20 PM, Simon Clubley wrote:
> I have come across some very unexpected DECnet Phase IV functionality
> while I was looking at the FAL specification.

DECnet IV is rather old, but has been useful for a long time.

> Did you know that you can directly submit batch jobs using FAL from
> across the network without having to go anywhere near a command prompt
> on the target system ? The command procedure runs on SYS$BATCH on
> the target system as the user you have logged into with FAL on the
> target system.

Ok, what is the problem with this?  One still has to be a valid user on 
the remote system.  What's the difference between logging onto the 
remote system and submitting the job?

FAL is a very useful tool.

> Did you also know that this functionality works just fine with captive
> accounts so you can transfer a command procedure containing commands
> of your choice to a captive account using FAL (assuming network access
> is not explicitly blocked) and then submit it for execution ?

If you are logged into a captive account, you can only do what the 
command file for the captive account is set up to do.  I'd guess any 
issues would lie in the domain of the people setting up the captive 
account command file, not DECnet.

> The other major surprise I had was that task-to-task communications
> works just fine (assuming once again network access is not explicitly
> blocked) when the target is a command procedure in a captive account,
> so you can transfer a command procedure using FAL and execute it in
> that way as well.

See above about captive account command procedure.

> Also note that if your login command procedure for the captive account
> is poorly written so that it falls through without doing an explicit
> logout (IOW, if you get the captive account - interactive access denied
> message when the login command procedure has finished) then you can
> get into network mode in that way as well if you don't do an explicit
> check for network mode.
>
> I spoke to VSI about this before posting this because of the possible
> security implications but they don't see a problem with this. I disagree.

I do not see a problem.

> FAL is supposed to be a data transfer mechanism only and even the
> 40-year-old FAL specification states that a FAL implementation should
> not be used for anything other than just transferring files.

Opinion or fact?  FAL is very useful.  FAL can be used for accessing 
files, not just transferring files.

> Task-to-task communications should also be disabled by default for
> captive accounts IMHO. There should be some setting somewhere that
> you need to turn on explicitly for captive accounts if you want the
> active features of DECnet such as remote batch job submission and
> task-to-task communications.

That is the responsibility of the system manager.

> VMS was sold as being secure out of the box and that you have to know
> enough about VMS to make it insecure. You shouldn't have to work the
> other way around and start pulling bits of clues from the documentation
> about how to make potentially insecure settings secure.

VMS is not shipped with any captive accounts set up.

> I only found out about this when I came across the comments in the
> FAL specification about the supposedly obsolete batch submission
> capability and I started looking closer. I wonder how many other
> people don't know about this.
>
> And finally, a question: Assume that your captive account needs network
> access because it is a dropbox style account where files are transferred
> to it over the network with FAL and then the user logs into the captive
> account from a terminal session to review and then process the files.
>
> How would you setup the captive account so that the passive features
> of DECnet would work (such as file transfer using FAL) but the active
> features (remote batch job submission and task-to-task communications)
> would be disabled, but ideally only disabled for that captive account ?
>
> Simon.
>

Bottom line, DECnet IV was implemented in an earlier time, to solve 
problems from that time.  Yes, no encryption, no concerns about security 
as it's practiced (if at all) today.  Judge it on then, not now.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486