[Info-vax] Some part of VMS attempting to execute SYSUAF.DAT
johnwallace4 at yahoo.co.uk
johnwallace4 at yahoo.co.uk
Wed Jan 20 08:20:42 EST 2016
On Wednesday, 20 January 2016 12:14:06 UTC, GerMarsh wrote:
> 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.
Much appreciated, thank you. [In passing: the first extract you
posted had a line for "Image name:" - but it's not in this one?]
>From the new info, we now know that
(1) the audited event was an IO$ACCESS or IO$CREATE operation
(2) the operation failed with status %SYSTEM-F-NOPRIV
>From the Fine Manuals, e.g. the OpenVMS IO Users Manual, for (1),
e.g. http://h71000.www7.hp.com/doc/84final/ba554_90018/ch01s03.html
we can see the significance of "EXECUTE" mode access here (which
corresponds to the bit FIB$V_EXECUTE in the Access Control chunk of
the File Information Block). It says that when EXECUTE mode access
is specified:
"The protection check is made against the EXECUTE bit instead of
the READ bit. Valid only for requests issued from SUPERVISOR, EXEC,
or KERNEL mode."
IE no one is actually attempting to execute the file, but someone
is using a variation on the obvious access checks (one I'd
forgotten about; although I quote the 8.4 manual for the example,
this little feature has been around for quite a long time and no
I can't remember how long).
Does this shed any light? I suspect not much, except to confirm
assumptions already made. Validating assumptions is always good.
Is this a symptom of a non-problem, ie something which has
been going on for ages, but nobody's noticed this particular
behaviour? It wouldn't be the first time I've seen that kind
of thing.
Are you getting anywhere via other routes?
Best of luck. Keep digging.
More information about the Info-vax
mailing list