Re: General AS/400 Question

Vern Hamberg wrote:

> On our system, there is a library called RBTSYSLIB. It was placed at the
> _bottom_ of QSYSLIBL. It contains only objects that are common to more than
> one of the Help Sys products. Would you rather they put it at the top of
> QUSRLIBL?

QUSRLIBL wouldn't work because it gets overridden if a JobD has any libraries
listed in it.  But I agree with Charlie that the issue is not that a vendor used
the System Library, but rather that they did it without warning and most
importantly, the default authority on the library was *CHANGE.  As late as 1996 
we
had Help/Systems Products that put unsecured libraries in QSYSLIBL.  They also
contained large numbers of adopting objects that were owned by a QSECOFR-type
profile..  In their more recent release (7.0 I believe) Help/Systems has gone a
long way towards tightening up security.  They have reduced their reliance on
QSECOFR adopt, and properly secured their libraries and objects (Maybe Laura's
objection had a big influence).

But let's not pick on Help/Systems, there are plenty of /400 vendors that don't
give adequate thought to securing their packages.  Grab the install manuals for
your favorite tools and read what they have to say about security.  In many 
cases
they don't even address the subject.  Those that do often have statements like
GRTOBJAUT VendorLib/*ALL *PUBLIC *ALL  (I've seen it!). Heck, prior to V3R7, 
even
IBM shipped QSYS with *PUBLIC authority *CHANGE. (Note, if you have an older
release, you may still have this exposure).

The bad news is there are a lot of security slackers out there.  The good news 
is
that customers are waking up and demanding better security schemes from their 
tool
and application vendors.  I recently went around and around with a printing tool
vendor that had a GRTOBJAUT VendorLib/*ALL *PUBLIC *ALL instruction in their
manual.  "Why do my end users need to be able to delete your program objects?" I
asked.  "Should everyone who accesses my system, including customers, vendors, 
and
potentially even competitors, be able to clear any of the files in your
application?".  "Will your system still work if someone does delete a critical
system object?".  After they held up their 'Menu Security' scheme as a defense, 
I
really laid into them.  These questions aren't designed to embarrass, they're
designed to force the vendor to think about security, and compell them to 
perform
due diligence on the _real_ security requirements of their software.

I agree with Laura that you should hold vendor's feet to the fire on these
issues.  In truth she has done them a great service by pointing out the problems
that they had in their package.  But if a vendor has learned the lesson (as I
believe Help/systems has) and made adjustments in their product, we ought to 
give
them credit for their new-found enlightenment and move onto the next security
scofflaw.  There are a lot of other vendors that haven't yet learned of the
problems they can cause for their customers.

> Bottom line for me--I _do_ trust the people at Help Systems. Why? Because I
> know them personally. I worked in tech support there myself until early '91
> (fact was, I was let go, so the fact I am supportive of their efforts comes
> not from anything I get from them). The kind of treatment Laura Ausel tells
> us about was not at all to be tolerated when I worked there.

Vern,  I don't believe this is an issue of trusting that someone has not
deliberately set out to do harm to my system(s).  Rather the issue is that I 
don't
want to have to trust that they will not _inadvertantly_ do harm to my system.  
If
they are working under the covers (and beyond my ability to audit), how can I be
sure that what the vendor is doing will A)Work, B)Not conflict with what some
other vendor is doing, and C)Be supportable from release to release?

> The strength of the reactions to Laura's posting has surprised me. Is there
> more going on here? What is the big problem with a vendor's use of MI?
> Pathfinder uses it, I bet J.D. Edwards does, Charlie Tuner does (doesn't
> it, Peter?), Pathfinder does. And what's the problem if a vendor can create
> a system domain program?

The best answers to that question are contained in Joeseph Park's book "AS/400
Security in a Client Server Environment.  It's excellent reading if you want to
understand the implications of the kinds of damage a system state program can 
do.

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
+---