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

[Tad Winters]

On 5/12/2021 9:14 PM, Simon Clubley via Info-vax wrote:
> On 2021-05-12, Tad Winters <tad.vms at gmx.com> wrote:
>> On 5/12/2021 5:10 AM, Simon Clubley via Info-vax wrote:
>>> On 2021-05-11, Dave Froble <davef at tsoft-inc.com> wrote:
>>>> On 5/11/2021 10:44 AM, Stephen Hoffman wrote:
>>>>>
>>>>> It's a way of directly activating hunks of a captive environment that
>>>>> might not be accessible directly.
>>>>
>>>> Only if those "hunks" exist.
>>>>
>>>
>>> As I have already mentioned, someone can also copy a command procedure
>>> of their choosing to the captive account using FAL and then execute the
>>> command procedure using one of the two methods.
>>>
>>> Simon.
>>>
>>
>> If you don't want that, set the ownership/protection on the command
>> procedure so that it cannot be overwritten.
>>
>
> But the attacker gets to create a filename of their own choosing.
> They don't have to replace an existing command procedure because
> both methods work on the attacker-chosen name, not an existing filename.
>
> 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.
>
>> Certainly you don't expect FAL to be implemented to determine if the
>> target file is a command procedure used as part of the potential group
>> of command procedures called from a CAPTIVE account, do you?
>>
>
> No way. :-)
>
> The real problem I have is with the active features of DECnet and that
> they are enabled by default for captive accounts. To me, that violates
> the principle of least astonishment:
>
> https://en.wikipedia.org/wiki/Principle_of_least_astonishment
>
> and VMS is supposed to be built around that principle.
>
> What I would like to see is for FAL to go back to being the passive
> data access mechanism by default that the specification says it should be.
>
> I would also like to see the active features of DECnet (ie: task-to-task
> communications) disabled by default for captive accounts until explicitly
> enabled by the system manager.
>
> If you protect the login command procedures sufficiently (along with
> any associated data files) then the worst that can happen then if you
> don't have things sufficiently locked down is that someone can write
> passive junk into the captive account directory.
>
> Network protocols need to be tightened up over time as new issues
> are discovered. This happens to TCP/IP and it should happen to DECnet
> as well. Just because something was once acceptable, does not mean it
> is acceptable today.
>
> Simon.
>

So you're saying that you want _one_ flag on a user account to not only
restrict interactive access to the defined login command procedure, but
to actually allow no other kinds of access?  Perhaps the setting of that
flag should implicitly mark the account with /NOBATCH /NONETWORK
/NOREMOTE.  Maybe you'd also like to use /PWDMINIMUM=30?  Should
AUTHORIZE confirm the login command procedure exists and then SET
SECURITY/CLASS=FILE/PROTECTION=(WORLD) {the command procedure filename}?

Maybe AUTHORIZE should audit the content of the login command procedure
to make sure it will work as you intend.  It will then also need to
translate SYS$SYLOGIN and audit that command procedure as well.

What else do you need it to do?