Operating System - OpenVMS
1748219 Members
4453 Online
108759 Solutions
New Discussion юеВ

Dual control using UAF features

 
Bill Hallman
Occasional Advisor

Re: Dual control using UAF features

Wow - take a day off and inundated with some great responses. I'm still digesting; but as of now I'm moving toward a simplified approach that gives everyone a separate username and, at specific points in the process, verifies that another valid user is logged in at the time. This combined with login timeouts should get me past the auditing reqs for now.

I have some qusetions about what I've seen here:
Richard: The hash_password procedure call you showed implies that you CAN send it a mixed case pw, despite what the manual says; is that true? And Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal

Steve: the application is written to run from a single session, which is why I want code to check that another valid user is present before it runs. Eventually I will have to redesign the app to be runnable from multiple sessions.

John - I like your solution if I can easily find a way to do an SSH call from the code (or maybe with $SPAWN to a DCL proc). This is essentially the DECnet solution, without DECnet, right? I have already declared to the users that I will use the presence of two valid users logged in, but I may try to change it, especially as it would not require the users have GROUP priv to hunt through logged on users.

To all, you have convinced me not to try to maintain my own passwords. I definetly want to use UAF to maintain, expire, check, etc.

Later I will redesign the app to strenghen the whole business, and may well try to get approval for outside help at that point.

Sorry I'm so late responding, but I am in Alaska, so it's not that late here (~11:30); and I've had other issues to handle this AM.


Richard J Maher
Trusted Contributor

Re: Dual control using UAF features

Hi Bill,

[Richard: The hash_password procedure call you showed implies that you CAN send it a mixed case pw, despite what the manual says; is that true? ]

Yes.

[[The code shown earlier would better use an AND operator and not a = equality test operator for the low-bit-set condition status checks; the code shown unfortunately misses all but one of the possible successful status condition codes, and that can lead to unexpected failures at run-time.]]

[And Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal]

Bill which do you think would be harder to diagnose and ultimately debug?

a) Doh! This thing keeps crashing at %FAC-F-QUALIFIED_SUCCESS
b) Everything appears to be running as normal and there's nothing in the log files but the repercussions of being non-deterministic in your error-checking have resulted in who knows: -

1) RMS Key of reference not established but read ok?
2) Rounding issues but close enough?
3) Counter overflow?
4) Output truncated?
5) Contextually Could be good - Could be bad?

Now you may not give a hill of beans as to why the "success" status was qualified but the first scenario's going to be a whole lot easier to fix eg:

"If sys_status not = x and y and new-Z"

as opposed to "Dang, why is is doing that?"

Personally I use BLBx in MACRO just out of convention but I think I'm going to change. (And there's that lovely case statement in MACRO and EVALUATE COBOL etc!)

Don't forget to check out lib$match_cond as well. I never use it but who knows?

Cheers Richard Maher



John McL
Trusted Contributor

Re: Dual control using UAF features

I'm intrigued by your comment about needing to validate that two users are logged in.

Is this only a check at login or will there be repeated checks to ensure that two valid users continue to be logged on? If it's the latter the application they run might need an AST routine to be triggered if the other user logs out.
Hein van den Heuvel
Honored Contributor

Re: Dual control using UAF features

>> and Hoff, I see what you are saying about checking for successful status return, rather just ss$_normal

Right. KISS. Just test for succes. If Macro BLBC/BLBS, Cobol has 'status-code IS FAILURE/SUCCESS, Pascal has the EVEN/ODD test. What is the implementation language?

>> moving toward a simplified approach that gives everyone a separate username and

Great. It just makes sense in general, and is more often than not an auditing requirement as well.

>> at specific points in the process, verifies that another valid user is logged in at the time.

Like John McL I do not get this. Please elaborate. At first I though there was missing NOT in the text here, but later you seem to repeat this.

IF, the requirement is to make not there is only one user in the application, THEN I would recommend a LOCK to grab before entering. That could be done in application code with a call to SYS$ENQ(W), or you could punt that effort and have RMS do the heavy lifting.

Just try to open ( DCL or in the code )a file exclusively. If you get it, then you are the only user in the cluster. If not, then report. And you can use simple tools like SHOW DEV/FILE to see who 'has' the application.

You can also use a record lock, after opening a file shared. When using a record lock you get the free option to wait for the lock to become available ( DCL: $OPEN/READ/WRITE/SHARE=WRITE + $ READ/WAIT/TIME=x. Code: RAB$V_WAT + RAB$V_TMO + RAB$B_TMO )

>> This combined with login timeouts should get me past the auditing reqs for now.


>> the application is written to run from a single session, which is why I want code to check that another valid user is present before it runs.

Again, Perhaps you mean checking that an other user is NOT present?

>> Eventually I will have to redesign the app to be runnable from multiple sessions.

Hmmm, you kinda have to go out of your way in OpenVMS to make an application NOT handle concurrency. If the lack of concurrency is due to a single resource (file?) then that's your application gateway. Use nothing additional. Just try to get it and decide according to result

Cheers,
Hein van den Heuvel
Robert Gezelter
Honored Contributor

Re: Dual control using UAF features

Bill,

Some recent postings raised a question about how the problem is being described.

When I wrote my original answer, my understanding was that this application requires two people to concur in the operation, as is an accounting/auditing procedure similar to the rules for handling bank night drop deposits, or for that matter the "two-person" rule in various classification regimes.

Some recent posts have raised the possibility that the requirement is an exclusion (one user at a time).

My re-reading of the original post seems to reinforce my original interpretation. If this is so, then there is perhaps a way to do this, although it is a little more detailed than I would want to detail in an ITRC post. It is not simple, but it would appear to work in to implement the situation as I understand it.

If you are interested, please let me know. If my interpretation is incorrect, I do not wish to put the ITRC thread into a needless digression.

- Bob Gezelter, http://www.rlgsc.com
Bill Hallman
Occasional Advisor

Re: Dual control using UAF features

This is a dual control app; there needs to be two users present to continue, so yes Robert you answered the right question. I want to have a solution that is a callable routine that can be inserted in the app at whatever point(s) the users/auditors require to ensure dual control.

The app now runs from a single executable, and thus cannot be run from multiple sessions, which is what I meant when I said I may later redesign to run from multiple sessions.

I am narrowed down to two options. I have written a DCL routine that can be called with $SPAWN to run F$PID to look at current processes (it will need GROUP priv) to ensure another valid user is logged on. One weakness of this is that being logged on does not necessarily mean presence, but since the operating environment (dual control to the room, etc.) helps ensure duality it shoud be OK.

Another option is to do an SSH connect to the local node using a username and password entered into the program. This ensures presence (the user has to be at the keyboard at the time) but is also requires the VMS password be entered into the program, which auditing may grump about. Also, I'm not sure how to do an in-program SSH call, at least quickly. If we decide to go that way, I could put it into $SPAWNed DCL instead of the PID search.

I expect some flak from this group about using DCL, but it at least it is quick and better than what we've got now, and hopefully even if the auditors write it up, theu won't decertify us, which they threaten to do with our current setup. All of this has to be implemented quickly, along with PWDMIX enforcement and all the other stuff I have to do. Anyone else have the problem of additional auding requirements (at least in my industry, credit card processing) and additional burden w/o additional resources?
Hoff
Honored Contributor

Re: Dual control using UAF features

Flip this around and see if y'all want to be holding the bag when your servers are attacked. VMS hasn't been very well tested against attacks, and I'm cautious around its security given DEFCON and related.

As for DCL, the implementation language is immaterial. It's the implementation and the security that matters; focus on the goals.

I would look to use the lock manager to cause just a single copy of the application to be running at any one time, and would likely use the ACME call and likely a two-password user login for the requisite security.

As for mandates and such, that's the modern era. And given what I've seen of recent targeted attacks (and having gotten caught up in two separate and successful credit card breaches), these auditors are uncharacteristically mellow about this stuff.
Robert Gezelter
Honored Contributor

Re: Dual control using UAF features

Bill,

I would rather take a discussion of the particulars of this issue offline.

Eliminating DECnet off-node traffic in this environment is understandable. Within a node, SSH2 is not encrypted either (it is encrypted when it is within TCP; not before). This may be a case of "Checklist" compliance enforcement. However, that is another question.

The problem is the enforcement of the proverbial "two-person" rule for certain actions. This is the cash counting rule, and in a more dramatic context, the well-used "two man launch authorization rule". Checking that a second process is logged in might pass audit this time, but I would not want to place bets on it.

As I said, I see a way that you could go in this direction, and be fully supported, but it requires more than a discussion on ITRC.

I will be happy to speak with you offline.

- Bob Gezelter, http://www.rlgsc.com
Richard J Maher
Trusted Contributor

Re: Dual control using UAF features

Hey, hold on a minute there Tom Cruise! Stop trying to cut Bill out from the bait-ball and isolate hime from his traditional support networks. I know the phrase "credit card company" must be flashing *deep-pockets* up on everyone's screen and times are tough, but if we can all mange to conduct ourselves with a modicum of decorum then I'm sure ITRC will be a much nicer place.

Wow, this must be what Bootcamp is like? "He'll never make the coffee urn!" "I got the toilets covered" :-)

Dang, I don't have anything useful to say, again :-) Hold-on here it is, I believe LMF uses user-mode locks for concurrent-use license checks; that could be a good start for your "How many users" check?

Cheers Richard Maher

PS. Hey Hein, how 'bout that ludicrous piece of over-engineering that is the VMS Message Facility eh? I mean why Microsoft copied it almost verbatim is beyond me. If only they had've talked to you and others here and we could have done away with that whole facility, number ,severity, and flags bizzo. Just a simple UNIX 1 or 0 eh waddayareakon? Everything else redundant? I mean it's not as if anyones gonna check it.
Hein van den Heuvel
Honored Contributor

Re: Dual control using UAF features

Bill,

If all you are going to do is to poll for an other username/pid to be there, then perhaps consider the simple record lock approach. No privs needed.

First-user:
Get record with some 'key-1' with short time-out + wait
If you can get it, fine. Keep it.
If you can not get it, someone else is using it. Report and bail.

Now (try to) get record with 'key-2'.
If you can get it then the other user is not or no longer, there. Report and wait.
If you can NOT get it, then the second user must be there. Proceed.

Second user:
Get record with some 'key-2'.
If you can get it, fine. Keep it.
If you can not get it, someone else is using it. Report and bail.

Now TRY to get record with 'key-1'.
If you can get it, release it. Report that user-1 is not active yet and wait.
If you can NOT get it, the report user-1 as present and proceed.

General:
Use ACL's on the file with the two records to control who can play. You could use en entire file as a lock, or records within the file. (RMS) record lock come with nice time-out and wait option even through DCL.

If you use a private lock in the program then you can have both users queue up an async lock for the other key, and thus can be immediately notified when the user/process goes away. Of course that will look like a deadly embrace to the OS, so be sure to specify LCK$M_NODLCKWT on the SYS$ENQ call.

Richard>> Hey, hold on a minute there Tom Cruise! Stop trying to cut Bill out from the bait-ball and isolate hime from his traditional support networks.

Agreed.

Richard>> PS. Hey Hein, how 'bout that ludicrous piece of over-engineering that is the VMS Message Facility eh?

Yeah yeah Richard. You are so funny, it is almost sarcastic! Wait, the other way around!
I know that you know that I know when and where to test for flavors of success/failure.

My favorite usage example for this the RMS$_CREATED return when using FAB$V_CIF with SYS$CREATE, and similarly SS$_CREATED on SYS$CRMPSC. Both alternate success statuses often indicate to a calling program to do alternate things.
On the flip side, the try for locked record described above requires a test for a specific anticipated failure versus a generic failure.

Anyway, I maintain that most tests for an explicit SS$_NORMAL are in fact incorrect, and born out of ignorance rather than from skill.

Cheers,
Hein