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

[Simon Clubley]

I have come across some very unexpected DECnet Phase IV functionality
while I was looking at the FAL specification.

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.

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 ?

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.

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.

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.

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.

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.

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.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.