they are moving around. It's hard to manage the (often vastly
differing) authorities of other code unless you have adequate
authority. In these cases, QSECOFR authority is a necessity.
It's probably worth spending a little time to clarify this last
sentence, and one of my earlier posts.
There is very little magic about QSECOFR. If I were to copy the QSECOFR
profile to a new profile called ZSECOFR, ZSECOFR would have all of the
capabilities of QSECOFR. It is not the profile itself, but rather the
special authorities that make QSECOFR so powerful. Therefore, we
shouldn't think of power as being "QSECOFR authority", but rather think
about power as being bestowed by each of the eight individual special
authorities that a user id might have.
-If a user has *SECADM, they can create, delete, and change User
profiles - assuming they have the appropriate object authority to the
profile they want to change (You can't change a password on a profile if
you don't have at least *CHANGE authority to that profile object). It
is worth noting that you cannot create or change a profile to have
special authorities that you are not carrying in your current job.
-If a user has *SAVRST, they can save and restore objects to the system
- this includes the ability to save objects that a user is *EXCLUDED
from. Imagine the implications of me being able to save (into a save
file in my own library) the credit card file that I do not have read
rights to. When I restore that file to any library other than it's
original, any individual authorities that object had (including my
*EXCLUDE authority) are lost.
-If a user has *SERVICE, they can use the System Service tools (STRSST).
SST is handy for turning raid on or off, and for turning your nefarious
little C program into a system state monster. Really, how many people
need *SERVICE? And how many days a year do they need it? Can you
justify having *SERVICE in your default profile 24 x 7 x 365 because you
STRSST everyday?
-If a user has *IOSYSCFG, they can configure communications on your
system. All those users who have *IOSYSCFG have the ability to mess
with your TCP/IP configurations, and if you still have SNA (ANYNET)
configurations, they can connect to your system as QSECOFR without
knowing the password. Very handy.
-If a user has *AUDIT, they can turn auditing values on and off.
Actually this is (IMHO) the least dangerous of the group, but oddly
enough it is the one special authority that seems to be tightly
regulated (according to our annual State of the System i security study
- go to www.powertech.com to read the whole 2008 study). Go figure.
-If a user has *JOBCTL they can start, end, hold, release, and otherwise
mess with any other user's spooled files. This would include JOBQ and
OUTQ entries. The nice thing about *JOBCTL special authority is that it
can be controlled (Investigate the OPRCTL parameter on the CRTOUTQ and
CRTJOBQ commands to see how to control *JOBCTL users).
-If a user has *SPLCTL they can start, end, hold, release, and otherwise
mess with any other user's spooled files. This would include JOBQ and
OUTQ entries. The bad thing about *SPLCTL special authority is that it
can _not_ be controlled or regulated. It is *ALLOBJ for spooled
objects. I can argue a very strong case for never giving this special
authority to any live person - an few if any 'work profiles'.
-If a user has *ALLOBJ, they can read, change or delete every object on
the system. If you don't believe me, then take a system that you don't
care about, sign on with *ALLOBJ, and execute the command DLTPGM
QSYS/QCMD. That will be the last command you run on that system until
you reload the operating system (Author's disclaimer, if you are dumb
enough to actually delete your QCMD program, I take absolutely no
responsibility for the awful mess you will create). Also note that
because *ALLOBJ confers at least *USE to every object on the system, and
User Profiles are objects, you can use *ALLOBJ to turn yourself into any
other user through the use of methods that Joe Pluta has already
covered.
Bottom line, it is Special Authorities that are powerful and dangerous,
not User ID's. Keep a close watch on who has which special authorities,
and why. And if your vendor cannot tell you why they need a special
authority, consider removing it from their profile. I think you would
be amazed at how many times you could do that without having any adverse
affect.
Jte
--
John Earl, VP and Chief Technology Officer
PowerTech: 253-872-7788
Direct: 253-479-1408
Mobile: 206-669-3336
John.Earl@xxxxxxxxxxxxx
Email is an excellent way to communicate material that is not time
sensitive. If your communication is of a more urgent nature, please
call.
===========================
This email message and any attachments are intended only for the use of
the intended recipient named above and may contain information that is
privileged and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message or by telephone and delete the
message from your email system. Thank you.
midrange.com
