[Info-vax] "Trusted" detached processes

[Richard Maher]

Hi Hans,

"H Vlems" <hvlems at freenet.de> wrote in message
news:92b67089-d9d1-47ff-842a-2e2eb90cc34a at k26g2000vbp.googlegroups.com...
> On 12 sep, 13:46, "Richard Maher" <maher... at hotspamnotmail.com> wrote:
> > Hi,
> >
> > For many years now Tier3 has been using the PRC$M_TCB when $CREPRCing
our
> > detached Communication Server processes, and everything is just peachy.
In
> > the UAF, we happily update/maintain the last non-interactive login time
and
> > the number of login failures since last successful login, and all the
while
> > $SETUAI et al is happy to leave the auditing to us.
> >
> > Some of the main benefits of this approach are: -
> > 1) Security - The user and/or System Manager is able to accurately
identify
> > when someone last logged into this account and also if there've been any
> > failure attempts since last successful login.
> > 2) Dormant account clean-up - Accounts that are used solely as server
> > accounts and will never be logged into interactively, don't get
incorrectly
> > disabled for being "dormant".
> > 3) No ridiculous stream of "UAF modification" audit messages clog up the
> > console and audit logs.
> > 4) We get to structure audit messages and content to best suite the
> > environment
> >
> > So what's the problem? Well for many years (even longer than the
resistance
> > of intrusion detection) Rdb resisted the benefits of (1) above, but
finally
> > caved in to the demands of System-Managers/DBAs who were sick of having
to
> > re-enable their ODBC server accounts that were falsely targeted for
being
> > dormant (2). But they chose not to deploy the /TRUSTED qualifier and
> > therefore did not obtain benefit (3). The really odd thing here is that,
> > when faced with the backlash from SMs and DBAs about a now cluttered and
> > unusable console log, they chose not to simply flip a bit when creating
a
> > server process but rather to deploy some half-arsed logical name that
will
> > prevent UAF updates until a given interval has elapsed :-(
> >
> > Given that the people involved with the Rdb fudge were fully aware of
the
> > possibilities of PRC$M_TCB, I'm left wondering if there is something
> > intrinsically flawed with this approach or if it's simply a case of the
> > people who made the decisions being a bunch of recalcitrant numpties -
any
> > thoughts?
> >
> > Regards Richard Maher
> >
> > PS. I don't think "login failures since last successful login" has ever
been
> > on the Rdb radar.
> >
> > PPS. Can't remember what ACMS does - anybody?
>
> ACMS: wasn't it DEC's transaction manager for VMS, similar
> functionality as IBM's CICS product?
> ACMS maintained lists of tasks (executables actually, under VMS) and
> made sure only one version was available to run.
> Users connected to ACMS without having ever to see a VMS logon screen
> or VMS prompt.
> That's what my memory seems to remember.....

Yes, I remember ACMS (a little bit better than you I fear :-) having coded
it at places such as Barclays De Zoete Wedd, London Clearing House -
International Commodities Clearing House (on systems for the IPE and LME),
Cable & Wireless, and Royal Bank of Scotland nee Coutts & Co (I wish I had a
pension like Fred's!) What I am asking is if the CP ran with the TCB bit set
or if it updated last login time at all?

Not just ACMS, but any layered product that required authentication. Go
crazy with examples if you're interested in a technical discussion.

> Hans

Cheers Richard Maher