RE: [BPCS-L] Fix that SSA *Allobj Security Exposure!

["DeeDee Virgei" <DeeDee.Virgei@xxxxxxxxxxxxxx>]

Thank you Genyphyr!  I've learned a lot from your posting; such as, I didn't 
know 'the adopted authority only lasts for the prior call level'.  Also, I like 
how the users' command line access is now handled...  We go back to 1989 w/ 
BPCS.  Like Lisa, we were once told by SSA to not give our users command line 
access (handled via 'Limit capabilities *YES' setting in the user profiles, not 
by object authority).  We still setup our users this way, which we've been able 
to work w/ so far.  But at least now I know how to handle it if we do open up 
their access...  I also believe you are correct about the group job not having 
anything to do w/ the group profile; I was really heading in the wrong 
direction w/ that one...  I did find in my testing that w/ Adopt Authority *YES 
and User Profile *USER, that the User Profile *USER takes precedence...   My 
next step is to apply the 4.05 CD security BMRS.  Thanks again.

DeeDee Virgei
Project Leader

Nelson Stud Welding, Inc.


 -----Original Message-----
From:   bpcs-l-bounces+deedee.virgei=nelsonstud.com@xxxxxxxxxxxx 
[mailto:bpcs-l-bounces+deedee.virgei=nelsonstud.com@xxxxxxxxxxxx]  On Behalf Of 
Genyphyr Novak
Sent:   Friday, February 25, 2005 5:57 PM
To:     bpcs-l@xxxxxxxxxxxx
Subject:        RE: [BPCS-L] Fix that SSA *Allobj Security Exposure!

 << File: ATT2745229.txt >> 




Hi Dee Dee,

Just to get specific about how the security checks are resolved:

If the program adopts authority *YES (verify w/DSPPGM and press F1 on that
parm) - it is adopting authority of the previous *CALLLVL. Each time a new
program is added to the stack the system sees if it adopts the previous
call level authority to save time on resolving authority checks for the new
program that is starting. In an environment where NO program adopts
authority of the prior call level, then the system has to perform separate
lookups each time a new object executes and accesses objects like data
files etc. (and if you use long authorization lists this can definitely bog
down performance).

The adoption of *OWNER authority could have been a problem in BPCS when the
user brings up an option that contains the command line -- in this case you
do not want them to run in the command line with the program *OWNER adopted
authority because then they can update BPCS data that using their own *USER
authority they would not normally have the right to update/see.

The way that we secure the command line in BPCS therefore is to say Adopt
Authority (previous call level) *NO and User Profile *USER on the new
program that is used to bring up the F21 command line from a BPCS menu or
in any program that leads to invoking a system function where the command
line could be presented to the user. We also ensured the ATTN key was set
to the BPCS attention key program up sooner (there was a 'window of
opportunity' closed under those BMRs to get the system ATTN key if you knew
just when to press it).

When an Adopt Authority (previous call level) *NO program is encountered in
the call stack, then the system has to start checking specific authority
again, and to not carry over prior call level authorities. So when you go
back from the BPCS command line into a BPCS menu program, that menu program
needs to say User Profile *OWNER (the adopt *YES is irrelevant in that
case) again so that the user can run it and update data to which normally
they would have no rights to update (or in some cases even view). The BPCS
next program they call if it says Adopt Authority *YES (from previous call
level) just tells the system - whatever rights they had before, they still
have now.

To get really loopy - If for any reason the new program was owned by  a
DIFFERENT profile to SSA and the User Profile for that program was also
*OWNER, then the person running the job would inherit the rights of the
previous call level SSA *OWNER as well as the new call levels' program
*OWNER. There is not a whole lot of use for this in BPCS as I can see it,
but just to point out you can get pretty detailed about it if you want to
or need to by use of *USER/*OWNER authorities and whether or not a newly
executed program will adopt the authorities earned in the prior call level
when it executes. But the adopted authority only lasts for the prior call
level - it is not cumulative after that- so when program 3 starts, it only
inherits what program 2 had if Adopt is *YES and what program 1 had is
forgotten.

Hope this helps.

By the way I don't think the Group Job has anything to do with a Group
Profile. I believe it is used a lot for ATTN key processing to create extra
jobs at the same workstation, suspending one while another runs and
assigning message queues etc. to that group job (and *GDA - group data
area).

Thanks,

Genyphyr Novak
Senior Systems Software Engineer
SSA Global R&D
Phone: +33 450 53 93 70
Mobile: +33 662 00 71 04
E-mail: genyphyr.novak@xxxxxxxxxxxxx




date: Fri, 25 Feb 2005 09:46:27 -0500
from: "DeeDee Virgei" <DeeDee.Virgei@xxxxxxxxxxxxxx>
subject: RE: [BPCS-L] Fix that SSA *Allobj Security Exposure!

Hi Again,

Darryl, you just made me realize something...  If all the security programs
are set to adopt the owner's authority and BPCSMENU is owned by SSA (or
which ever single group profile is selected) then I should be OK -the step
of adding 'CHGGRPA GRPJOB(SSA)' to BPCSMENU is overkill.  The only thing is
I don't remember which program parameter takes precedence, 'Use adopted
authority' or 'User profile' (all the security programs are still set to
*USER) or if it's collective...  Time for me to read up on this some more.
Actually, since Genyphyr supplied me w/ the 4.05 CD BMR #s,  I'm all set.
Thanks Genyphyr!  Thanks Darryl!  Clare!  And everyone else!

FYI, I do agree that SSA doesn't need *ALLOBJ authority; just would like to
also remove it from my users' group profile settings (at least those w/
ODBC access).

And I agree w/ Norma, this discussion is somewhat nerve racking!  Thanks
again.

DeeDee Virgei


-----Original Message-----
From:              bpcs-l-bounces+deedee.virgei=nelsonstud.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+deedee.virgei=nelsonstud.com@xxxxxxxxxxxx]  On
Behalf Of darryl frankel
Sent:        Thursday, February 24, 2005 5:31 PM
To:          'SSA's BPCS ERP System'
Subject:           RE: [BPCS-L] Fix that SSA *Allobj Security Exposure!

Matters are different when accessing the database using tools such as ODBC
drivers.

In this instance, you may be advised to:
- Revoke all authorities and simply grant authority to a single group
profile with all rights required to run BPCS such as SSA. ALLOBJ authority
is not required at all.
Change your initial program such as BPCSMENU to adopt the owner's
authority.
In this manner when you sign on, you will not have access to BPCS, until
the
user has passed BPCS Security, under program control starting with the
initial program BPCSMENU.

- Create a new user profile for ODBC users to sign on with. This user
should
then at most have READ rights only to BPCS data libraries. In some shops,
you may want to restrict the access to a few files only.

Darryl Freinkel
Assignment400.com