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

[Dave Froble]

On 5/11/2021 9:08 AM, Simon Clubley wrote:
> On 2021-05-10, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 5/10/2021 2:20 PM, Simon Clubley wrote:
>>> 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 it's an interactive account where you can get to the DCL prompt, then
> nothing. If it's a captive account, then a lot.

Access to the remote system is defined by system manager(s).  If 
allowed, then no problem.  If not allowed, then no user account, and 
again no problem.

>> 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.
>>
>
> You have completely and totally missed the whole point of my original posting.

I did not miss your point.  What you have decided to ignore is the 
requirement for system management of user access.  VMS of 30+ years ago 
requires system management.  It does not assume automatic security.  Do 
remember, the distribution shipped with the password of the SYSTEM user 
account as MANAGER.  No problem, if the system access was managed.  Yes, 
a problem, if such access was not properly managed.

> Due to unexpected functionality, if you can get to the captive account
> via a network login, you can directly execute any DCL commands you choose
> regardless of whatever the login command procedure does in terms of
> interactive user input when you login from a terminal session.

Not "unexpected functionality".

A captive user, unless set up to do so, cannot create any command files. 
  So no choices available.

>>> 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 about totally missing the point I was making.
>
>>> 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.
>>
>
> Then you have missed the point of what I am saying.
>
>>> 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.
>>
>
> Fact, if you change "transfer" to "access" in my wording. It's in the
> FAL specification that a FAL implementation should only implement passive
> data access and not do anything active such as remote job entry.

You have chosen to ignore the fact that setting up of the captive user 
capabilities either controls all issues, or, it might as well not have 
been a captive user account.


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