SM for Everyone!
April 15, 2013
By Bob Green
Vladimir Volokh of VEsoft fame called us to pass on an interesting story.
He was doing MPE system and security consulting at a site. One of his regular steps is to run VESOFT’s Veaudit tool on the system. From this he learned that every user in the production account had System Manager (SM) capability!
Giving a regular user SM capability is a really bad thing. It means that the users can purge the entire system, look at any data on the system, insert nasty code into the system, etc. And this site had just passed their Sarbanes-Oxley audit.
Vladimir removed SM capability from the users and sat back to see what would happen. The first problem to occur was a job stream failure. The reason it failed was because the user did not have Read access to the STUSE group, which contained the Suprtool "Use" scripts. So, Suprtool aborted.
“Background Info Break”
For those whose MPE security knowledge is a little rusty, or non-existent, we offer a a helpful excerpt from Vladimir’s son Eugene, from his article Burn Before Reading - HP3000 Security And You – available at www.adager.com/VeSoft/SecurityAndYou.html
<beginarticlequote>
When a user tries to open a file, MPE checks the account security matrix, the group security matrix, and the file security matrix to see if the user is allowed to access the file. If he is allowed by all three, the file is opened; if at least one security matrix forbids access by this user, the open fails.
For instance, if we try to open TESTFILE.JOHN.DEV when logged on to an account other than DEV and the security matrix of the group JOHN.DEV forbids access by users of other accounts, the open will fail (even though both TESTFILE’s and DEV’s security matrices permit access by users of other accounts).
Each security matrix describes which of the following classes can READ, WRITE, EXECUTE, APPEND to, and LOCK the file:
• CR - File’s creator
• GU - Any user logged on to the same group as the file is in
• GL - User logged on to the same group as the file is in and having Group Librarian (GL) capability
• AC - Any user logged on to the same account as the file is in
• AL - User logged on to the same account as the file is in and having Account Librarian (AL) capability
• ANY - any user
• Any combination of the above (including none of the above)
...
Whenever any group is created, access to all its files is restricted to GU (group users only).
<endarticlequote>
As Eugene points out above, account users do NOT have Read access by default to a new group in their account. This was the source of the problem at the site Vladimir was visiting. When the jobs could not read the files in the new STUSE group, the system manager the wielded the MPE equivalent of the medieval broadsword: give all the users SM capability.
ALTUSER PRODCLRK; CAP=SM,IA,BA,SF,...
This did solve the problem, since it certainly allowed them to read the STUSE files, but it also allowed them to read or purge any file on the system, in any account.
What he should have done was an Altgroup command immediately after the Newgroup command:
ALTGROUP stuse; access=(R:any;a,w,x,l: gu)
or specified the correct access when the group was built:
NEWGROUP stuse;access=(r:any;a,w,x,l:gu)
Since the HP 3000 runs in a corner virtually unattended (except for feeding the occasional backup tape), we often forget many of the options on the commands that are used sparingly. Neil Armstrong, my cohort in our Labs, often does a Help commandname to remind himself of some of the pitfalls and options on the lesser-used commands, NEWGROUP being one of them.