RE: Audit Journal Entry

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Patrick

Thanks for the frank and open answer. One of our customers got a T in 
the type on an AF record - with a 20 following - and this is for lack 
of authority to a TCP/IP port. A couple questions - do the GR types 
migrate to where they apply better in subsequent releases? And 
second, how does one get not authorized to a port? I tried port 
restrictions, I tried Application Administration.

Thanks
Vern

At 10:16 PM 9/26/2006, you wrote:

> The "GR" audit journal entries were added to the system as a way to solve a
> development process problem.
>
> Often the need for a new audit journal entry in the OS was not discovered
> until too late in the development process to create them in time for that
> release.  In the -- now, long ago -- past, we would have to wait for the
> next release to add the new audit journal entry.  This time delay was not
> always acceptable.
>
> So, to be able to add new crucial audit journal entry codes that were not
> originally planned for, we created the concept of a "generic audit journal"
> entry or the GR.  The GR entry is used for many different types of
> unrelated entries.  The TYPE of the GR entry ("T" in this case) is supposed
> to tell you exactly what a specific entry means.  The type also defines
> what kind information is stored in the other entries of this particular
> record.
>
> Unfortunately, a quick check of the Audit Entry Layout appendix in the
> Security Reference manual, seems to show that the information for the "T"
> entry type for GR records is missing.  It was either inadvertently removed
> or somehow never got updated.
>
> Based on the information in a previous post of this topic, it seems that
> this indicates something today with an FTP connection request.  I can't be
> sure though.
>
> As an aside, this "brilliant" idea happened to be mine and I was somehow
> able to convince the necessary people that this was indeed a good idea.
> After one or two releases, however, it became apparent that the idea may
> not have been quite as brilliant as I thought it was. Mea culpa...
>
> Patrick Botz
> Senior Technical Staff Member
> IBM Lab Services, Rochester
> Security Architecture & Consulting, i5/OS Security Architect
> (507) 253-0917, T/L 553-0917
> CTC Fax # 507-253-2070
> email: botz@xxxxxxxxxx
>
> For more information on CTC, visit our website at
> http://www.ibm.com/eserver/services
> http://www.ibm.com/servers/eserver/services
>
> --
> 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.