[HECnet] How much should you be allowed to shoot yourself in the foot?

[Paul Koning]

> On Oct 12, 2020, at 5:41 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
> ...
> If you're winning enough to defeat these restrictions, then maybe you're winning enough to understand the ramifications of doing them.
> 
> Comments for other DEC OS's?  I don't remember what RSTS, RSX and VMS do.

The security (privilege) model in RSTS comes in two flavors, depending on whether you're looking at V9.0 and later, or the versions before it.  (Here I mean V4 through V8; I have no real experience with V3 and earlier, though I do know its suite of syscalls is drastically different from what came in V4 and carried forward pretty much from there.)

In V8 and before, privilege was pretty much an all or nothing parameter.  A person logged into any [1,*] PPN is privileged, a person logged into any other PPN is not.  The only special case is that in V5 through V8, the "write kernel memory" syscall is available only to users in [1,1].

Also in those releases, there is a concept of "privileged program" (like "setuid" program in Unix).  A program with the 128 bit set in its protection code is privileged; when executing it can do all the things that normally only [1,*] users can.  Program privilege doesn't grant the right to "poke memory" in V5 or later.  Setting the privilege bit is of course itself a privileged operation.  Privilege can be dropped, either temporarily or permanently.

Finally, a program running in a logged out job is privileged by definition; this is how LOGIN can do its thing.

In V9, inspired by the VMS security model, I replaced most of this by a "multiple privileges" scheme. Now a PPN has an attribute set in its security parameters that is the privilege bitmask.  There are plenty of them, many similar to what's in VMS though some different.  For example, there are flags to bypass read and write protection (separately) for any file the group, and another set of flags to bypass these for any file anywhere.  There is a flag to enable memory reading; another to enable memory writing and non-file-structured disk writing.  And so on.  A conversion program would convert old system disks to the new scheme, assigning the equivalent privileges from before.  But in V9, there are no longer special PPNs, so it's perfectly fine for [5,42] to be the all powerful sysop while [1,2] can do little or nothing.

I also created a mechanism to associate a privilege bitmask with an executable file, but that didn't ship.  Or maybe it shipped but wasn't a documented feature, I forgot.  It did work in testing.  The intent was to be able to fine tune what privileges a program might get.  In the end, the old scheme was kept, so a program with the 128 bit in its protection would get the "everything expect WRTMEM" mask.

For security when inter-process communication is used to request services, like file printing, the "send a message" function got a new option to include the job's current privilege mask.  And there is a new syscall that says "use this PPN and this privilege mask for permission checks (in addition to my own).  This allows the print spooler and things like it to obey the security rules very easily, with the kernel doing all the legwork.

	paul