[VMS V7/8] How to avoid filling sec audit with entries of BACKUP user? - VMS

This is a discussion on [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user? - VMS ; Is there a (simple) way to avoid having the security audit file filled up by security messages of the backup account using its BYPASS/READALL priv? That means, we want to see all the accesses on the system FILE access: Failure: ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?

  1. [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?

    Is there a (simple) way to avoid having the security audit file filled up
    by security messages of the backup account using its BYPASS/READALL priv?

    That means, we want to see all the accesses on the system

    FILE access:
    Failure: read,write,execute,delete,control
    SYSPRV: read,write,execute,delete,control
    BYPASS: read,write,execute,delete,control
    READALL: read,write,execute,delete,control

    but not for this particular user (which makes 20-40% of the audit file)...

    *) Sticking UIC below MAXSYSGROUP would not make a difference, would it?
    *) UAF /Flag=NoAudit is not overwriting Audit settings (as /FLAG=Audit is)
    *) Sticking an ACL for the Backup account on *every* file is out of scope.
    *) Filtering the security file afterwards /SELECT= is out of scope, too.

    What did I miss?

    TIA

    --
    Peter "EPLAN" LANGSTÖGER
    Network and OpenVMS system specialist
    E-mail Peter@LANGSTOeGER.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  2. Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUPuser?

    Peter 'EPLAN' LANGSTOeGER wrote:
    >
    > Is there a (simple) way to avoid having the security audit file filled up
    > by security messages of the backup account using its BYPASS/READALL priv?
    >
    > That means, we want to see all the accesses on the system
    >
    > FILE access:
    > Failure: read,write,execute,delete,control
    > SYSPRV: read,write,execute,delete,control
    > BYPASS: read,write,execute,delete,control
    > READALL: read,write,execute,delete,control
    >
    > but not for this particular user (which makes 20-40% of the audit file)...
    >
    > *) Sticking UIC below MAXSYSGROUP would not make a difference, would it?
    > *) UAF /Flag=NoAudit is not overwriting Audit settings (as /FLAG=Audit is)
    > *) Sticking an ACL for the Backup account on *every* file is out of scope.
    > *) Filtering the security file afterwards /SELECT= is out of scope, too.
    >
    > What did I miss?


    I know you said, "Sticking an ACL for the Backup account on *every* file
    is out of scope"; however, remember that you can add that to the default
    ACEs on every top-level directory in every effected tree and then SET
    SECURITY/DEFAULT [topdir...]*.*;* to propagate that down each tree. So,
    its not THAT big a deal, as compared to scripting SET SECURITY commands
    to set ACEs on every file. The default ACEs get propagated to all new
    files, as well.

    Something to consider.

    Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?

    D.J.D.

  3. Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?

    In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera writes:
    >Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?


    Out of scope as well (as written)

    So, I take it as I haven't overseen something obvious...
    --
    Peter "EPLAN" LANGSTÖGER
    Network and OpenVMS system specialist
    E-mail Peter@LANGSTOeGER.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  4. Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUPuser?

    Peter 'EPLAN' LANGSTOeGER wrote:
    >
    > In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera writes:
    > >Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?

    >
    > Out of scope as well (as written)


    Can you explain?

    > So, I take it as I haven't overseen something obvious...


    It depends. I think I know what you're trying to accomplish. However, so
    far, all of the solutions that are synergistically compatible with the
    design of the AUDIT facility have been flagged as "out of scope", what
    ever that might mean. A solution to a stated problem is, by definition,
    "in scope".

    So, I'm stymied at this point. It almost sounds like you're looking for
    a re-write of the AUDIT facility to allow users to side-step security
    selectively (*BIG* security hole!), beyond BYPASS privilege.

    D.J.D.

  5. Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?

    In article <48BB56F4.881E4A23@spam.comcast.net>, David J Dachtera writes:
    >Peter 'EPLAN' LANGSTOeGER wrote:
    >>
    >> In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera writes:
    >> >Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?

    >>
    >> Out of scope as well (as written)

    >
    >Can you explain?


    Not really. These are not my rules. It has to do with 'unmanipulated'
    security audit files and disk space usage and probably with some more
    which I don't know...

    >So, I'm stymied at this point. It almost sounds like you're looking for
    >a re-write of the AUDIT facility to allow users to side-step security
    >selectively (*BIG* security hole!), beyond BYPASS privilege.


    Huh? With BYPASS you side-step security? You remember this

    FILE access:
    Failure: read,write,execute,delete,control
    SYSPRV: read,write,execute,delete,control
    BYPASS: read,write,execute,delete,control <====
    READALL: read,write,execute,delete,control

    And, yes, a SYSUAF flag DontAudit or so would have been nice ;-) But I
    didn't explicitely request this! I only asked for what I overlooked...


    In my old company this all was solved by not using BYPASS or READALL
    (only access was via the SYSTEM protection field) for BACKUP account -
    which was also there for the recommended/optimized PQL values - and the
    users had been informed that only files open for SYSTEM Read are backuped
    (BACKUP UIC was below MAXSYSGROUP and so no SYSPRV access was there).

    And the casual disk movements had been done with a fully privileged BACKUP
    tool (usually by the SYSTEM or my own account) and the security alarms
    didn't matter at this times.

    But here, we seem to need some other ideas...

    Nevertheless, thanks for responding
    --
    Peter "EPLAN" LANGSTÖGER
    Network and OpenVMS system specialist
    E-mail Peter@LANGSTOeGER.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  6. Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUPuser?

    Peter 'EPLAN' LANGSTOeGER wrote:
    >
    > In article <48BB56F4.881E4A23@spam.comcast.net>, David J Dachtera writes:
    > >Peter 'EPLAN' LANGSTOeGER wrote:
    > >>
    > >> In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera writes:
    > >> >Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?
    > >>
    > >> Out of scope as well (as written)

    > >
    > >Can you explain?

    >
    > Not really. These are not my rules. It has to do with 'unmanipulated'
    > security audit files and disk space usage and probably with some more
    > which I don't know...


    ANAL/AUDIT/IGNORE doesn't "manipulate" the data, only filters it for
    purposes of the report.

    > >So, I'm stymied at this point. It almost sounds like you're looking for
    > >a re-write of the AUDIT facility to allow users to side-step security
    > >selectively (*BIG* security hole!), beyond BYPASS privilege.

    >
    > Huh? With BYPASS you side-step security? You remember this
    >
    > FILE access:
    > Failure: read,write,execute,delete,control
    > SYSPRV: read,write,execute,delete,control
    > BYPASS: read,write,execute,delete,control <====
    > READALL: read,write,execute,delete,control


    Exactly. The user can BYPASS security, but still gets AUDITed/tracked.

    D.J.D.

+ Reply to Thread