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

[Stephen Hoffman]

On 2021-05-10 18:20:15 +0000, Simon Clubley said:

> 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.

See the SUBMIT /REMOTE command.

> 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 accounts have to be marked NOBATCH or NONETWORK or NOOTHER, or that 
access otherwise blocked by the DCL procedures.

> 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.

If the DCL is present to and readable by the captive user, it can be 
involved, yes.  Best to use execute-only access, though I'd not presume 
that to be entirely secure either.

> 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.

Problems with error-handling doom a whole lot of software.

> 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.

Captive doesn't get to write anywhere outside of very targeted 
directories, and then only with constraints. See below for more on the 
constraints.

> 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.

ssh has a similar mess waiting, here. That requires added configuration 
work to disable sftp.

If the account is an FTP or SFTP or FAL drop-box, it CANNOT be allowed 
to set the filename, and the processing MUST move the file away from 
the dropbox directory, and the user CANNOT be allowed to access the 
uploaded file absent additional processing.  (q.v. gifar, for a very 
old example of this mess. Writing a secure dropbox app is not trivial.)

> 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 ?

I don't let folks log into the server if I can avoid it.  If I can't 
avoid that, then the login is locked down, with ACLs to keep access 
further constrained, and subsystem identifiers to constrain what the 
captive user can access. This is a form of home-grown sand-boxing, 
which isn't all that effective, and isn't all that well documented.

Credential-based and proxy-based DECnet logins and FTP logins are not 
something I'd rely upon to remain secure, either.

And there's a reason I keep writing comments about the problems of 
continued use of DECnet...



-- 
Pure Personal Opinion | HoffmanLabs LLC