Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Setting the SYSTEM a/c to DISUSER

 
John A. Beard
Regular Advisor

Setting the SYSTEM a/c to DISUSER

Question about the issues of setting the SYSTEM account to /DISUSER.

Our auditors are requesting that we modify the SYSTEM account with the /DISUSER flag set (they are concerned about possible external attacks, etc...too well known a username...)

We do have a number of alternate fully privileged accounts running under [10,*].My questions here is if we do disuser the SYSTEM account will that have any effect on areas such as booting the VMS boxes or any other non-site independant startup procedures. All our 3rd party products are started via alternate privileged accounts so I am not concerned about them at this point.

No doubt I have left a million and one things out of this scenario, but if there was a "show stopper" from the word go then that will suffice for the immediate future.

Thanks in advance...
Glacann fear críonna comhairle.
11 REPLIES 11
John Gillings
Honored Contributor

Re: Setting the SYSTEM a/c to DISUSER

John,

In general, I don't think this is a good idea. I'd expect the assumption that SYSTEM is not DISUSERed to be all over the place. In particular, it would seriously constrain your startup procedure, as you couldn't SUBMIT any jobs.

If the concern is external attacks, there are several defences, especially if you don't use the account for interactive logins. Start with a completely random, 32 character password that even you don't know. First line in LOGIN.COM:

$ IF F$MODE().EQS."INTERACTIVE" THEN LOGOUT

Maybe add UAF/INTERACTIVE and /NETWORK access restrictions. If the auditors trust the DISUSER bit in the UAF, they should also trust access restrictions.

If you want to go further, jack up LGI_HID_TIM from 5 minutes to a few hours. Then you can DELIBERATELY feed in login attempts with invalid passwords at regular intervals to keep SYSTEM in INTRUSION state. That way even if some external hacker manages to guess your 32 character random password, they STILL won't get as far as the LOGOUT command, but network and batch jobs will still work.

On the other hand, you could just try it and see what breaks ;-)

Check with HP. I think it's still recommended that patches be installed from SYSTEM, and it's possibly mandatory for OS upgrades (though that can be dealt with by temporarily enabling the account).

The big question you need to sort out with the auditors: does the (arguable) decreased risk from external penetration balance the increased risk and cost resulting from running a non-standard (and possibly unsupported) configuration?

(I've been in plenty of places with very high audit standards, and can't remember ever going as far as DISUSERing SYSTEM).
A crucible of informative mistakes
Hoff
Honored Contributor

Re: Setting the SYSTEM a/c to DISUSER

Your auditors have just proved themselves to be somewhere between ignorant and idiot; this'll disable your server.
Steve Reece_3
Trusted Contributor

Re: Setting the SYSTEM a/c to DISUSER

This was certainly possible, though not recommended, with v5.5-2 on VAX. I've not tested it on any other versions, whether VAX, Alpha or IA64.
All of the startup jobs that aren't run directly as part of the startup process will have to be submitted as a different user (one of your priv'ed accounts) and you'll have to test it to see what breaks. Most patches rely on being a privileged account, not the SYSTEM account.
Do bear in mind though that the SYSTEM account can still login on OPA0: even if it is disusered. Also bear in mind that disks need to be owned by someone and that's usually the SYSTEM account. You can get some odd results if a different account initializes a disk and you then remove that priv'ed account.
Steve
labadie_1
Honored Contributor

Re: Setting the SYSTEM a/c to DISUSER

I once worked at a site where in order to log in with the SYSTEM account, after having correctly entered the 2 passwords (generated by VMS, with at least 10 characters), you had to be authorized by somebody on OPA0:.
Yes, the SYSTEM account was a captive account :-)

Added to the setup offered by John Gillings, should this secure enough your site ?

Jan van den Ende
Honored Contributor

Re: Setting the SYSTEM a/c to DISUSER

John,

I completelely agree with Hoff.

Way back when (VMS 5.x; Vax) we got the same request. We complied, but at the next reboot we were in deep s**t!! It happened to by on my day-off, but eventually they tracked me and I had to drive up (ca 100KM!)
Only remedy was SYSBOOT, console-only change-back of SYSTEM account.

And thereafter trying to explain to noncompos auditors WHY we did undo what they requested... :-(

Save yourself the trouble: DO NOT DO THIS!!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.