Re: ODBC Security -- MIDRANGE-L

Paul,

Wayne is a bright and wonderfull guy, but that doesn't mean he's right all of 
the
time.  <bg>  The "Application Only Access" that he (and Paul Conte before him)
champions is a good one, Heck I use a hybrid version of it when I develop new
systems, but it is not without it's own flaws.

PaulMmn wrote:

> I don't remember the problems with exit points (other than finding them
> all), but the security strategy is (basically):

The original knock on exit points was that they did not handle non-IBM ODBC.  
None
of the third party ODBC vendors used the IBM ODBC exit points, they were all 
using
DRDA and prior to V4R1 DRDA had no exit point.  But IBM understood the hole that
this left for customers and put together a DRDA exit point for V4R2 and then 
PTF'd
it back to V4R1.


>         - All objects (files and programs) owned by an OBJOWNER profile.

To do this well you should actually have two 'Owner' Profiles.  One owns the 
data
objects, and the other owns the program objects.  The profile that owns the data
objects is _NEVER_ signed on to, adopted, or used in any way.  Therefore no one
ever gets *ALL rights to your critical data files (you'd hate to ever have those
puppies deleted, so why ever give anyone the rights to?).  The profile that owns
the Programs would be given *CHANGE rights (at most) to the data. Then users who
need authority to change the data would be given *USE rights to programs owned 
by
the Program Owner.   These programs would adopt Program Owners authority, 
thereby
granting *CHANGE access to the data.

>         - All files have OBJOWNER *ALL (or *CHANGE) authority

If OBJOWNER owns the files as in Wayne's typical scenario, OBJOWNER is going to
have *ALL authority by default.  That is simply too much authority for end 
users to
have over production files.   You could dial this back to *CHANGE, but anyone
operating under the authority of OBJOWNER would always have the authority to 
dial
it back up to *ALL (The owner of an object can always specify security to that
object).  Better to have One owner own the data and the other own the programs.


>         - All files have QUSER *EXCLUDE authority
>
>         - All users sign on as QUSER-level
>
>         - All programs Adopt OBJOWNER authority (USRPRF(*OWNER))

It's not necessary to have all programs Adopt authority.  Only the initial entry
point to the application and all submitted batch programs need to adopt.

>         - All users granted *USE rights to the programs, not the files!

Again, not necessary to grant *USE to all the programs, Only the initial entry
point to the application and all submitted batch programs.


>         - *PUBLIC authority *EXCLUDE (to prevent PCs from reading your files)
>         - *PUBLIC authority *USE (if you don't mind PCs copying your files
> from 400 to PC)

While this may work for some, it can be too broad for many.  *PUBLIC *EXCLUDE
prevents anyone from using any Query tools (PC based or AS/400 based).  *PUBLIC
*USE allows anyone to use a Query Tool, but also allows the downloading of the
complete file via FTP or Client Access File Transfer.  It's sort of an all or
nothing scenario.  However, if you use exit programs it is easy to specify that
only certain operations are permitted.  You could, for example, restrict access 
to
the FTP download for HR users, but allow them to upload a single file into a 
single
library.  Or allow users to read fileA through ODBC, but not FileB.  The
possibilities are really unlimited because exit programs allow the end user to
control what the security rules are.

There are three additional strengths of Exit Points that haven't been mentioned.
The first is that they can restrict Remote Commands.  Even under V4R3 users that
are of the LMTCPB(*YES) flavor can enter commands through the Remote Command 
Server
and through DDM and have them executed on your AS/400.   LMTCPB(*YES) is only
checked by QCMD and by the FTP Server after V4R1.  You can use Exit Programs to
incoming block remote commands.

The Second is that they help you secure your system today without a complete
application security overhaul.   As I said earlier, the 'AoA' model is nice 
(with a
few modifications), but it is not a trivial matter to retrofit that model into
existing applications.  If you've got an appication that relies on Menu Security
(or worse yet, grants everyone *ALLOBJ special authority), re-arranging your
security model is going to require a lot of time as well as an in depth 
knowledge
of how all the parts of your system fit together.  If your application is a
Purchased Package, your task is made doubly difficult because the vendor will
continue to ship to you their security problem with each new release.   Exit
Programs can help here by securing an unsecured application from network access.

Finally, you can use exit points to audit network transactions. Exit Points give
you a view of requests that are being sent to your AS/400 that you can't get
anywhere else.   Who is using FTP against your AS/400 today?   Who is issuing
remote commands?   Who uses ODBC?   You don't really know unless you've got some
sort of exit program that audits for these transactions.  There is no other 
place
on the system to get this information.

Now I'm not saying that you should rely completely on Exit Programs, object
security still matters.  But Exit Programs are an essential part of a good 
security
approach and I believe that it is unwise to dismiss them out of hand.  Just 
giving
someone *ALL or *USE is going to at times provide them with too little or too 
much
authority.  Exit Programs balance the secuirty model so that someone can get 
just
the right access to just the right data at just the right time.

Sincerely,

jte


> (I hope I didn't leave anything out...)
>
> This scheme does the following:  QUSER-level users can not change your
> files.  Ever.  ODBC will not be able to change anything on the 400.  You
> have to grant QUSER *CHANGE rights to each and every file you want them to
> be able to change (use an authorization list!).
>
> QUSERs can change your files by using your programs.  IE they sign on and
> their initial program points them to a menu, which they can use because
> they have *USE rights to the program.  The program, owned by OBJOWNER and
> adopting OBJOWNER authority, can update the files.
>
> There are more details, but this covers the basics.
>
> --Paul E Musselman
> PAulMmn@ix.netcom.com
>
> >Gary,
> >
> >The most effective way to prevent ODBC access to AS/400 data is to write
> >or buy
> >Exit Programs that monitor your network interfaces.  By setting Exit Points 
>at
> >the network entrance to your system, you can block and/or regulate ODBC, File
> >Transfer (including FTP) and Remote Command request that are sent it's
> >way.  The
> >IBM manual "Client Access/400 for DOS and OS/2 Technical Reference V3R1"
> >explains
> >how to write exit programs, or you take a look at our offering at
> >www.400security.com .
> >
> >John Earl   johnearl@toolnet.com
> >
> >>Gary Munroe wrote:
> >
> >> We are just in the process of setting up ODBC to our AS/400 (v3r2) and
> >> looking at security.  Specifically, how we could set it up so that people
> >> that currently have a signon to the AS/400 could be prevented from
> >>connecting
> >> via ODBC.  Any additional information on ODBC security (other than standard
> >> AS/400 file security) would be helpful too.
> >>
> >> Thanks.
> >> | Gary Munroe                                                      |
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@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
> +---



--
John Earl   johnearl@toolnet.com

PowerTech Toolworks  206-575-0711
PowerLock Network Security www.toolnet.com
The 400 School   www.400school.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---