Re: security, pgm adoption

 

Jim Welsh wrote:

Anyone using the program adoption method as mentioned in the November 98
News/400
mag for security purposes...specifically to prevent users with Operations
Navigator or other
such tools, MS Query..etc....from accessing and possibly even deleting objects
on the 400?

Jim,

I read the article by Brian Singleton, and even though Brian is a bright guy, I have to disagree with a couple of the points that he made.   First, if you follow Brian's design you will disable all ad-hoc query access, from tools like Query/400, SQL, etc.   That's fine if it's part of your design, but many shops would have the users in an uproar if they just turned off query.

Second, the article skimmed over the fact that there is a fair piece of work to be done in order to get many real world applications from here to there.   If you're building a new application, then a scheme such as this would often work quite well (*).  But for existing applications it can sometimes be unpalatable to the users to have a new security design retrofitted to an application.

Third, Application only Access can fall down in the batch world.   The AoA model envisions that all authority be given to a menu entry point program, and that program (through adopted authority) provides the access to the rest of the world.   But Adopted authority does not automatically get extended to batch submits.   If your package does any submits, you will need to identify all of the programs that get submitted to batch, and then create each of those programs with adopted authority and authorize users to *USE these programs.

Finally, the article doesn't explain the advantages that Exit Programs provide.  Exit Programs can be an excellent tool for blocking access to system resources (Blocking reads, updates, deletes, what ever you like), without having to completely re-arrange your security model.  (Fair disclosure, Powertech Toolworks sells the PowerLock brand of exit programs to do just this.)
 

 

I'm taking the first step by setting up *PUBLIC *EXCLUDE to all objects within
our PRMS
applications...

No matter what you choose to do with your security, this is a good first step.   In a networked world, *PUBLIC is really the whole freaking world.   It's better to create groups as you have done, and limit *PUBLIC to only those objects you wouldn't mind showing to your competitors.

This is one those shops that had every user setup with *ALLOBJ authority which I
have
recently corrected.

Another good step.   It is almost impossible to secure anything against a *ALLOBJ user.

As the article states, AS/400 application menu security is a thing of the
past...time to tighten
things up!

Brian's got this right.  If you have PC's attached, Menu Security = No Security. 
 

The application owner for PRMS is a profile called APC..all the users are
grouped under APC...
APC owns all the objects...I am able to delete PRMS objects simply by pointing
and clicking...
 

This is a difficult situation.   If you lessen the User's authority to this package, you may disable some things.  Clearly you need to fix this.  Exit points can certainly help here.  You may also wnat to re-engineer your security model, but go slowly so as not to upset the apple cart.  One suggestion:  Find (or create) one user who is willing to be the guinea pig when you tighten security.  The if your plans fo awry it only affects one user.
 
 

Good luck!

jte
 

--
John Earl                                       johnearl@toolnet.com
PowerTech Toolworks                  206-575-0711
PowerLock Network Security       www.toolnet.com
The 400 School                             www.400school.com
--
  +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---