RE: RE: Prevent User Profile from using public authority

One of the problems was that this canned package used a command line that 
might not have been QCMD or QUSCMDLN.  I think it was homegrown and then 
did a CALL QCMDEXC or some such animal.  The problem with this technique 
is that one cares about LMTCPB, the other doesn't.  Now it's coming back 
to me as to why we didn't go that route.

I too have ran into the wall on IFS not respecting adopting authority. 
Most of the canned stuff out there wouldn't touch IFS because that would 
require them to learn something new that wasn't supported on V2R1 of 
OS/400.  So, in general, for our canned software - not a problem.  I am 
aware of the profile switching technique.  Haven't used it yet though.

I am confused by your statement:  "I prefer to set effective group(s) for 
the user at those authorized common entry points."  What does this mean?

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





"David Morris" <David.Morris@xxxxxxxxxxxxx> 
Sent by: security400-bounces@xxxxxxxxxxxx
04/26/2005 11:01 AM
Please respond to
Security Administration on the AS400 / iSeries  <security400@xxxxxxxxxxxx>


To
<security400@xxxxxxxxxxxx>
cc

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






Rob,

I would try to identify the common entry points for your application.
Those will usually be menu systems, batch routing programs and several
server exits. Those could adopt but adoption has all sorts of
limitations with things like IFS files and triggers and can often lead
to unintended exposures. I prefer to set effective group(s) for the user
at those authorized common entry points. If you use this technique, you
will also want to revoke authority with a registered exit or scope
message that does a profile swap. Using this technique, no one without
special authorities can do anything that *PUBLIC cannot do without going
through your designated entry points.  Those entry points need to be
very well thought out and secure. Assuming that someone can likely get
to a command line or equivalent somewhere, you may want to make sure
users are limited capability and review commands that are allowed for
those users.

It is a lot of work to secure your system and I don't think anyone hits
everything all of the time so journaling/auditing are important.

David Morris

>>> rob@xxxxxxxxx 04/26/05 9:04 AM >>>
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

_______________________________________________
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.