Re: Commands for Limited Users

Phil,

Your summary is correct. I do advocate limiting authority so that users
can't do anything without calling an appropriate application. I haven't
run into any problems with a long running savsys related to group and
supplemental group profiles. It could be that Rob relied heavily on
private authorities. We have very few private authorities and favor
owner/primary group/authority lists.

--David Morris
 
"Elsewhere Rob Berendt has indicated the difficulties he ran across
using private authority instead of authority lists. Your experience
doesn't seem to invalidate Rob's findings."

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Phil Ashe
Sent: Thursday, September 07, 2006 2:05 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

David:

I have run into a few showstoppers with adoption. Triggers, IFS files

and vendor packages are three examples. If you rely on adoption, you may
need to redo your security scheme when you implement an application
change. I have been forced to redo the authority of an application that
relied on adoption when a new OS release ended adoption in an IBM
supplied process. I had a similar experience with a widely-used vendor
package that broke on a new release because it started using a system
function that ended adoption. I have also run into application changes
that failed due to IFS access. 

It sounds like you are advocating to limit the profiles that actually
have authority to work on your system. Then use profile swaps rather
than program adoption to enable most users to access these programs. In
your environment you've seen issues with authority adoption. As more
users modernize their applications, we can expect to see these problems
more often.

Based on your experience, part of what is needed to modernize
applications is a way to move away from programs that adopt authority to
something that implements profile swapping. 

Otherwise the core elements of your ideal i5 security scheme seem to be
the same: few owners; most users have little or no rights; most users'
rights to objects come through some means from higher-powered users.

Elsewhere Rob Berendt has indicated the difficulties he ran across using
private authority instead of authority lists. Your experience doesn't
seem to invalidate Rob's findings.

I took that to mean that you used adopted authority in your exit

program but it sounds like you are actually swapping or setting the
effective user, which is the approach I use in all cases where I used to
use adoption. There are some other steps you need to take like register
exits to back out the authority to mimic adoption.

The NetIQ exit programs actually swap profiles to something and set it
back. Other NetIQ authority schemes are based on authority adoption.  

You mention remote access users being granted ownership privileges as

the biggest security problem you see with adoption. I frequently see
high power profiles being adopted in poorly implemented programs opening
up all kinds of possibilities. 

Every object needs an owner, and the profiles that own important objects
should be controlled. There is all sorts of abuse that can happen when
high power profiles (*ALLOBJ or object owners) aren't controlled and
monitored. Regardless, bad program design is bad program design, and
there are a lot of ways bad programs can hurt your shop.

Phil Ashe