Patrick and Rob, As always, your input to these forums is very valuable. In fact, Rob, judging by your numerous and prolific posts, I sometimes wonder if you ever actually get any work done at your real job! ;-P In my answer to Charles' question - "Is there any way to prevent a user profile from using *PUBLIC authority? Here's the scenario, I've got a user profile set up for JDBC use from a external web server. All I want this profile to be able to do is call stored procedures it is specifically authorized to" - I was not judging whether his entire security scheme was to be open access or exclusionary, I was referring directly to what he asked regarding ODBC/JDBC: "Rather than risk hosing something else on your box by trying to create a 'replacement *PUBLIC profile' or even just trying to hit every object on your box, it seems to me it would be a lot easier to use an exit program for the ODBC/JDBC remote transactions" and I went on to position my company's exit program by saying "...but only one that I know of can afford 'pinpoint' accuracy with regard to controlling access via the exit point without having to modify any existing OS/400 object authorities or user profile groupings." The way I interpreted it was that he was trying to avoid any major changes to his existing security scheme. Why mess with the OS/400 authorities of specific objects when trying to address a specific METHOD of access to the object? In most shops, they 'allow all and deny specific' functions (rather than 'deny all and allow specific'). So, I could have a rule that prevents *PUBLIC from accessing any system objects via the ODBC servers: User Network Operation Action *PUBLIC *ALL *ALL *PASS *PUBLIC :IPALLOWED :ALLODBC *FAIL Where :IPALLOWED is the group of trusted internal IP addresses (10.*, 172.*, etc.) and where :ALLODBC is a group that includes all ODBC server functions: DBINIT_*ALL_*ALL All Functions and Commands DBNDB_*ALL_*ALL All Functions and Commands DBROI_*ALL_*ALL All Functions and Commands DBSQL_*ALL_*ALL All Functions and Commands If I had specific users to secure in this fashion, then I would simply not use *PUBLIC for the user parm and instead create a group, say :ODBCUSERS, that contained the OS/400 profile names that I want to allow to perform ODBC functions. Beyond that, I could even specify a specific object or objects: /QSYS.LIB/DW404DATA.LIB/FTPCOST.FILE Or /QSYS.LIB/DW404DATA.LIB/*.* All of this can be done without touching the object authorities in OS/400. If I needed to cover another METHOD of access, I could simply duplicate the rule to apply to FTPSRV or RMTCMD, for example. And, of course, I can always have the blanket protection for all remote access servers with a rule like: User Network Operation Action *PUBLIC *ALL *ALL *FAIL Personally, I would love to see more shops go with the exclusionary method of access control where QCRTAUT could be set to *EXCLUDE and then access is granted based upon "need to know," but that is not realistic in today's 'do more with less [resources]' business model. Steve ---------------------------------------------------------------------- message: 1 date: Mon, 25 Apr 2005 18:40:30 -0500 from: Patrick Botz <botz@xxxxxxxxxx> subject: Re: [Security400] RE: Prevent User Profile from using public authority Is changing to an exclusionary access control model from an open access model complicated? Absolutely. Does using an exit point product in the absence of an exclusionary model provide value? Absolutely, Will an exit point solution without an exclusionary access control model be able to provide the same level of security to an organization as an exclusionary model plus the exit point solution? In my opinion. the answer is no. ------------------------------ message: 2 date: Tue, 26 Apr 2005 08:25:24 -0400 from: "Wilt, Charles" <CWilt@xxxxxxxxxxxx> subject: RE: [Security400] RE: Prevent User Profile from using public authority Patrick, I'm pretty much in agreement with you. Looking back at my original post and the two options I outlined: 1) a. Create a group profile for all my "regular" users. b. Grant the group profile the same authority that *PUBLIC currently has for each & every object c. change *PUBLIC to *EXCLUDE for every object 2) a. Grant *EXCLUDE authority to every object for this user profile (or better yet a new group profile of which this profile will be a member) Would you agree that #1 is exclusionary and #2 is open? So you recommend #1? If so, how do I go about getting it implemented? Is the "Tips & Tricks" book still the best resource? What about IBM objects? Will option #61 "Revoke public authority to objects" on the SECTOOLS menu take care of everything or will I need to worry about other IBM objects?
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.