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

[Dave Froble]

On 5/11/2021 10:44 AM, Stephen Hoffman wrote:
> 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.

For some things, yes.  Some capabilities exist only in DECnet.

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

I do not do that.

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

Which of them allow:

Open "DFE90A::[DFE]DATA.DAT" For Input as File #1%

Assuming proxys are set appropriately.

Please don't reply with:

Open "DFE90A"DFE XXX"::[DFE]DATA.DAT" For Input as File #1%

If I even remember how to do that correctly ...

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

Only if those "hunks" exist.

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

As do I ...

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

Not this app author ...

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

I can agree with this.  No bother at all.  Doing so might also cause 
system management to evaluate how DECnet can be used.

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

Judged for use today, yes, the original development should not be judged 
by today, unless a time machine was available to the developers.


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