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

[Simon Clubley]

On 2021-05-12, Dave Froble <davef at tsoft-inc.com> wrote:
> On 5/12/2021 1:34 PM, Simon Clubley wrote:
>> On 2021-05-12, Dave Froble <davef at tsoft-inc.com> wrote:
>>> On 5/12/2021 8:10 AM, Simon Clubley wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> Ok. who can create and copy the command procedure?
>>>
>>
>> Now you are just trolling David. However, just in case you really
>> are serious:
>
> I am very serious.
>
>> Anyone on the network with a DECnet client and an editor. The DECnet
>> client doesn't even have to be a VMS-based DECnet client.
>>
>>> If limiting activity to the captive account, just how does it get these
>>> command procedures, and how does it copy them?
>>>
>>
>> They are pushed to the captive account from across the network.
>> They are not pulled from the captive account.
>
> How does this happen, unless they have write access to the UIC of the 
> captive account?  If they have write access, then they are authorized to 
> do so.
>

Because they use FAL to login _as_ the captive account. They do not
log into FAL as themselves.

>> To stop this, you have to make absolutely 100% sure that network
>> mode access is blocked in the captive account. Apart from configuration
>> mistakes or omissions that might be made in this area, then for some
>> usage cases you simply cannot do that.
>
> Makes me wonder if you actually use VMS ...
>

I suspect you are in one of those moods of yours where you sometimes
pretend not to understand anything in order to mess with people...

>>> What you're assuming is that a user already has these authorized
>>> capabilities, and if so, then it is "authorized capabilities".
>>>
>>
>> Well, that's a load of nonsense David.
>
> No, that is exactly what we are discussing.
>
> Any user can only do what they are authorized to do.  They cannot access 
> any files they do not have access to.  They cannot place files in any 
> directory they do not have access to.
>

Captive accounts are unique in VMS in that the user gets access to
an account with elevated privileges that you would never give them
normally if they had free access to the account.

For that to work however, you need to block off _all_ possible methods
to stop them from executing commands with the privileges of the captive
account and with the current DECnet design, it's possible to for them
to still execute commands of their choosing if they can get logged in
via network mode instead of interactive mode.

As I have just told Tad, the real problem is the ability to execute
transferred command files while in network mode, not the ability to
transfer them in the first place (provided you have sufficiently
protected the existing files that are there).

>> A user may be authorised to do whatever they want in a non-privileged
>> account or on another non-critical machine on the network but they are
>> restricted to a specific workflow when using the captive account on the
>> target machine.
>>
>> That doesn't stop them from creating a command procedure with the commands
>> they would like to run (but are blocked from doing so in their authorised
>> accounts) and then copying it to the captive account where they can
>> actually execute those commands.
>
> If they do not have access, as in write privs, to the captive account, 
> they just how does that happen?
>

Because they login to FAL _as_ the captive account, not as themselves.

Simon.

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