× 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's still an open access method.  For a number of reasons.

In Patrick's article (always eloquent) he stated that most shops allow 
people access to the data except the data they want to control.  That is 
an open shop.  A closed shop would change system value QCRTAUT to *EXCLUDE 
and then only let them access to data they wanted them to have.

Another thing that makes it an open system, in my mind, is that your 
method would still allow the users to UPDDTA, etc the files in question. 
It would also allow them to ftp the data, etc.  Pat mentioned that you 
could use exit points to restrict this, but ideally you would not let them 
have access to the data, as a default, in the first place.

One method is to only allow access via programs that adopt authority. This 
way the users have no direct access to the data itself.  We found that our 
canned package has every program set to USEADPAUT(*YES).  All we would 
have to do is to change the initial program to be owned by a user with 
access to the data.  The only problem with this package is there are too 
many points where the users are given a command line via CALL QCMD or 
QUSCMDLN and the thought of doing CHGPGM USEADPAUT(*NO) on these two 
hasn't been totally worked through yet.  This would effectively lock out 
all access via other tools, interfaces, etc for these users.  And now that 
the thought of changing QCMD and QUSCMDLN just hit me, it bears another 
round of internal discussion.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Wilt, Charles" <CWilt@xxxxxxxxxxxx> 
Sent by: security400-bounces@xxxxxxxxxxxx
04/26/2005 07:25 AM
Please respond to
Security Administration on the AS400 / iSeries  <security400@xxxxxxxxxxxx>


To
"Security Administration on the AS400 / iSeries" 
<security400@xxxxxxxxxxxx>
cc

Subject
RE: [Security400] RE: Prevent User Profile from using public authority






> -----Original Message-----
> From: security400-bounces@xxxxxxxxxxxx
> [mailto:security400-bounces@xxxxxxxxxxxx]On Behalf Of Patrick Botz
> Sent: Monday, April 25, 2005 7:41 PM
> To: Security Administration on the AS400 / iSeries
> Subject: Re: [Security400] RE: Prevent User Profile from using public
> authority
> 
> 
> In my opinion, exit point products, while providing a very 
> large amount of
> value add, are NOT a replacement for an exclusionary access 
> control model.
> 
> An exclusionary model defaults PUBLIC authority to *EXCLUDE 
> -- i.e. access
> is excluded to PUBLIC by default unless and until explicitly 
> configured
> otherwise. PUBLIC authority of *USE or greater is still 
> appropriate for
> some data in this model, but it is not assumed to be the 
> desired access.
> 
> An open access control model assumes everyone should be 
> allowed *READ or
> higher access to everything unless explicitly configured otherwise.
> Because of the heritage of i5OS many, if not most, customers 
> have an open
> access control model.
> 

Patrick,

I'm pretty much in agreement with you.  Looking back at my original post 
and the two options I outlined:

1) a. Create a group profile for all my "regular" users.
   b. Grant the group profile the same authority that *PUBLIC currently 
has for each & every object
   c. change *PUBLIC to *EXCLUDE for every object

2) a. Grant *EXCLUDE authority to every object for this user profile (or 
better yet a new group profile of which this profile will be a member)


Would you agree that #1 is exclusionary and #2 is open?  So you recommend 
#1?

If so, how do I go about getting it implemented?  Is the "Tips & Tricks" 
book still the best resource?

What about IBM objects?  Will option #61 "Revoke public authority to 
objects" on the SECTOOLS menu take care of everything or will I need to 
worry about other IBM objects?

Thanks,

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) 
mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.