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

[Mark Berryman]

On 5/13/21 11:58 AM, 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.

Wrong.  I did not.  There was no denying network access whatsoever. 
Take a look at the posting again.  There was also no experimenting.  I 
simply setup a captive login procedure with two lines in it and then 
tried to access that account via FAL.  It failed.

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

That is what the manuals are for.  You've assumed that captive accounts 
tend to be privileged, which is not a valid assumption.  Setting up an 
account with elevated access without reading the documentation is just 
asking for trouble, regardless of the situation or the OS.  (See most 
Windows systems).

However, I think you will find that most captive accounts are setup so 
that users need not learn the command line.  They are given a nice menu 
to do their work and they don't need to worry about how it is done.

> 
> What if they fail to write the perfect captive command procedure which
> falls through instead of doing an explicit logout ?

It such a case, the users get this error message:
%DCL-E-CAPTINT, captive account - interactive access denied

Along with a security audit.

Rather than constantly addressing the questions asked about that, the 
logout gets added (yes, this is based on the input of multiple system 
managers).

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

That happens.  *In every single case* where I have seen this done, the 
files were dropped into a "dropbox" directory and did not use the 
captive account directly, regardless of the skill level of the person 
setting up the system.

In fact, every captive account I have seen (and I have seen many) 
disallows inbound network access - again, regardless of the skill level 
of the system manager.  So maybe, regardless of the fact that this is 
new to you, it is not a surprise to anyone else (at least, not to anyone 
involved enough in a VMS system to be setting up a captive account).

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.
> 
> 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, eventually find the bit about SUBMIT/REMOTE
> and then magically connect that to the captive account they setup ?

Well, let's see.  Way back when I was responsible for setting up some 
captive accounts I was fairly new to VMS myself.  I hadn't read all of 
the VMS docs but I did make use of them for reference.

I was fully aware of submit/remote because it is clearly spelled out in 
"DECnet for OpenVMS Guide to Networking".  I was also aware of task to 
task capabilities because it is also clearly spelled out in the same manual.

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.

As I said, I was once "ignorant of the system" myself.  And yet, 
somehow, none of my captive accounts were susceptible to the issue at 
point here.

Let me be pointed.

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.

If the captive account is set up to do some work and then quit without 
ever getting any user input, then that account will do a logout (if for 
no other reason than to prevent an error message and a security audit 
every time it is used).

So, in what circumstance do you find this to be a genuine concern.
> 
> VMS should be secure by default and have multiple layers of protection
> to help stop people from doing the wrong thing by mistake.

You are welcome to resurrect SEVMS and find a way to make it viable 
enough to be maintained moving forward.  However, you will probably find 
there are reasons that what you are asking for pretty much died on the vine.

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

I believe I have.  Show me where I haven't.

Mark