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

[Stephen Hoffman]

On 2021-05-10 22:13:53 +0000, Dave Froble said:

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

Today is a good day to consider alternatives to DECnet, too.

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

If the CAPTIVE user doesn't authenticate past the username, or has a 
known password or, you know, it's DECnet so anybody with an interest in 
the credentials probably already knows the credentials or should be 
assumed to know, so, access is available.

And the detail I'm going to have to ponder now—for those cases where 
DECnet is still lit—is whether some component of the CAPTIVE command 
procedure environment might be triggered out-of-band. And what might 
happen.

This when a CAPTIVE environment is built from multiple command procedures.

If the main procedure enforces access for invoking some "nested" 
command procedure, I hadn't given much consideration to that "nested" 
procedure being triggered (submitted) directly, rather than via the 
main procedure.

NONETWORK is probably goodness. NOOTHER (err, no detached jobs 
permitted) and NOBATCH may or may not be possible with some CAPTIVE 
procedures, absent privilege separation and inter-process 
communications with privileged server processes for those that use 
detached or batch jobs. Or, you know, maybe even actual process 
management and scheduling support.

> FAL is a very useful tool.

sftp, scp, and ssh, too.

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

It's a way of directly activating hunks of a captive environment that 
might not be accessible directly.

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

See above above directly accessing and submitting hunks of the CAPTIVE 
environment.

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

sftp and scp and ssh are very useful, too.

There are things I'd like to see with sfpd yes, but most of the time I 
can or do have a window open "over there" and have direct access.

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

Nah, it's pretty much on the app authors; on the developers. Who set up 
the CAPTIVE environments. Who increasingly either create the CAPTIVE 
usernames, or write the directions for the CAPTIVE user creation. App 
developers that are often focused elsewhere, and can sometimes miss or 
can ignore security issues. Hopefully the system managers catch these 
mistakes, but that still means some number of the developer's sites are 
potentially open to problems.

This ties back into my longstanding comments about making DECnet 
installation and configuration incrementally more involved too; of 
explicitly flagging the risks to the app developers and system 
management folks; of defaulting to secure installs.

You want or need to use DECnet, telnet, FTP or ilk, you get a few added 
steps to install and configure and start those, and the manager or the 
developer gets to acknowledge and read and override the warnings.

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

If DECnet is in use today—outside of a museum or a hobbyist—it's a 
target for attack today, and it gets judged by today, and not by then.



-- 
Pure Personal Opinion | HoffmanLabs LLC