Re: Security Exit point monitoring

Evan,

I don't know of a way of solving this problem that would not require code modifications, but here is a shell of an idea you may be able to build on...

1) Create a library (READLIB) that your user community has *USE access to
2) Populate that library with logicals that user READONLY has only *USE access to
3) Make sure that user READONLY is *EXCLUDE on all production libraries where the physical files are based.
4) Create an ODBC exit (QZDA...) that swaps profile to READONLY for all ODBC requests

Now, when ever a user tries to use ODBC thy will be swapped to profile READONLY profile and will have enough authority to *USE the logicals in READLIB, but no authority to see or change anything else.

The challenge you are left with is then any client side application that has a legitimate need to change data. This should be a small list of files that are left, and if you can create stored procedures (that adopt authority) for those existing files you may have a very tight and elegant solution that secures client side applications without messing up the legacy stuff.

But still, you'll have to code some.

jte

On May 27, 2010, at 4:07 PM, Evan Harris wrote:

Hi John and Charles

That was mostly my question (more in hope than expectation) so thanks
for the answer. It was pretty much as I expected but I had a client
that wanted to know.

Rob to answer your question the guys I am talking to know they have a
lot of users that use the Excel plug-in and they quite sensibly want
to protect themselves against their excel users updating the database.
At the same time they don't want to break their other ODBC
applications (you might be surprised how many of these exist outside
in the real world). Like a lot of places they don't have a complete
and accurate list of the profiles and other identifying features that
these things use so they asked if there was another way to avoid the
effort that might be required.


On Fri, May 28, 2010 at 12:56 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

On Thu, May 27, 2010 at 6:08 AM, John Earl <john.earl@xxxxxxxxxxxxxx> wrote:

If I understand your question correctly, then the answer is,
unfortunately, no. There is no way for the IBM i side Exit Program to
know anything about which client side program initiated a remote SQL
access attempt. The i side just knows that it received a remote SQL
request, it can see the SQL string along with some basic identifying
information about he job on the i (User name, etc.). The i side exit
program can also find other information on the i about the job such as
IP address, group profile membership, LMTCPB status, etc, but there is
nothing in the data string passed that would identify any information
about the client side program that launched the request in the first
place.

Actually, that's not quite true anymore...

With 6.1, IBM added some special registers,:
CURRENT CLIENT_ACCTNG
CURRENT CLIENT_APPLNAME
CURRENT CLIENT_PROGRAMID
CURRENT CLIENT_USERID
CURRENT CLIENT_WRKSTNNAME


Granted you have to modify your client applications to pass the values
along, but you could do so then restrict the activities allowed by
connections, such as those from Excel, that have blanks for the
current values.

Charles
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Regards
Evan Harris
http://www.auctionitis.co.nz
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
John Earl
President and CEO
Patrick Townsend Security Solutions
"The Encryption Company"

Olympia, WA | www.patownsend.com
Office: 360-357-8971 Ext 118