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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.