RE: VB, ODBC and AS/400 -- MIDRANGE-L

Pete,

At 09:56 PM 2/3/98 -0600, you wrote:
>At 09:55 PM 2/2/98 -0800, John Earl wrote:
>>I'm still not sure how you would do that, even with exit programs.  How can
>>an exit program tell the difference between, say a VB ODBC update and an
>>Excel ODBC update?  From the perspective of a sysadmin, the VB update might
>>be okay (because it's a homegrown app with all the apporpriate edits in
>>place) and the Excel update would never be okay (No edits, no field
>>integrity, etc.).  But to the exit program, they're both just ODBC
updates, no?
>
>Well, what I've done is to put a table allowed commands in the program. If
the >statement is one that can change the database, I look at the table to
see if the >command is registered. If it isn't, I don't allow it. I also
don't allow CALLs to >QCMDEXC, but calls to any other program, at least
currently, are allowed. That part is >probably not foolproof, but so far has
been sufficient.

Yeah, we have a similar method of restricting access to CA Servers and
functions.  With the information that the IBM Exit Points provide, it's easy
to regulate access via servers (Database server, File Transfer Server,
Remote Command Server, etc.), and to functions within those servers, (File
Transfer upload, SQL Update, etc.), but there is no easy way to tell what PC
program initiated the server/function call. We're working on a couple of
scenario's, but nothing that jumps right out as both secure and easy to
implement (secure and hard to implement doesn't really help customers much).

With the current state of the technology, if you open up an ODBC statement,
you open it to all ODBC drivers coming from any PC program.  If you've allow
a VB payroll time update program to use ODBC, you're opening yourself up to
having those same files updated through MS Access, Excel, or any other ODBC
capable program on the PC.  In order to be sure that the update is coming
from your 'sanctioned' VB program, either IBM has to change the exit program
to provide the PC program name to the /400 (fat chance!), or the PC VB
program has to somehow identify itself to the /400 exit point, which is no
small feat. 

News/400 had an article last October that stated that the only secure ODBC
update was from a stored procedure that adopted authority.  That's certainly
taking the issue to the outer edge, but I can easily see how the author came
to that conclusion.  But underlying this statement was the notion that
AS/400 sysadmin's can not rely on PC's as part of their security structure.
Because PC's that access a /400 just can not be secured, the /400 has to be
the final arbiter of who get's access to which /400 resources.  Nobody has
yet found a good way to do that with ODBC (but we're still working on it! :)

JMHO,


jte
--

John Earl       Lighthouse Software Inc.
8514 71st NW    Gig Harbor, WA 98335
253-858-7388    johnearl@lns400.com

Without Lighthouse Network Security/400, your AS/400 is wide open.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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
+---