12 Oct
2020
12 Oct
'20
11:41 p.m.
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.
13 Oct
13 Oct
12:56 a.m.
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
3:22 a.m.
VMS has a fine grained privilege system - I haven't counted recently, but I'll
bet there are close to 32 individual privileges that can be enabled or disabled at will.
Processes have both an "authorized privileges" and an "enabled
privileges" mask, so an account can have many privileges authorized but a user can
selectively turn them on or off at will. Programs (really installed images, but
that's an executable program for this discussion) also have a privilege mask and when
a user runs one of these the image privileges are ORed with the process privileges.
I'm not aware that specific privileges can be associated with specific terminals, but
you can restrict accounts to only log in on local (hardwired) terminals, batch jobs, PTYs,
network terminals, or even on the CTY only.
There's also an elaborate system of ACLs for files, but that's a different
story.
One VMS privilege bit that I really like is "READALL" - this says that the
process can have read access to any file on the system, regardless of protections. The
process doesn't, however, get any special dispensation for modifying or deleting the
file (there are other privilege bits for that!). Having read access to everything without
having to worry about accidentally screwing something up is really handy.
Bob
3:25 a.m.
Actually, I seem to remember last time I looked (quite a number of years
ago), there were 36 different privileges in VMS. Definitely more than 32
in any case. But yes, that is a rather nice part in VMS. And you can
assign such rights both to users and programs.
Johnny
On 2020-10-13 03:22, Robert Armstrong wrote:
VMS has a fine grained privilege system - I
haven't counted recently, but I'll bet there are close to 32 individual privileges
that can be enabled or disabled at will. Processes have both an "authorized
privileges" and an "enabled privileges" mask, so an account can have many
privileges authorized but a user can selectively turn them on or off at will. Programs
(really installed images, but that's an executable program for this discussion) also
have a privilege mask and when a user runs one of these the image privileges are ORed with
the process privileges. I'm not aware that specific privileges can be associated with
specific terminals, but you can restrict accounts to only log in on local (hardwired)
terminals, batch jobs, PTYs, network terminals, or even on the CTY only.
There's also an elaborate system of ACLs for files, but that's a different
story.
One VMS privilege bit that I really like is "READALL" - this says that the
process can have read access to any file on the system, regardless of protections. The
process doesn't, however, get any special dispensation for modifying or deleting the
file (there are other privilege bits for that!). Having read access to everything without
having to worry about accidentally screwing something up is really handy.
Bob
--
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
3:32 a.m.
So if you can read sysuaf.dat.......
----- Original Message -----
From: "bqt" <bqt at softjar.se>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Monday, October 12, 2020 9:25:05 PM
Subject: Re: [HECnet] How much should you be allowed to shoot yourself in the foot?
Actually, I seem to remember last time I looked (quite a number of years
ago), there were 36 different privileges in VMS. Definitely more than 32
in any case. But yes, that is a rather nice part in VMS. And you can
assign such rights both to users and programs.
Johnny
On 2020-10-13 03:22, Robert Armstrong wrote:
VMS has a fine grained privilege system - I
haven't counted recently, but I'll bet there are close to 32 individual privileges
that can be enabled or disabled at will. Processes have both an "authorized
privileges" and an "enabled privileges" mask, so an account can have many
privileges authorized but a user can selectively turn them on or off at will. Programs
(really installed images, but that's an executable program for this discussion) also
have a privilege mask and when a user runs one of these the image privileges are ORed with
the process privileges. I'm not aware that specific privileges can be associated with
specific terminals, but you can restrict accounts to only log in on local (hardwired)
terminals, batch jobs, PTYs, network terminals, or even on the CTY only.
There's also an elaborate system of ACLs for files, but that's a different
story.
One VMS privilege bit that I really like is "READALL" - this says that the
process can have read access to any file on the system, regardless of protections. The
process doesn't, however, get any special dispensation for modifying or deleting the
file (there are other privilege bits for that!). Having read access to everything without
having to worry about accidentally screwing something up is really handy.
Bob
--
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
3:44 a.m.
Peter Lothberg <roll at stupi.com> wrote:
So if you can read sysuaf.dat.......
VMS has "one way" password encryption (like Un*x) so you can't get an
account's password by reading the SYSUAF file (well, OK you can guess it, but only by
very brute force). So you could figure out which accounts were privileged, but it
wouldn't automatically give you access to those accounts.
FWIW, the VMS manuals had a table of privilege bits that, if granted to a user, in
theory gave that user the ability to gain any other privilege. Some were obvious, like
SETPRIV (which literally meant "this process can set any privilege bit it wants,
regardless of authorization") but others were more subtle. For example, CMKRNL
(change mode to kernel) would allow a clever enough user to write a program accessed any
memory location anywhere, and from there the user could theoretically change the privilege
mask for his process. There were actually quite a few privileges which could be leveraged
into any privilege.
Also, on VMS network (DECnet network, of course) is a privilege. This one is enabled by
default for new accounts, but you can deny a user network access if you want.
Bob
2:58 p.m.
On Oct 12, 2020, at 9:44 PM, Robert Armstrong <bob
at jfcl.com> wrote:
RSTS used to have plain text passwords (in RAD50, so case insensitive and limited to 6
alphanumerics. That changed in V8 with its new file structure, which also added
"account attributes". One of them is a hashed password, 14 ASCII characters run
through a one way hash function constructed from a slightly modified DES. The
"slightly modified" was so you couldn't use a DES chip as a search engine.
Peter Lothberg <roll at stupi.com> wrote:
So if you can read sysuaf.dat.......
VMS has "one way" password encryption (like Un*x) so you can't get an
account's password by reading the SYSUAF file (well, OK you can guess it, but only by
very brute force). So you could figure out which accounts were privileged, but it
wouldn't automatically give you access to those accounts. FWIW, the VMS manuals had a table of privilege bits
that, if granted to a user, in theory gave that user the ability to gain any other
privilege. Some were obvious, like SETPRIV (which literally meant "this process can
set any privilege bit it wants, regardless of authorization") but others were more
subtle. For example, CMKRNL (change mode to kernel) would allow a clever enough user to
write a program accessed any memory location anywhere, and from there the user could
theoretically change the privilege mask for his process. There were actually quite a few
privileges which could be leveraged into any privilege.
That's a good notion, we didn't think of that in RSTS. It doesn't have
SETPRIV. The only way I can think of to get any privs without being officially issued
them is if you have the "SYSMOD" privilege, which enables and memory writes, or
WRTNFS, which enables non-file-structured disk writes.
Also, on VMS network (DECnet network, of course) is a
privilege. This one is enabled by default for new accounts, but you can deny a user
network access if you want.
In RSTS, it isn't a privilege but rather a quota (for "message receive
blocks" which are somewhat like Unix sockets). If your quota for those is 0 you
can't do networking. There are also login terminal flags that control (a) any
interactive login, (b) any login on a dialup line (modem controlled line) and (c) login
via DECnet. So it's possible to set up an account that can't be accessed via SET
HOST.
paul
4:01 p.m.
On 2020-10-13 14:58, Paul Koning wrote:
RSX in old times had plain text passwords in ASCII. That was changed in
the early 80s I think (for RSX-11M-PLUS only) to one way encrypted via
the Purdy hash. Same as VMS, I believe. 64 bit polynomial, one way hashing.
Passwords are max 39 characters.
In 11M, it's still plain text, max 8 characters.
There is a sortof unofficial discussion going on from time to time about
what is the "lowest" privilege one can have in VMS, which actually can
be used to elevate yourself to everything.
It's an interesting topic, and I think the list is surprisingly long, as
to which privileges are sufficient to actually elevate you all the way.
I thought the message receive blocks were only used for interprocess
communication, and not for anything DECnet related. But then again,
DECnet under RSTS/E is not something I ever was exposed to.
As for allowing logins from different sources, that exists in RSX as
well as VMS as well. VMS even have these things about which hours you
are allowed to log in on different days. But this is drifting about from
shooting yourself in the foot to more generic security features of the OS.
Johnny
--
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
On Oct 12, 2020, at 9:44 PM, Robert Armstrong
<bob at jfcl.com> wrote:
RSTS used to have plain text passwords (in RAD50, so case insensitive and limited to 6
alphanumerics. That changed in V8 with its new file structure, which also added
"account attributes". One of them is a hashed password, 14 ASCII characters run
through a one way hash function constructed from a slightly modified DES. The
"slightly modified" was so you couldn't use a DES chip as a search engine.
Peter Lothberg <roll at stupi.com> wrote:
So if you can read sysuaf.dat.......
VMS has "one way" password encryption (like Un*x) so you can't get an
account's password by reading the SYSUAF file (well, OK you can guess it, but only by
very brute force). So you could figure out which accounts were privileged, but it
wouldn't automatically give you access to those accounts. FWIW, the
VMS manuals had a table of privilege bits that, if granted to a user, in theory gave that
user the ability to gain any other privilege. Some were obvious, like SETPRIV (which
literally meant "this process can set any privilege bit it wants, regardless of
authorization") but others were more subtle. For example, CMKRNL (change mode to
kernel) would allow a clever enough user to write a program accessed any memory location
anywhere, and from there the user could theoretically change the privilege mask for his
process. There were actually quite a few privileges which could be leveraged into any
privilege.
That's a good notion, we didn't think of that in RSTS. It doesn't have
SETPRIV. The only way I can think of to get any privs without being officially issued
them is if you have the "SYSMOD" privilege, which enables and memory writes, or
WRTNFS, which enables non-file-structured disk writes. Also, on VMS
network (DECnet network, of course) is a privilege. This one is enabled by default for
new accounts, but you can deny a user network access if you want.
In RSTS, it isn't a privilege but rather a quota (for "message receive
blocks" which are somewhat like Unix sockets). If your quota for those is 0 you
can't do networking. There are also login terminal flags that control (a) any
interactive login, (b) any login on a dialup line (modem controlled line) and (c) login
via DECnet. So it's possible to set up an account that can't be accessed via SET
HOST.
4:03 p.m.
On 2020-10-13 16:01, Johnny Billquist wrote:
On 2020-10-13 14:58, Paul Koning wrote:
RSX in old times had plain text passwords in ASCII. That was changed in
the early 80s I think (for RSX-11M-PLUS only) to one way encrypted via
the Purdy hash. Same as VMS, I believe. 64 bit polynomial, one way hashing.
Passwords are max 39 characters.
I should have added
https://en.wikipedia.org/wiki/George_B._Purdy#Purdy_polynomial
Johnny
--
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
On Oct 12, 2020, at 9:44 PM, Robert Armstrong
<bob at jfcl.com> wrote:
RSTS used to have plain text passwords (in RAD50, so case insensitive
and limited to 6 alphanumerics.? That changed in V8 with its new file
structure, which also added "account attributes".? One of them is a
hashed password, 14 ASCII characters run through a one way hash
function constructed from a slightly modified DES.? The "slightly
modified" was so you couldn't use a DES chip as a search engine. Peter Lothberg <roll at stupi.com> wrote:
So if you can read sysuaf.dat.......
? VMS has "one way" password encryption (like Un*x) so you can't get
an account's password by reading the SYSUAF file (well, OK you can
guess it, but only by very brute force).? So you could figure out
which accounts were privileged, but it wouldn't automatically give
you access to those accounts.
4:19 p.m.
On Oct 13, 2020, at 10:01 AM, Johnny Billquist <bqt
at softjar.se> wrote:
I thought the message receive blocks were only used for interprocess communication, and
not for anything DECnet related. But then again, DECnet under RSTS/E is not something I
ever was exposed to.
No, DECnet uses an extension of the IPC feature. A receive block allows you do to either,
subject to quotas. Local messages and the various DECnet messages are all queued to the
receive block, with a type code indicating what sort of message it is.
The "with privilege mask" message I mentioned is a variation on the local IPC
message, with a distinct function code and a portion of the payload dedicated to the masks
and PPN. Those fields are all set by the kernel, so the receiving program can use and
trust those values.
paul
...
In RSTS, it isn't a privilege but rather a quota (for "message receive
blocks" which are somewhat like Unix sockets). If your quota for those is 0 you
can't do networking. There are also login terminal flags that control (a) any
interactive login, (b) any login on a dialup line (modem controlled line) and (c) login
via DECnet. So it's possible to set up an account that can't be accessed via SET
HOST.
2:13 a.m.
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
1501
days inactive
1502
days old
10 comments
5 participants
participants (5)
-
bob＠jfcl.com -
bqt＠softjar.se -
paulkoning＠comcast.net -
roll＠stupi.com -
tommytimesharing＠gmail.com