RE: Problems with adopting authority -- MIDRANGE-L

Rob:

My initial reaction on this comes from way back in Versions 1 & 2 of OS/400 
(and even earlier with CPF) when vendors often required signing on as QSECOFR 
in order to install their products. What could be done to a system under 
QSECOFR was a bit too far beyond what could be done under another profile with 
*SECOFR class and all related special authorities. IBM has done a few things to 
control that, so it's not as big of a concern nowadays. But I'm never going to 
trust it until a version of OS/400 comes out that never has any PTFs needed. 
(BTW, I would not trust any vendor who demands an install using QSECOFR -- 
except IBM.)

I see a couple others commented while I was out and I'll skip those comments, 
simply noting that they seem accurate. I can still think of two additional 
areas though.

First goes to the idea of standards. QSECOFR can be abused and should be 
strictly limited to IBM requests. I can't think of any reason to use QSECOFR 
(except due to IBM and simple items such as being able to sign on at the 
console even when disabled) as long as it's possible to create alternative 
*SECOFR profiles.

By creating and using an alternative, a mindset can be put in place. Create a 
profile to act as security officer and use that profile for security officer 
activities. By avoiding QSECOFR, it can be kept in a very clean state, limiting 
chances to damage it or to make it unavailable for whatever reason. And if it 
ever becomes unusable in any way, the alternative *SECOFR profile can maybe 
help recover it in an emergency.

Second goes to the idea of auditability. QSECOFR is a widely known profile, at 
least relative to a profile you create yourself. By using only when absolutely 
necessary, entries relating to QSECOFR in your audit journal should be few and 
far between. If you ever see any such entry, you immediately know it's 
important. That doesn't minimize the importance of auditing an alternative 
*SECOFR profile, but it sure should be a red flag whenever you see a QSECOFR 
reference if you know it ain't used anywhere!

The potential benefits of an alternative *SECOFR profile seem to me to far 
outweigh the cost of creating one.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   5. RE: Problems with adopting authority (rob)
>
>Why is it so much better to create a user profile with all the authorities 
>of QSECOFR, and have the program owned by that user profile than just to 
>have it owned by QSECOFR?
>
>
>qsrvbas@xxxxxxxxxxxx (Tom Liotta)
>
>1. Leave owner as QSECOFR (or better, a *SECOFR but not QSECOFR).
>2. Leave program as usrprf( *OWNER ).
>3. Early in the program, switch to an authorized profile that can execute 
>user profile changes.
>4. Call QCAPCMD (or whatever) to do the work.
>5. Then immediately switch back to whatever user was running the job 
>(possibly QTCP).
>
>This way, usrprf(*OWNER) has authority to switch both ways and the 
>switched-to profile has authority to do the work without requiring adopted 
>authority.
>
>You should only need to create the one switched-to profile unless you also 
>choose to create the alternative *SECOFR profile (a very good idea, 
>avoiding QSECOFR).

-- 
-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promos=380455