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

[Johnny Billquist]

On 2020-10-13 14:58, Paul Koning wrote:
> 
> 
>> On Oct 12, 2020, at 9:44 PM, Robert Armstrong <bob at jfcl.com> wrote:
>>
>>> 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.
> 
> 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.

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.

>>   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.

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.

>>   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.

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