Re: audit journal entries (and more) - IBM AS400

This is a discussion on Re: audit journal entries (and more) - IBM AS400 ; "Czesio" schrieb im Newsbeitrag news:1158154357.704704.61420@h48g2000cwc.googlegro ups.com... > Hi, > > Is any way to delete audit journal entries from the journal receivers? Hopefully not. I tried around years ago, found no reasonable way except for some manipulations on Objects using ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: audit journal entries (and more)

  1. Re: audit journal entries (and more)


    "Czesio" schrieb im Newsbeitrag
    news:1158154357.704704.61420@h48g2000cwc.googlegro ups.com...
    > Hi,
    >
    > Is any way to delete audit journal entries from the journal receivers?


    Hopefully not. I tried around years ago, found no reasonable way except
    for some manipulations
    on Objects using SST/DST. But this can also be noticed.

    OS/400 is - except for a lot of other operating systems - really nice
    doing auditing the users, but:
    you must use this function and it's a hard job, because of the mass of
    data.
    On the other side, without a deep inspect of all object rights and a
    good plan in work
    management, your audit journal won't help. OS/400 still has some ugly
    holes and some really
    weird concepts in security "checking".

    One example - for the group to have to discuss something.

    Go to a box with V5R4 and create a user profile without any special
    rights.
    Usually, CHGSYSVAL should be *PUBLIC *EXCLUDE, but on older releases
    or for administrative reasons, this command might be *USE for everyone.

    As you usually won't expect - if a user has *USE on this command,
    *everyone*
    can for example change the system value QSTRUPPGM...

    and if you notice that in an audit journal you didn't make your home
    work

    -h



  2. Re: audit journal entries (and more)

    Holger Scherer wrote:

    > On the other side, without a deep inspect of all object rights and a
    > good plan in work
    > management, your audit journal won't help. OS/400 still has some ugly
    > holes and some really
    > weird concepts in security "checking".
    >
    > Go to a box with V5R4 and create a user profile without any special
    > rights.
    > Usually, CHGSYSVAL should be *PUBLIC *EXCLUDE, but on older releases
    > or for administrative reasons, this command might be *USE for everyone.
    >
    > As you usually won't expect - if a user has *USE on this command,
    > *everyone*
    > can for example change the system value QSTRUPPGM...


    It seems a bit of a stretch to call this a "hole" or even a weird
    concept. If you grant authority to do something (e.g., to execute a
    particular command), it's not surprising that someone might use the
    authority. And then, add on top of that no monitoring of the use of it.

    Finally, in the case of the startup program, there should be nothing
    that the program is capable of doing that would cause any trouble. The
    profile assigned to execute the startup shouldn't have authority to do
    anything but run the startup program. The startup program should run
    under the authority of its owner, not the authority of the job profile.

    So, unless authority is also granted to write a program capable of
    causing trouble, there is still no significant problem beyond perhaps a
    delayed startup.

    In other words, as with computers in general, if you set things up
    deliberately to ignore proper security guidelines and to expose the
    system to abuse, it's your own fault.

    Tom Liotta

    http://zap.to/tl400

+ Reply to Thread