1. ADDAUTLE -- Add Authorization List Entry
2. CHGAUTLE -- Change Authorization List Entry
3. CHGDTA -- Change Database File (using DFU)
4. CHGNETA -- Change Network Attributes
5. CHGOBJOWN -- Change Object Ownership
6. CHGSYSVAL -- Change System Value
7. CHGUSRPRF -- Change User Profile
8. CRTAUTHLR -- Create Authority Holder
9. CRTAUTL -- Create Authorization List
10. CRTUSRPRF -- Create User Profile
11. DLTAUTHLR -- Delete Authority Holder
12. DLTAUTL -- Delete Authorization List
13. DLTUSRPRF -- Delete User Profile
14. EDTAUTL -- Edit Authorization List
15. EDTOBJAUT -- Edit Object Authority
16. GRTOBJAUT -- Grant Object Authority
17. GRTUSRAUT -- Grant User Authority
18. PWRDWNSYS -- Power Down System
19. SBMRMTCMD -- Submit Remote Command
20. STRDFU -- Start DFU
21. STRPDM -- Start PDM
22. STRREXPRC -- Start REXX Procedure
23. STRSEU -- Start Source Entry Utility
24. STRSST -- Start System Service Tools
25. UPDDTA -- Update Data (using DFU)
I then reviewed whether or not the command was set to *EXCLUDE.
Do you see a risk of having any of the above commands not set to *EXCLUDE (e.g., *USE)?
Prudent use of object level security and controlling who is given special authorities is a much more robust way to secure your system rather than using either exit points or securing commands. For example, if you control the users who have special authorities such as *SECADM to just the users that need to create or manage user profiles, there's really no need to secure the command, CRTUSRPRF, because this command requires *SECADM special authority to run.
The STRSST command requires *SERVICE special authority so again, if you control who has *SERVICE to just the users that have a business justification to have it, then you shouldn't have to secure the command. Likewise, if you have used object level security, you shouldn't have to secure the EDTOBJAUT command because, unless the user somehow has *OBJMGT to an object, they can't edit the authority of the object.
Now if your system is wide open from an authority point of view and most users have more special authorities than is appropriate, then maybe, as a stop-gap measure, it would be appropriate to secure the commands. But, in general, I would put my efforts into securing the objects appropriately and making sure special authorities are only given to the appropriate users rather than trying to make sure all the commands you've listed are secured.
However, this method is very error prone -- you have to make sure to secure all instances of the commands and make sure you review all new commands added each release. Securing the objects and limiting special authorities is much more robust approach.
This was first published in December 2005