13 Oct
2020
13 Oct
'20
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.