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

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.

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

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.

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

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.