I was finishing up with the Access Control Job (ACJ)
modifications for MINI-EXEC Access (SC%MEA
capability) when I got to thinking more about the console.
For 36 bit machines, there has been some historical inconsistency
about messages that come up on the console but only on the console
and nowhere else. Under Tops-20, one example was BUGINF
and BUGCHK messages, which you had
to be near the console to see. Enhancements were eventually made
to Tops-20 distribute these via Orion to all Galaxy operators,
which is a nice idea as it also puts them in them into the OPERATOR-SYSTEM-LOG in PS:<SPOOL>.
It's also essential in a cluster.
However, there are still those other pesky messages, which maybe
you need to do something about. One example is "DDMP
swap space low action", which can occur if
you happen to have a number of multi-section programs executing
and don't have enough swapping defined (I.E., you took the
defaults). You can wind up with a crashed machine if you don't
release some memory.
Under Tops-20, there is a program called CTYPEEK that uses the TLINK% JSYS to allow terminals to 'spy' on the console via one way links. For a number of reasons, I am uncomfortable with spying. You certainly need to spy when you are debugging protocols; I've used it for both the Extended Mode FTP server and Tops-20 Kermit. Think of it like a Tops-20-centric Wireshark without the formatting.
On the other hand, when you get too many people with SC%WHL or SC%OPR and too many 'personalities', you start to need accountability. In short, I'd rather have it logged someplace that somebody is spying. CTYPEEK is unusual because it's one of the few programs that MRC put on the PANDA distribution that has no source code immediately available. That is unfortunate because having a program—any program—that must run with SC%WHL or SC%OPR enabled with no source code has been bothering me.
Some sleuthing turned up an email that Kirk Lougheed posted to
Tops-20 Wizards in August 2nd, 1982 2316-PDT, nearly four decades
ago (!!). It was short enough that I did a complete rewrite,
getting some additional functionality. That actual list of
enhancements is as follows:
Some sample output:
28-Mar-2022 20:33:53 Console terminal (TTY5:) being monitored by SLOGIN, TTY46:, Job 11
% Console terminal (TTY5:) is already being monitored by you: SLOGIN, TTY45:, Job 10
20:23:19 USER [Console terminal (TTY5:) being monitored by SLOGIN, TTY21:, Batch Job 9]
20:23:19 USER % Will monitor a maximum of 18 Hours, 38 Minutes, 28 Seconds and 864 Milliseconds.
20:23:19 USER Monitoring will be discontinued on Sunday, March 13, 2022 4:01:48PM-EDT
Which is how I logged the EST to EDT transition (possibly the
last one!)
On 3/28/22 6:45 PM, Thomas DeBellis wrote:
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'