I've had some time to read all the comments and digest them.
This was extremely informative; all of it.
Because the KL architecture implies a separate front end, that front end itself must be secured. If you can get into RSX20F or its equivalent (meaning the parser for KLH10 or SIMH), then the party is really over. So this implies passwording the front-end, and maybe that's not a great idea. Ditto if you have an operative switch register; that would need to be disabled and maybe that's not possible or worse maybe it's a downright terrible idea.
On the other hand, once you have the system all nicely configured, you really don't want somebody bumping into something and getting you into a situation where you have to do a recovery. Now unfortunately, as a hobbyist, that most likely somebody is…me‼️
Yet, this was also historically true. We wrote a lot of
defensive code to keep the requirement to have WHEEL (SC%WHL) or OPERATOR (SC%OPR)
capabilities to an absolute minimum and some amount of code to
keep somebody with these capabilities from blowing something
away. Most of the time we all ran with capabilities off (which I
still do) to challenge ourselves to implement functionality that
didn't require access to everything. This was the reason for
SEMI-OPERATOR (for Galaxy access, we called it LOPR for Little
Operator or l'opr).
When I looked at the MINI-EXEC, I realized that the only 'dangerous' thing in there was the "/" (forward slash) command, which puts you into MDDT (monitor DDT). Yeah, we don't want to be bumping into that...
Otherwise, after the initial system build, the only thing that
the MINI-EXEC is used for is debugging top-level EXEC problems.
There is nothing about DDT'ing the EXEC that should need WHEEL, so
requiring it is complete overkill. Therefore, like LOPR (SEMI-OPERATOR), I have defined
another capability called SC%MEA,
for Mini-Exec Access. If you have an EXEC
developer, then you just give him/her/it SC%MEA
and that's really all you need.
I enhanced the ACJ to check for both SC%MEA and SC%WHL and reject if the top-level fork does not have at least one of these and have it enabled. A not-logged-in job is rejected in all cases, no exceptions.
The CTY still remains somewhat special. If you are running on
the CTY, then all that is necessary is to have either SC%WHL or SC%MEA,
but not necessarily enabled. This is to handle the case of an
EXEC that blows up early in the login process so that debugging is
possible (or to replace the EXEC). This is similar to GETAB%/SYSGT% (SC%GTB)
capability (which is what you need for SYSTAT
to work). All that is necessary is to possess it; it need not be
enabled.
This is obviously not a 'cure', but rather more of a preventive
measure; I don't see that there can be a 'last word' on the
subject.
On Mar 7, 2022, at 3:56 PM, Thomas DeBellis <tommytimesharing@gmail.com>
What about other DEC multi-user operating systems? Do you have 'magic'