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

[Paul Koning]

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

>  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