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

[Simon Clubley]

On 2021-05-13, Dave Froble <davef at tsoft-inc.com> wrote:
> On 5/13/2021 1:58 PM, Simon Clubley wrote:
>> On 2021-05-13, Mark Berryman <mark at theberrymans.com> wrote:
>>> On 5/12/21 10:14 PM, Simon Clubley wrote:
>>>> .
>>>> .
>>>> .
>>>> The point is that if they have network access, they can copy over
>>>> a filename of their choosing to the captive account and then execute
>>>> that file while still in network access mode, without ever having
>>>> to go anywhere near an interactive login in order to execute the
>>>> command file they have just transferred.
>>>>
>>>
>>> As I believe I have effectively demonstrated, no they can't.  Why do you
>>> continue to exist they can?
>>>
>>
>> No you haven't Mark. There's no way in hell that you have even come
>> _close_ to demonstrating that.
>>
>> All you have been able to demonstrate is that someone with detailed
>> knowledge of VMS (ie: you) and the time to experiment has been able
>> to implement something that addresses my concerns, and only by outright
>> denying network access to the captive account.
>
> If a captive account needs network access, then something is very wrong 
> in the design of the apps and implementation.
>
>> Now what about the average system manager or someone who has been given
>> some VMS systems to manage along with other systems but is not a VMS expert ?
>
> Then they need to learn.  Do you turn loose a driver on the road without 
> any training, or testing?
>

VMS needs to be easier to manage in this day and age and to integrate
with the rest of the computing world or it is dead.

>> What if they fail to write the perfect captive command procedure which
>> falls through instead of doing an explicit logout ?
>
> If a captive user leaves the command procedure, the process is 
> terminated.  No need to logout.
>

You are wrong, wrong, wrong about that in network mode!!!

In network mode, the network session continues if the captive command
procedure falls through, at least in my tests on VMS 8.4 Alpha and
VAX/VMS 7.3.

If you ever see the captive account - interactive access denied message
while using the captive command procedure in interactive mode then your
captive command procedure is not correctly written.

>> What if they actually _do_ need to allow network access to the captive
>> account so files can be dropped into the account for later processing ?
>
> Oh, no!  Very poor app and installation design.  If such happens, it 
> needs to be tightly controlled.  No dumping data hither and yon.
>
>> In your worldview Mark, are these people solely responsible for any VMS
>> security issues simply because they didn't fully grasp the security
>> implications of some unknown to them concepts specific to VMS such as
>> task-to-task communications and remote batch submission ?
>>
>> Did they even think about these concepts in the first place because the
>> documentation wasn't explicit enough about pointing out the security
>> implications of this functionality ?
>>
>> In your worldview Mark, are they expected to read every single page
>> of the VMS documentation,
>
> If they don't, then why even write documentation?  That is a major 
> problem with the Microsoft world.
>

Bloody hell David, you are making my point for me a _lot_ better than
even I can. :-(

> If you don't know what you're doing,  then hire someone who does. 
> OLtherwise, you deserve whatever your cheap ass gets.
>
>> eventually find the bit about SUBMIT/REMOTE
>> and then magically connect that to the captive account they setup ?
>
> When a captive user account is set up, properly setting up the SYSUAF 
> record is part of that setup.
>
>> VMS should be secure by default and have multiple layers of protection
>> to help stop people from doing the wrong thing by mistake.
>
> Ship it without a power cord ....
>

Seriously, David, seriously ? :-(

>> This is why I am annoyed with Doug's dismissive response. At a technical
>> level, he is correct. At a practical level, he is wrong because DECnet
>> should have some better controls than it currently does, with active
>> functionality disabled especially for captive accounts until explicitly
>> enabled by the system manager for an account.
>>
>> So no Mark, you have not even come close to demonstrating that,
>> especially for systems which might be managed by people without the
>> level of knowledge that you have.
>>
>> Simon.
>>
>> PS: I wonder how many people have read my postings about this and
>> have then promptly gone off to check their captive account setups
>> in light of the active functionality I have highlighted ?
>>
>> I wonder how many of them promptly found issues which they have now fixed ?
>>
>> To those of you who did, you are welcome and I'm glad I could help.
>>
>

Simon.

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