Operating System - OpenVMS
1748265 Members
4019 Online
108760 Solutions
New Discussion юеВ

Re: "Trusted" detached processes

 
SOLVED
Go to solution
Richard J Maher
Trusted Contributor

"Trusted" detached processes

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?
7 REPLIES 7
Ian Miller.
Honored Contributor
Solution

Re: "Trusted" detached processes

I had a quick look in the listings

Setting this flag then sets psb$l_noaudit to non-zero which appears to suppress some auditing. Apart from that it does not seem to do anything bad.
____________________
Purely Personal Opinion
Craig A
Valued Contributor

Re: "Trusted" detached processes

What process is doing the disable of allegedly dormant accounts? It sounds like someone needs educating about having an exemption list from last login date checking.

Craig A
Richard J Maher
Trusted Contributor

Re: "Trusted" detached processes

Ian,

Thanks for the info. I guess the motivation for Rdb engineering, or the lack thereof, shall have to remain a mystery. (Unless someone in Sydney would care to ask a half interesting question while you're all chomping on your bamboo :-)

Craig,

Firstly, you maybe suprised to find that this is a fairly common problem/issue and secondly, there really are one or two benefits to recording last login times and login failures (not least of which is security)

Yet again the horse goes thirsty for reasons known only to the glue factory :-(

Cheers Richard Maher
Craig A
Valued Contributor

Re: "Trusted" detached processes

Hi Richard

I have no doubt that this info is useful - What I do not understand is how the accounts are being deemed dormant and/or being disabled?

Craig A
John Gillings
Honored Contributor

Re: "Trusted" detached processes

>or if it's simply a case of the people who
>made the decisions being a bunch of
>recalcitrant numpties

As an Australian I obviously know what "recalcitrant" means, but I'm not sure about "numpties".

However, I can hypothesise about the reasons for Rdb choosing the mechanism they did. Remember these are data base folk. Their focus is on I/Os. The logical name means they can control how often the UAF is updated. "ALWAYS, DAILY, WEEKLY, MONTHLY, YEARLY, NEVER". This means you can minimise, or eliminate I/Os to the UAF, which, to a data base mindset is always "a good thing".

The only downside I can see with your approach (which I would choose in your position), is that if you generate lots of logins, you generate lots of UAF updates. In the scheme of things, not really a huge cost!

I suppose the Rdb folk could also set the TCB bit in a future release and get rid of the extraneous audit messages as well as retaining their granularity control. Then they could laud it as a further improvement in a release note :-)

Have you suggested it to the Rdb people? They're usually very receptive to suggestions for improvement, especially easy ones. Maybe have someone else review your message to remove any unnecessary words like "recalcitrant" and "numpties"? ;-)
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: "Trusted" detached processes

Hi John,

> As an Australian I obviously know
> what "recalcitrant" means, but I'm not
> sure about "numpties".

I picked it up in England but I think it's Scots, so some sweaty :-) might chime in with its origins?

> This means you can minimise, or eliminate
> I/Os to the UAF, which, to a data base
> mindset is always "a good thing".

Maybe intrusion detection only every fifth time? You should bring this up with VMS engineering as well! I mean what good is last-login-time and login-fails anyway?

> The only downside I can see with your
> approach (which I would choose in your
> position), is that if you generate lots of
> logins, you generate lots of UAF updates.

Nope! With Multi-tab SSO and a single, persistent, network connection (as long as at one web-page is referencing it) you can sit there all day! (Well, I finally got around to implementing an inactivity timeout in the client, which should really be in the server, but anyway.)

> Have you suggested it to the Rdb people?

Go to www.jcc.com and search this year's listserver for "maher". I think you'll find my immediate response(s) to Colleen's request for feedback on May 22. I have 2 more notes of encouragement on Aug 18 and then I register my disbeleif at her release note on Sept 10 :-(

> They're usually very receptive to
> suggestions for improvement,

Yeah right! ROTFL! How's SQL> set session authorization using 'persona' :ws_integer; coming along? Or ever had to Rdb/SQL your way through a hierarchical structure and compare it to Orrible Oracle or SQL Server or DB2? You make me laugh :-(

> Maybe have someone else review your
> message to remove any unnecessary words
> like "recalcitrant" and "numpties"? ;-)

Feel free to read the original wording in my e-mails that are a matter of record.

When searching for another explanation, may I suggest that if Colleen's real name is not Collinder then maybe it should be?

Cheers Richard Maher

PS. That was me toying with the idea of Oracle outsourcing under-performing positions to SEIKish locales rather than comparing Colleen to a kitchen utensil.
Richard J Maher
Trusted Contributor

Re: "Trusted" detached processes

PPS. Catch up with ya mate Muggeridge over the Rdb Forum in Sydney?

Well I've just seen the 8.4 field test description and it still does not have IPsec int it :-(

I, and the VMS customer base, haven't been kicked in the guts like that in a long time - Ya broke my heart on this one!