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

[Simon Clubley]

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.

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

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.

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

Simon.

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