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