× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It sounds like higher ups have mandated that this user receive the
authority. You've probably tried this, but provide management with copies
of the innumerable articles on security talking about excessive authority.
Quote Carol Woodbury's book "IBM i Security Administration and
Compliance." Look up ALLOBJ in the index at the back of the book--there
are multiple references which should dissuade management from allowing
this authority. e.g., "...You're permitting that person to violate a
written or unwritten guideline that limits access to confidential or
private data residing on your system."

That said, the only options you have would be auditing everything the user
profile does. Then whenever there is questionable usage, report it to
management.

Michael Quigley
Computer Services
The Way International

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 08/29/2017
08:04:06 PM:
----- Message from Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> on Tue,
29 Aug 2017 16:11:20 -0500 -----

To:

midrange-l@xxxxxxxxxxxx

Subject:

Re: Rename WRKUSRPRF

QSECOFR authority - not really such a thing - but *SECOFR special
authority - that's has to be what was granted.

Now why do I say this? There are ways to block things from someone with
*SECOFR SPCAUT using something called function usage.QSECOFR itself will

(I believe) be immune from this stuff - or should be! But the person
with *SECOFR SPCAUT can be kept out of various operations and
functionality.

It's worth a look, methinks!

Good luck!
Vern

On 8/29/2017 3:15 PM, James Rich wrote:
On Tue, 29 Aug 2017, Steve Pitcher wrote:

You can put some exit programs in place to prevent actions. But then
the person could remove those programs. Or they could use your copied

command. I'd be more concerned with them using the PWRDWNSYS command.

Or ENDSBS. Or DLTLIB. And so on.

The end game would be to show the powers that be how dangerous
special authorities can be and try to remove the excess authority
rather than playing Spy Vs Spy over and over again.

I completely agree. This exact battle has already been fought and
lost. The only good option I have left is simply to be a better spy.

James Rich



----- Message from Holger Scherer <hs@xxxxxxx> on Tue, 29 Aug 2017
23:15:27 +0200 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Rename WRKUSRPRF

what's the gain in renaming WRKUSRPRF. If someone has *SECOFR he can
do a lot of damage.
You must think about auditing or rethink about the increased access
rights.

-h




Am 29.08.2017 um 22:01 schrieb James Rich <james@xxxxxxxxxxx>:

For reasons beyond my control or influence, a user on a system has
been granted QSECOFR authority. We're concerned about a number of
problems with that, but mostly the use (abuse) of the WRKUSRPRF command.

Are there problems with renaming QSYS/WRKUSRPRF? Can I simply
RNMOBJ OBJ(QSYS/WRKUSRPRF) OBJTYPE(*CMD) NEWOBJ(NEWUSRPRF) and still be
ok?



----- Message from Holger Scherer <hs@xxxxxxx> on Tue, 29 Aug 2017
23:17:18 +0200 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Rename WRKUSRPRF

Then *SECOFR rights are a no go! If that user profile needs to do some
work with increased security, use special programs with *OWNER
authority or other good practice procedures.

Or maybe (no pun intended) do a general rethink of the security concept.

-h



Am 29.08.2017 um 22:09 schrieb James Rich <james@xxxxxxxxxxx>:

Unfortunately nothing more than security by obscurity. He isn't
the most highly trained IBM i user in the world.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.