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

[Johnny Billquist]

The security model in RSX is very different.

Skip the rest if you don't want to know a lot of innards of RSX...

There are essentially three different domains of security.

1.
The first one is the terminal. A terminal have privilege, not a user. If 
a terminal have privilege, it can do the dangerous stuff. A terminal 
can, in a sense, arbitrarily gain privilege. It's just a terminal 
attribute like any other. Such as if you want wrapping at the right end 
of a line. However, of course, a non-privileged terminal do not have the 
privilege to turn on the privilege. But a privileged terminal can of 
course turn off the privilege. To re-enable it again would require 
someone at another terminal, with privilege, to turn it on on that 
terminal again. Programs that do dangerous things are usually checking 
against this terminal attribute to decide if it will be allowed or not. 
If not, you get some "nice" error message from tools that will not allow 
you to do stuff.

2.
The second privilege domain are programs. Programs can have privilege as 
well. Programs that have privilege are allowed to execute system calls 
that are considered dangerous or affecting others. Some system calls are 
allowed for all users when affecting themselves, but will be denied if 
attempted on other users/programs, unless the program have privilege. 
System calls that "fail" will give an appropriate error code returned if 
you don't have privilege. In addition, privileged programs can map in 
any part of the kernel into their address space, and switch to running 
in kernel mode, really dropping all safe guards. So then you can shoot 
yourself to Jupiter in an instance, if you aren't careful. No safety net...

A terminal without privilege cannot run an arbitrary program that is 
privileged. However, a program that have privileges, and which have 
already been installed in the system, can be run by anyone. So such 
programs have to check for themselves if the terminal is privileged, in 
order to decide what is allowed to do by the user (see first point above).

3.
Files, as well as common regions, are protected through the concept of 
owners, groups, and protection masks. You essentially have SYSTEM, 
OWNER, GROUP and WORLD. And for each one of these groups, you can have 
READ, WRITE, EXTEND and DELETE access.
OWNER, GROUP and WORLD should be pretty obvious, I think. However, 
SYSTEM is anyone with a group number of 10 or less. And these users 
always have the capability of changing the protection.



Finally, when logging in to an RSX system, the terminal is initially 
always privileged. But it is also "locked", so you can't give any 
commands. The login system will at a point check which group you are in, 
and if your group number is greater than 10, it will drop the privilege 
of the terminal, and this happens before the terminal gets released so 
you can give any commands.

So, in a sense, any user in group 10 or less, is a privileged user, 
because when they log in, they will have a privileged terminal, and they 
can always change protection of files they don't have access to. And 
they can run privileged programs, and unless those programs have some 
special dislike for you, you'll be able to use them to their full extent.

So there is no special attributes to users, no special users, no special 
groups that can be added or deleted. It's just based on your terminal, 
which normally gets based on your UIC when you log in.
The additional point is, if your terminal is privileged, you can change 
your UIC to whatever you want at any time. So you can become a user in 
whatever group you want. So, terminal privilege is pretty much enabling 
you to get access to everything else all the time.

And when the system starts up, the console terminal is logged in, and 
with privilege. So unless the startup script logs that terminal out, you 
already have access to everything from the start.

You could possibly sum things up that in RSX, if you have a privileged 
terminal, it's rather easy to shoot yourself in the foot, and there is 
very few safeguards if you write your own programs and decides you want 
to be creative...

   Johnny

On 2020-10-12 23:41, Thomas DeBellis wrote:
> I was updating some of MRC's late changes into my version of PANDA.  A 
> (very) few of these were not documented with a change number, so I had 
> been caught by surprise.  While doing this, I stumbled over some 
> defensive coding that he had put in to keep even an enabled WHEEL or 
> OPERATOR from doing something /Really/ /Bad/.
> 
> I got to wondering about this, which led me to think about the use of 
> the OPERATOR id, which is analogous to the [1,2] PPN under Tops-10 and 
> maybe having administrator rights under Windows, not as bad as root.
> 
> Tops-20, like most mainframe operating systems of the day, assumed a 
> trained operations staff (as in trained to "DON'T TOUCH") and a trained 
> systems programming staff.  However, this all-or-nothing approach 
> eventually became more granular with the implementation of SEMI-OPR 
> capability.  I had implemented this at Columbia several years earlier 
> with SC%LOP, or Little Operator capability (this was known colloquially 
> as l'opr.)  We had a number of training issues with our operators (some 
> of them literally could not read), so this allowed them to use Galaxy to 
> mount tapes and paper forms, but nothing more.  PANDA provides 
> administrator capability (SC%ADM) which allows a certain amount of file 
> system administration.
> 
> The PANDA access control job (ACJ) already puts certain restrictions on 
> OPERATOR, mainly in the area of login.  It occurred to me that the above 
> assumptions concerning training simply are not true in the current 
> hobbyist universe.  You can actually remove OPERATOR (SC%OPR) capability 
> from the OPERATOR id, which will break a rather large number of things.  
> As a matter of fact, you can delete the OPERATOR id entirely.  I'm not 
> sure you could complete boot up into an sensible state after that; I 
> guess you'd need to turn on debugging and go directly to KDDT to then 
> recreate the id by hand. That's training; maybe Monitor Internals level 
> training...
> 
> And of course, even trained individuals can do dumb things... (GUILTY!)  
> So I modified the ACJ further to implement the following policies on a 
> CRDIR% of OPERATOR:
> 
>  1. May not delete OPERATOR.
>  2. May not remove SC%OPR from OPERATOR.
>  3. May not set OPERATOR not login-able
>       * FILES-ONLY
>       * INVALID
>       * CHARGE-LIMITED
>  4. May not set OPERATOR FTP-ONLY (no way to get to the EXEC; the normal
>     time-sharing user interface)
>  5. May not set 'junk' (I.E., undocumented) bits in OPERATOR directory
>     protection word
>  6. May not set OPERATOR directory protection to allow world read, write
>     or connect
>  7. May not clear the OPERATOR password (set to NUL)
> 
> 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.
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol