Living a Privileged 3000 Life without SM
April 5, 2013
By Brian Edminster
After reading the article on the safe and prudent use of privileges from yesterday, the subject touched a nerve with me. I've seen too many HP 3000 sites which have SM (or PM) capabilities assigned to production account users. They don't need it, and it adds risk and insecurity to a 3000. Along the same lines of error, PM is granted on insufficiently secured groups where production programs reside.
That first mistake is usually an instance of using a sledgehammer to kill a fly, usually due to laziness or ignorance. But the latter is a sign of careless security, or ignorance. The misuse of MPE/iX privileges is often triggered because application programmers are too lazy (or ignorant) of ways to properly design their applications. They could use the incredibly powerful and finely granular security provisions that MPE/iX allows to avoid this.
At the least, they could instead have used a lockworded copy of what is commonly known in the 3000 community as the 'GOD' program. This lets the manager who invokes it temporarily gain 'SM' -- much like the 'su' (superuser) command in your favorite flavor of Unix does. If something with finer granularity is needed, perhaps this is an opportunity for someone to port at least the concept of 'sudo' to MPE/iX.
Sudo is a Unix tool that is designed to allow specific non-super-users restricted (and optionally logged) access to commands that normally require 'su'. In MPE/iX parlance, it's a way to allow specific users restricted and logged access to commands requiring more than regular 'vanilla' user capabilities. My take on this is that proper use of MPE/iX's privileges would make a "SuDo/iX" unnecessary, but your mileage may vary.
You might ask, what's the harm of allowing SM to an application user who is normally 'captive' within a logon, no-break UDC that forces the user into the application, and logs them off on exit? How about the admin (who shall remain nameless, even though they're retired now) that accidentally did a 'Purge @[email protected]@;Yes' -- except they were thinking they were logged into a test server, not one of the production machines.
And as for regularly changing passwords to application databases, auditors are usually talking about "user application access" passwords. From a best practices perspective, these shouldn't be the actual database passwords, but rather should be values stored in a table of authorized application users and their respective privileges.
That said, if you find yourself with a need to regularly change the physical database passwords, put that call to the DBOPEN routine (or retrieval of the password to be used for it) into a XL library. That means recompiling the library, not the application, when the passwords have to change.
And lastly, if your system has to be that tight, you probably shouldn't store user application passwords in clear-text in the database, either. Instead, apply a one-way hash to the value when it's initially stored. Then, any time a user supplies their password, it's run through that hash again and compared with the stored value. If they match, the passwords match.
The folks at Beechglen have a callable 'MD5' hash routine just for this purpose. Look for heading about 'MD5 Checksum' at "http://www.beechglen.com/mpe/data-encryption. In poking around the Freeware section of Beechglen's site, I saw they have a program called 'su' that is essentially a more controlled version of the old 'GOD' program. I haven't used it personally, but anything that allows more granularity of control in granting access and power is a good thing.