SPCAUT = *NONE

435 pts.
Tags:
Identity management
Security management
What can you do on the command line if you have it but have SPCAUT = *NONE.

I'm just trying to understand the risks and the benefit of having it = *NONE.

My understanding is that there is no risk as you cannot do anything, but if that is the case, can I set the LMTCAP = *YES?



Software/Hardware used:
V5R4 and V6R1
ASKED: March 20, 2012  3:36 PM
UPDATED: March 22, 2012  1:20 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    What can you do on the command line if you have it but have SPCAUT = *NONE. You can do anything that you are authorized to do. A 'special authority' (SPCAUT) is a way to short-circuit some authority checking. When you have a 'special authority', you don't need to be granted authority to do the things that the 'special authority' allows. For example, if you create a spooled file, you can also delete it. You don't need SPCAUT(*SPLCTL) to delete your own spooled files. But if you want to delete a spooled file that belongs to some other user profile, you either need SPCAUT(*SPLCTL) or you need to be granted sufficient authority to all the appropriate objects that may be involved in deleting spooled files. Some 'special authorities' grant new capabilities. For example SPCAUT(*IOSYSCFG) gives the capability of changing elements of the system's I/O configuration and SPCAUT(*SERVICE) gives the capability of accessing system service functions. You can't grant authority for those; you must have the capability through the appropriate 'special authority'. In general, no user ever needs anything beyond SPCAUT(*NONE). ...if that is the case, can I set the LMTCAP = *YES? There is no required relationship between LMTCPB() and SPCAUT(). They control very different things. The LMTCPB() attribute is used to determine which commands a user may execute from a command line. Each command has an attribute -- ALWLMTUSR() -- that can be set to either *YES or *NO. When a command has ALWLMTUSR(*NO), it can not be executed on a command line by a user who has LMTCPB(*YES) -- even if the user has all 'special authorities'. (Of course, such a user has ways of obtaining the capability.) LMTCPB(*YES) doesn't mean that a user can't execute a command. If the command can be reached through taking a menu option that runs the command, then the command will run. LMTCPB() also has a role in what values may be entered into the Program/procedure, Menu and Current library fields on a Sign On display. Some IBM-supplied commands are set by default with ALWLMTUSR(*YES). The SNDMSG and DSPJOB are examples of commands that are available by default even to limited users. You can set the attribute to allow or disallow any command you choose (if you have authority). If you use LMTCPB() to control command-line usage, make sure you check the ALWLMTUSR() attribute of every command on your system that you might be concerned about. (Not just commands in QSYS!) A limited user also might execute commands by typing them into a source member, compiling them as a CL program and running the program. If not CL, then REXX doesn't even need to be compiled. All of that can be done without access to a command line. Commands might be executed through ODBC or via RMTCMD or any rexec() client from a PC. It's very good not to give any SPCAUT() to any user. The need should be restricted to system administrators and perhaps some operations staff. Be very wary of relying on LMTCPB() for any degree of security if your system allows access through non-telnet network interfaces or if you haven't controlled attributes on commands. It can give a very misleading sense of security. Tom
    125,585 pointsBadges:
    report
  • Guy553
    Tom, Excellent response, however I think it goes far beyond the knowledge of my auditors, which is why I ask the question. Their perception is that and "elevated user" is someone that has:- Sign on capabilities - Password of *NONE: *NO Command line Access - Limit Capabilities *NO Initial Menu <> to *SIGNOFF Special Authorities <> to *NONE That is until recently, now they question that if a user has access to the command line they can type commands on it, even if they have no special authorities, (they not concerned with menu options, as they believe that if they have access to menu options they have been authorized to them). Basically they have identified some users on the system with no special authorities and access to a command line. Their thought pattern is that if they have access to the command line they can access to perform tasks above and beyond their role requirements. I need to know if this is true and if so I will remove the command line access. These users, I should add, have not been granted any special authorities to individual commands, nor have the commands been changed from the default. They are "normal" users that have for some reason been created with a command line, probably because when they were created no one understood the risk of the impact of granting them with it. Obviously now that everyone is more security conscious, these things are being picked up. My thought is that if they have no special authorities they do not need a command line access as they should not be able to carry out anything on the command line they cannot do without going through the menus.
    435 pointsBadges:
    report
  • TomLiotta
    Their thought pattern is that if they have access to the command line they can access to perform tasks above and beyond their role requirements. There's no way to answer 'yes' or 'no' without knowing what authorities they have. I need to know if this is true... To determine that, you need to review all of the objects that they are authorized to, including any object that doesn't have *PUBLIC *EXCLUDE, and compare those authorities to their "role requirements". ...and if so I will remove the command line access. If you have a network adapter active on your AS/400 and you run TCP/IP and/or host servers, then removing command line access won't secure anything from users with authorities beyond their "role requirements". It can just mean that improper accesses will be through other means. It might, however, satisfy your auditors, no matter how mistaken they might be. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following