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

[Dave Froble]

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?

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

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

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

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


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