|
Ok. I understand. Me, and evidently a few others, thought you were trashing the owned program model itself and not necessarily QPGMR. And you're right, most of that stuff can be eliminated by LMTCPB. But I wouldn't count on that. Glad to see that you use exit points. Out. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Rooney, Michael P" <michael.p.rooney@xxxxxxxxxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 03/23/2004 03:19 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx> cc Subject RE: Object authority Rob, Your exit point comment is true and yes, we do utilize exit points. As my post states, we, like others, use an owned program model. Most of the other functions you've outline require CMD line access which we do not permit. As the topic initially discussed the use of QPGMR as adopted authority, I didn't feel it necessary to outline a perferred security strategy. The whole point of my orignal post was aimed at addressing the use of QPGMR as the "adopted" owner and user. I believe this to be a bad practice that permits access to numerous system functions beyond the role of a "programmer". Given the flexibility of the iSeries, it is entirely possible to achieve the same result using multiple methods. In short, what is best suited for one environment may not be best in another. The simple fact is, iSeries security is complex and it would be nieve of anyone to think that a simple structure using adopted authority is an end-state solution. Michael -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx Sent: Tuesday, March 23, 2004 1:43 PM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority The problem with that concept is that, unless you have a strong exit point strategy, if the person is a member of the group which has access to the files then what is to stop them from doing the following? Start, Run, cmd rmtcmd dltf mylib/myfile //myiseries or Start, run, cmd ftp myiseries quote rcmd dltf mylib/myfile or an iSeries file transfer request, or ODBC, or etc? This is why many locations have went to the owned program model. And this was by some heavily regulated people in the medical field. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Rooney, Michael P" <michael.p.rooney@xxxxxxxxxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 03/23/2004 01:32 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx> cc Subject RE: Object authority While I have no doubt that this approach works in yours (and probably other) environments, the gaping hole you speak of may lay in some "unauthorized" persons ability to execute one of these programs. As the program executes as *OWNER, OS/400, as you pointed out, doesn't enforce any authorities on the objects used by the individual executing the program. In this case, it's not the "inclusion" of users that would concern me but the "exclusion" of individuals. What I find more concerning is the use of QPGMR. As this is an IBM-supplied profile, creating all programs to adopt these permissions is more dangerous than your approach (i.e. creating a specific profile). Working in a highly regulated industry, we are subjected to annual audits by the FRB and SEC. One of the items that is reviewed without hesitation is the identification of programs that execute under adopted authority. This review is NOT limited to just QSECOFR. Our solution is the use of Group Profiles. Where as, we create programs and files with specific ownerships based upon the application. Individual users are than "added" to the group "owning" the objects. This enables us to have users enrolled in 1 group, 2 groups or no groups (i.e. exclusion). Now before anyone says you can do the same by "revoking" permissions to the qualified objects, we prefer to operate on the "need to use basis", where you are granted access based on your need to use. In other words, we don't want to have to "revoke" access to everything we create. With 300+ users, this approach works best in our environment while (most importantly) satisfying regulators. Hope this feedback is helpful. MichaelR -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Helgren Sent: Tuesday, March 23, 2004 12:09 PM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority Actually, I think this is a great approach and until I see some gaping hole in my logic, we'll continue to use it. I don't know if there is an equivalent in the Windows and Linux world, but when I finally discovered this as part of OS/400 security I was relieved. It is very easy to implement. We don't use QPGMR, we create a specific User Profile, but all programs are compiled USRPRF(*OWNER) and the files and objects are owned by this profile. The beauty is (as mentioned before) that users sign on to the iSeries and get a menu driven system that allows them to run any program because they *are* the owner as far as the iSeries is concerned. If they exit the menu system (Sys Attn or whatever), they revert back to their own user profile which in some cases can do nothing. This seems to be a fairly rational and easy approach to managing security. Or, perhaps I missed something. Pete Helgren Value Added Software,Inc. 801.581.1154 -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Rooney, Michael P Sent: Tuesday, March 23, 2004 9:09 AM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority If your shop only has 1 user this works well. Better yet, why not run as QSECOFR? Otherwise, I vote to stay as far away from this approach as possible. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Gerald Magnuson Sent: Tuesday, March 23, 2004 10:50 AM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority how about another survey question??? We have changed the CRTPGM (all create pgm commands) to USRPRF(*OWNER) and all programs are created with QPGMR group... How many of us are running this way, instead of the actual user profile controlling both the program object authority and data object authorities??? ("make it work like the S/38,S/36,S......") -- Gerald Magnuson The Knapheide Manufacturing Company Quincy Illinois _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
