[Info-vax] Some part of VMS attempting to execute SYSUAF.DAT

[GerMarsh]

On Tuesday, January 19, 2016 at 9:49:32 PM UTC, johnwa... at yahoo.co.uk wrote:
> On Monday, 18 January 2016 17:11:37 UTC, GerMarsh  wrote:
> > I have seen an intermittent problem when a program using Websphere MQ routines attempts to execute the UAF data file. Bit like this...
> > 
> >  Terminal name:            FTA98:
> > Image name:               DSA6:[OFFICEMAN.][DECSUPP.MQ_DEV]MQPUT.EXE;2
> > Object class name:        FILE
> > Object owner:             [SYSTEM]
> > Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:, WORLD:
> > File name:                _DSA300:[VMS$COMMON.SYSEXE]SYSUAF.DAT;1
> > File ID:                  (20,1,0)
> > Access requested:         EXECUTE
> > 
> > I am pretty sure that I have seen such alarms with some VMS programs too.
> > 
> > I apologise profusely if I have missed some newsgroup article or even HP patch list which covers this but damned if I can find it!
> > 
> > Anyone any idea why any program routine would try to execute a data file?
> 
> My frequently-failing memory suggests that the audit extract you have
> included here may not be complete, that there may be fields before and
> after which may shed light on the picture. But no one else has asked,
> so ICBW.
> 
> E.g. stuff can go in the audit on success as well as on failure, and
> VMS will tell you which one is the case, but the extract you posted
> doesn't include that information. There are various examples in the
> Fine Manuals, in particular this stuff is covered in the Guide to
> System Security.
> 
> The Fine Manuals even tell you how stuff can be set up to audit every
> conceivable auditable event. Normally this would not be a useful thing
> to do, but sometimes there may be good reason to do so - e.g. someone
> in the ng recently asked "how do I see what a particular user has been
> up to", expecting the answer to be "here's how you see all the commands
> they issued". The audit log may provides useful and trustworthy
> information in a case like that.
> 
> Back to your query. An audit entry would typically indicate what kind
> of operation had been attempted, and the result of the attempt, e.g.
> 
> Access requested:      DELETE
> ...
> Status:                %SYSTEM-F-NOPRIV, no privilege for attempted operation
> 
> I don't see the equivalent of these fields in your extract. 
> 
> 
> Similarly, I might have expected to see (amongst possible others) an
> "auditable event" field which might have some related information:
> 
> Auditable event:       Object deletion
> 
> So what this example would tell us which we can't see in your extract
> is that there was a delete attempt on an object which VMS security
> had been configured to audit when the attempt failed. In this example
> the audit log tells us that it failed because of a privilege violation.
> 
> Is there some additional audit text in your picture that might be
> helpful here?
> 
> 
> Full text of Example 10.2 in the VMS 8.4 Guide to System Security,
> from http://h71000.www7.hp.com/doc/84final/ba554_90015/ch10s02.html
> 
> 
> 
> Message from user AUDIT$SERVER on BILBO
> Security alarm (SECURITY) and security audit (SECURITY) on BILBO,
>                        system id: 19662
> Auditable event:       Object deletion
> Event information:     file deletion request (IO$_DELETE)
> Event time:            24-APR-2008 13:17:24.59
> PID:                   47400085
> Process name:          Hobbit
> Username:              ROBINSON
> Process owner:         [ACCOUNTING,ROBINSON]
> Terminal name:         OPA0:
> Image name:            DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
> Object class name:     FILE
> Object owner:          [SYSTEM]
> Object protection:     SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE
> File name:             _DSA2200:[ROBINSON]FOO.BAR;1
> File ID:               (17481,6299,1)
> Access requested:      DELETE
> Matching ACE:          (IDENTIFIER=MINDCRIME,ACCESS=NONE)
> Sequence key:          00008A41
> Status:                %SYSTEM-F-NOPRIV, no privilege for attempted operation
> 
> and here's part of an example of an audit of a successful access - spot
> the difference (same manual):
> 
> Username:               ABADGUY
> Image name:             BOSTON$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE
> Object name:            _BOSTON$DUA1:[RWOODS]CONFIDREVIEW.MEM;1
> Object type:            file
> Access requested:       DELETE
> Status:                 %SYSTEM-S-NORMAL, normal successful completion
> Privileges used:        SYSPRV
> 
> Best of luck.

Sorry - I thought I would only include the relevant info. Here is a full journal entry...
Security audit (SECURITY) on SFDV01, system id: 54973
Auditable event:          Object access
Event information:        file access request (IO$_ACCESS or IO$_CREATE)
Event time:               12-JAN-2016 15:04:12.81
PID:                      000028FA
Process name:             _FTA79:
Username:                 MARSHG1
Process owner:            [MARSHG1]
Terminal name:            FTA79:
Object class name:        FILE
Object owner:             [SYSTEM]
Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:, WORLD:
File name:                _DSA300:[VMS$COMMON.SYSEXE]SYSUAF.DAT;1
File ID:                  (20,1,0)
Access requested:         EXECUTE
Posix UID:                -2
Posix GID:                -2 (%XFFFFFFFE)
Sequence key:             94B4D282
Status:                   %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

There is nothing in the MQ logs.