Re: Library List.

John

At 10:22 PM 12/10/97 -0800, you wrote:
>
>At 09:39 PM 12/9/97 -0500, you wrote:
>>"...for security reasons..."????? What security concerns would have you move
>>these 2 system libraries to the bottom of the user list?
>>
>
>Walden,
>
>For starters, prior to V3R7 both libraries came shipped with *PUBLIC
>authority *CHANGE, which means that a body could add a program to this
>library that would get invoked instead of some legitimate program.  This can
>be a security exposure when you have any sort of security rules enforced by
>a program (which is common).  A classic example would be the joe-programmer
>that puts a near replica of the payroll program in QUSRSYS, with a minor
>modification that enriches the programmer in some way.  When
>Jane-payroll-clerk runs payroll, he calls joe-programmer's bogus version (by
>virtue of it's place in the library list) and perfoms the dirty deed under
>her own profile.  There are even simpler and more damaging versions of this
>hack, but you get the idea.  Hacks like this can be difficult to detect.
>I've worked at a couple of banks where all ad-hoc manipulations of the
>library list were prohibited.  No ADDLIBLE, no CHGLIBLE, no CHGJOBD, etc.
>Any program that had the ability to manipulate the library list was
>scrutinized intensly.
>
>It's kind of a new concept to those of us who grew up using and loving
>library lists, but it is a fact of AS/400 security.

Personally, I'm _extremely_ reluctant to—in fact, I won't—take things out
of the system portion that are so heavily used by the OS for system
operations. E.g., all manner of TCP/IP objects are in QUSRSYS. I think
there's got to be a better way to deal with the risks—valid ones—that you
mention. I mean, _NO_ programmer should be allowed to put production
application objects into QUSRSYS, without some kind of repercussions.
There're other mechanisms, like CURLIB and PRDLIB, that can do this much
better and more safely.

We need policies and we need education. We need to get rid of
mavericks—oops, there I gooooo...

<no more soapbox—lost it there a little...>

Seriously, policies must be in place to manage these things, IMO.
Otherwise, we get into horrible messes. I know we have at our shop, but we
are doing everything we can to have a reasonable, workable environment.
This includes the use of change management and other tools.

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


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