RE: Prevent User Profile from using public authority

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?