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

[Simon Clubley]

On 2021-05-13, Mark Berryman <mark at theberrymans.com> wrote:
> On 5/13/21 11:58 AM, Simon Clubley wrote:
>> 
>> 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.
>
> Wrong.  I did not.  There was no denying network access whatsoever. 

Yes, you did Mark. You used the f$mode() technique followed by an
explicit logout and that's an outright blocker for the modes you
want to deny. I've used the same technique myself in the past for
the same reason.

>
> As has been stated before, you've obviously never been responsible for a 
> captive account.  Had you been, you likely would have already realized 
> that these issues get addressed.

You are wrong about that Mark. I have setup a number of captive accounts
in the past, including appropriate denials of mode access when required.

However, it's becoming obvious from reading this thread that my usage
cases for captive accounts in the past appears to be different from
what many others here are using them for.

>
> In *my* worldview, I don't put people ignorant of the system in charge 
> of the system.  However, if that is the only option available, I do 
> expect them to make use of available resources to learn the system 
> before making changes to it.
>

Do you give them time to learn that stuff ? If so, then good for you
(seriously). It's clear from various postings here over the years that
not everyone is as lucky as that.

>
> Are there any captive accounts that don't take user input?  If the 
> captive account is set up by someone with no idea of what they are doing 
> (i.e. they do take into account network, batch, etc.) then any attempt 
> to use FAL to talk to that account will result in FAL attempting to talk 
> to that user input, not its expected network object, and the FAL access 
> will fail.
>

That isn't what my experiments always revealed. I found cases where input
was prompted for and the input completed with an error, but the command
procedure fell through and the network mode session was maintained for FAL.

>> 
>> 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.
>
> I believe I have.  Show me where I haven't.
>

People make mistakes Mark, especially people under pressure by managers
to get something done quickly. 

Your argument is based around the fact that if people read all the
documentation and make the appropriate mental connections, they can
turn insecure defaults into a secure configuration.

That's not how it should work. There should be a limited secure
configuration by default and if you need to make it less secure
for some reason or need to enable active functionality, you are
_then_ forced to read the manuals to find out how to do that.

You should not be forced to read the manuals to find out how to turn
insecure defaults into secure ones.

In this very thread David has made the classic mistake of assuming that
it is safe to let a command procedure fall through because you will just
get logged out.

If _David_ can make that mistake even with all this documentation, then
what about the average person who doesn't have that level of knowledge ?

Simon.

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