RACF really doesn't control access to a whole lot of commands.  CP class overrides will help here. It will audit a whole bunch! But control, no, not really.  Once on operator or sysoper id with secuser set to operator: SEND RACF SETRACF INACTIVE; response yes; now your system has fallen back to weak(er) cp passwords.

Some shops will not permit network access to the HMC, so now you need physical access to the HMC. OK, now you can get to SYSG by enabling the 3270 HMC iconic thingie and you know a valid ipl volume, but you are physically at the controls of the box.  So you have passed through several get smart doors into the cold room and you are being recorded by a webcam  ...

On an insecure note - sometimes I like to write the volume, start cylinder, # of cylinders of DIRMAINT 1DB in the comments of SALIPL - and it shows up on the SAPL screen.  Bailed me out of a jam more than once.

Coming back to operator and RACF without knowing maint password using some of the stuff Bob mentioned:

from operator:
xautolog maint
set secuser maint *
send cp maint IPL something or other (190 or CMS) ...
send maint rac (change my password through one of the racf commands)
...
logon maint
... have oodles of fun ...

-------- Original Message --------
Subject: Re: [IBMVM] Oops and finding passwords on a system...
From: Scott Rohling <[email protected]>
Date: Tue, May 12, 2009 9:31 pm
To: [email protected]

Good question --   I know that RACF can be used to control command access -- but I'm not sure it would work on OPERATOR.

I can see the problem:   Given that the only accessible user is OPERATOR if things fail at IPL (RACF doesn't come up, DASD isn't online, whatever) at the real/HMC console - it needs the authority to do what needs doing to bring up the system or restore what needs restoring.   physical/logical Access to the operator console is security hole at that point.

Scott

On Tue, May 12, 2009 at 6:54 PM, Mike Walter <[email protected]> wrote:
And every human Operator need class D privclass to handle SPOOL operations.  Some report or data files can be transferred by an Operator to another userid, viewed there, and transferred back.

It makes me wonder how secret 3-letter US government agencies dealt with Operator, sysprog, and security admin issues.

Mike Walter
Hewitt Associates

(Sent from the wee keyboard on a Blackberry.)


----- Original Message -----
From: "Bob Bates" [[email protected]]
Sent: 05/12/2009 04:48 PM EST
To: [email protected]
Subject: Re: Oops and finding passwords on a system...



From the HELP file for DEFINE MDISK says the PRIMARY OPERATOR has it. Doesn't matter what's in the directory or what the userid is. If you are the primary operator, you've got the ability.

Besides, AUTOLOG, SET SECUSER, and SEND can also be used to look at files on other users if you have the authority to do it. Want to keep the passwords under wraps, they best be encrypted. An inventive soul can find a way to get to clear text files if they have access to the right stuff.


Bob Bates
Enterprise Hosting Services

w. (469)892-6660
c. (214) 907-5071

"This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation."




The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.

Reply via email to