Re: NO queries in QGPL please!! -- MIDRANGE-L

John,

In a message dated 98-03-19 19:03:08 EST, you write:

> Dean is a smart guy, but he's wrong on this point.
>  First off, message queues for devices are created in
>  QUSRSYS, not QGPL, so there will be no conflict with
>  users doing their own autoconfig

Dang, John!  One mistake in nearly three years, and you guys have got me
paranoid.  Ya' know, just because you're paranoid doesn't mean "they're" _NOT_
out to get you ;-).  I signed back on to verify the information I _JUST_
checked.  Device descriptions and message queues are, as stated earlier by
Dave Shaw, created in QSYS.  OUTQ's are created in QUSRSYS.

>  Second, If you did the same thing to QUSRSYS that I
>  proposed to QGPL, (limit users ability to add objects
>  to it), the only thing that wouild be disabled is
>  end-users ability to autoconfig devices.  This is not a
>  bad thing.  Autoconfig is a handy tool for IS staff,
>  but good security practices would counsel against
>  leaving it on all the time.

Agreed here, but the only limitation is for OUTQ's...

>  Third, and this one really gets me, is the general
>  notion that something bad (we don't know what, but
>  we're sure it's bad) might happen if you tighten down
>  security.  I'm not picking on Dean, because I hear this
>  from many sources.  And I know that this comes from the
>  (percieved) limited ability to test security changes,
>  especially ones like this that affect IBM objects .
>  Many people have nightmares about the time that they
>  changed some security value and ended up disabling
>  hundreds of people.

No, no, no, no, no ;-).  I _by no means_ meant to imply that security
shouldn't be tightened down.  I am a _HUGE_ (no smart aleck comments about my
stature from those that I've met, please) supporter of security issues.  I
attend those marathon security BOFs at COMMON, and try to help make the /400
more secure when I can.  I agree with Steve Glanstein's position that security
level 50 should be used unless you're going to lose vendor support over it --
and that you should look at dropping vendors that would do so.

>  But just as with any other change on your system, you
>  should test security changes on a small scale before
>  you roll out a massive change.  When you can't create a
>  separate test envirnoment (like this  QGPL change), you
>  can pick a small group of users, tell them what you're
>  doing, and make the change effective for just those
>  users.  You can then determine whether the change has
>  any adverse affect (I'd be shocked if you found one in
>  this instance).

Agreed, and _this_ is what I meant to imply.  Be careful, use a "development
box" for testing if you can -- many of you have a Y2K box installed that would
be perfect.

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"It is impossible to make anything foolproof, as fools are so ingenious." --
Anonymous
+---
| 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
+---