RE: Object authority

["Rooney, Michael P" <michael.p.rooney@xxxxxxxxxxxxx>]

Charles,

We're getting off the RPG topic but....

In Geralds post, he indicated that all CRT commands had
been modified so that all programs were created with
*OWNER and that owner was QPGMR.  This assumes that the
person executing the CRT... command is a member of or
has authority to the QPGMR Id.  If I'm not mistaken, this
essentially enables them to modify, change or delete 
any/all of the programs.

Additionally, what are the *PUBLIC permissions on all
the objects created?  If it is anything but *EXCLUDE, more
than QPGMR has access to all the programs and files.  Hence,
my point about having to "revoke" permissions. This also
implies the need to "revoke" QPGMR permissions to iSeries
commands such as CHGRPYLE or CHGJRN.    

As I stated in a subsequent post, iSeries security is a
complex topic (probably suited for a different list) and
solutions for 1 environment may not be best suited for
another.

That said, I would still have an issue with creating all
objects to execute under the QPGMR profile, as access for
QPGMR isn't restricted to just "programming".

Michael             


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of CWilt@xxxxxxxxxxxx
Sent: Tuesday, March 23, 2004 2:04 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Object authority


Michael,

I don't see why adopted authority would require "revoking" permissions
verses "granting " with group profiles.

Whereas many sites using adopted authority use only a single owning profile.
There's no reason why in your situation, multiple profiles couldn't be used
for different parts of the application.

Adopted authority works quite well in an environment were access must be
explicitly granted.

IMHO, it works even better than group profiles because as Rob pointed out,
with group profiles by themselves, you've given users authority to do
whatever they want to objects and programs.

Using adopted authority, the users are simply authorized to use pre-approved
programs.  Those programs in turn have the authority to make changes to the
data.

Charles


> -----Original Message-----
> From: Rooney, Michael P [mailto:michael.p.rooney@xxxxxxxxxxxxx]
> Sent: Tuesday, March 23, 2004 1:32 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Object authority
> 
> 
> 
> While I have no doubt that this approach works in yours (and 
> probably other)
> environments, the gaping hole you speak of may lay in some 
> "unauthorized"
> persons ability to execute one of these programs.  As the 
> program executes
> as *OWNER, OS/400, as you pointed out, doesn't enforce any authorities
> on the objects used by the individual executing the program.  In this
> case, it's not the "inclusion" of users that would concern me but the
> "exclusion" of individuals.  
> 
> What I find more concerning is the use of QPGMR.  As this is 
> an IBM-supplied
> profile, creating all programs to adopt these permissions is 
> more dangerous
> than your approach (i.e. creating a specific profile).
> 
> Working in a highly regulated industry, we are subjected to 
> annual audits
> by the FRB and SEC.  One of the items that is reviewed 
> without hesitation
> is the identification of programs that execute under adopted 
> authority.  This
> review is NOT limited to just QSECOFR.
> 
> Our solution is the use of Group Profiles.  Where as, we 
> create programs and
> files with specific ownerships based upon the application.  
> Individual users
> are than "added" to the group "owning" the objects.  This 
> enables us to have
> users enrolled in 1 group, 2 groups or no groups (i.e. exclusion).
> 
> Now before anyone says you can do the same by "revoking" 
> permissions to the
> qualified objects, we prefer to operate on the "need to use 
> basis", where
> you are granted access based on your need to use.  In other 
> words, we don't
> want to have to "revoke" access to everything we create.  
> With 300+ users,
> this approach works best in our environment while (most 
> importantly) satisfying
> regulators.
> 
> Hope this feedback is helpful.
> 
> MichaelR
> 
> 
>  
> 
> 
> 
> 
> 
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.