Operating System - OpenVMS
1748102 Members
4650 Online
108758 Solutions
New Discussion юеВ

Re: Dual control using UAF features

 
Steve Reece_3
Trusted Contributor

Re: Dual control using UAF features

Hey Bill,

If you want to make sure that two users are present, the best way that's easy to implement would be to have a primary and secondary password on the VMS account. That would mean that the two users could use different passwords, but would, of course, rely on users not sharing those passwords with each other.

Otherwise, as someone has already commented, get the second user to take a specific named lock out and only allow access to the application when that lock has been taken. That should be usable when you redesign the application to be runnable from multiple sessions too.

Steve
Hoff
Honored Contributor

Re: Dual control using UAF features

As for whatever solution you pick (DCL, ssh, $acmw dual-password, etc) solution, clear that with your management and with the auditors. As much a hassle as auditors can be, ending up holding the bag for a data breach is a far bigger hassle for all involved. Handling the design-affirmation decision to the auditors and the management is generally goodness. Avoiding the aftermath of a data breach is definitely goodness. (pun intended.)

As for that $enq locking stuff I mentioned earlier, here's an intro into locking on OpenVMS:

http://labs.hoffmanlabs.com/node/492

Your application would acquire an exclusive lock on an application-specific and locally-chosen lock resource name, and that will block other parallel access to that resource among all cooperating application invocations locally and (transparently) within the cluster.

Scanning for processes matching a target usually works, but (having seen enough of these weird cases over the years) tends to be as much or more work and more code as using the lock manager, and the process scan tends to have the occasional timing window or degenerate case.

The more that you can use system services and VMS RTL calls here (rather than rolling your own resource and security-related code), the easier it'll be to get your code past the auditors, too.
Robert Gezelter
Honored Contributor

Re: Dual control using UAF features

Richard,

Your comment about "Stop trying to cut Bill out from the bait-ball and isolate hime [sic] from his traditional support networks. ..." is uncalled for.

Things may be far different in the "land down under", but here in the USA, compliance is a serious legal responsibility issue [emphasis on "legal"]. Everything on ITRC is cross-referenced by various search engines. Today's New York Times providentially had a front page article entitled "How Privacy Vanishes Online" by Steve Lohr noting how statistical correlations of mined data can strip anonymity (see http://www.nytimes.com/2010/03/17/technology/17privacy.html ).

If there is a future breach of security, this conversation could quite possibly be used against the poster. I have seen it happen to people. It can be extremely embarrassing for all concerned.

When I sense the presence of an issue that is best not left in a public forum, I routinely speak to people off-line and offer some guidance, as a contribution to the community, pro bono.

I would not want Bill to have to be confronted with that contingency. I would rather he have a solid understanding of the issues and limitations without the dialogue being public.

Several years ago, we had an episode in the US involving a self-help group. The end result was a ruling that anything said in a self-help group was fair game in a legal context. If it had been said to a health care provider, attorney, or cleric, it would have been protected.

While IT professionals can sometimes operate without worrying about non-technical issues, compliance is a mix of both, which makes it a potential mine field.

All of that said, I disagree with most of the solutions proffered. The requirement, as I understand it (some background with the PCI specification outside of this thread) is an implementation of the two-man rule (sexism unintended, that is the terminology, it is really the "two-person" rule).

This means:

- NO SHARED PASSWORDS
- INDIVIDUAL AUTHORITY/ACCESS REVOCABLE AT ANY TIME

How does one accomplish this? Not by checking whether another user is logged in. This can be hacked in any number of ways.

One can do this in a variety of ways, but they all involve some degree of subtlety. One way to do it is leveraging time limited certificates issued by a CA, ala Kerberos. Then each user can separately approve the action without creating the potential for Trojan Horse attacks. Each user would log into their normal OpenVMS account or menu. Requests would only be valid if they were digitally signed by at least two authorized requestors (and the data could include the PIDs to ensure that the PIDs were both in the machine room).

The preceding is only a rough approximation of what is needed.

Applications level security outside of the OpenVMS model is always limited to the trustworthiness of the application (which may be spoofed). Additionally, such home-brew security does not leverage the audit and other features of OpenVMS.

- Bob Gezelter, http://www.rlgsc.com
Hoff
Honored Contributor

Re: Dual control using UAF features

Certificates would certainly work; that has some advantages here. Like deferring the authentication processing over to VMS, deferring the authentication and authorization over to Open Directory or AD or other such is (also) goodness.

As an application programmer, get out of this authentication business and this processing where you can. And whenever you write this or related stuff, get it reviewed and cleared.

Regardless of the authentication mechanisms, I don't see a way to keep this particular hunk of code outside of the trusted base. This code is still making a "go no-go" decision.

And how the application would prompt the folks to authorize this in parallel (without using something "easy", like the dual-password login and two local users gaining access for an application-defined "special" username created within OpenVMS) is also specific to the UI you'll be using to garner the authentication.

As I mentioned earlier, this area is fairly hairy for a (now rather less than) three week deployment schedule.

ps:

On re-reading my text:

>Handling the design-affirmation decision

that was intended to be this:

Handing the design-affirmation...
John Gillings
Honored Contributor

Re: Dual control using UAF features

Bill,

I'm not sure I understand the process flow here. If it's something like "we need two people standing at the same screen to start running this application"? If so, I think Steve Reece is on the right path.

Protect the application so it can only be run from a specific username. Make that username captive so all it can do is run the specific application. Make the captive login check for other instances of itself and limit to whatever number you like. Give it two passwords, one for each user. Problem solved? You may go even further and require the username to be entered from a specific login source (like one of the authorising users).

For event deeper security protect your data files with subsystem ACEs so they can only be accessed via the application(s).

Since you're in control of the application you can include a short command prompt timeout so the application automatically closes itself. Ensuring the continuing physical presence of both users is more difficult.

With modern hardware, process creation and login is no longer as slow as they once were. The need for complex procedures which essentially do nothing more than avoid an extra login are no longer necessary. Use the login to give you free auditing, accounting and, in this case, dual password protection.

Hein's two record algorithm will probably work, but make sure you analyse all the timing windows for potential deadlocks. Two locks being acquired in opposite orders always rings alarm bells (though the second action succeeding through failing to acquire the lock means it's more likely that timing flaws will result in false negatives than deadlocks).
A crucible of informative mistakes
John McL
Trusted Contributor

Re: Dual control using UAF features

Bill,

At the moment I'm thinking that if you have an equivalent to SET HOST 0 available in SSH then you could have user accounts that have an identifier that allows them to access and run a command procedure that basically does that SET HOST 0 equivalent and logs in as a third (and captive) user to get to the application. The users enter the new password interactively, it's not embedded in the procedure.

As John G says, make this 3rd account handle the checks for simultaneous access. You can also handle the locking via a file or files that have only owner access and are owned by this username.

I think this system will give you
(a) individual user accounts (at the top level)
(b) individual passwords and a generic password for the app, only the relevant people being told the latter
(c) management of passwords and account access via normal utilities (e.g. AUTHORIZE)
(d) auditing via VMS accounting and the VMS security subsystem
(e) in-house control over simultaneous access

If you put an audit ACL on the code that does the equivalent of SET HOST 0 then you'll know who has been logging in to access this system. Maybe SSH passes than information through to VMS and you can use it to both manage the access and audit it. (Audit is an after-the-event approach to security - it's better to control access before the event.)

Ongoing checks for continuing dual access should be easy because the same username is involved. (Checking that the output of the command $ SHOW USER XXXX is 2 would be a simple way at DCL level, but perhaps you want more than this.)

Brad McCusker
Respected Contributor

Re: Dual control using UAF features

>I'm not sure I understand the process flow
>here. If it's something like "we need two
>people standing at the same screen to start >running this application"?

I agree with John, I'd like clarification of this point. How exactly do these two peoples actions flow and interact.
Brad McCusker
Software Concepts International
Richard W Hunt
Valued Contributor

Re: Dual control using UAF features

After reading all of this, I wish to offer my two cents' worth:

This is clearly a case where "divide and conquer" makes a LOT of sense.

First, using a password policy routine and the PWDMIX flag in SYSUAF, you can get complex passwords in any rules you want, with mixed case, punctuation, mandatory balance of the UPPER, LOWER, DIGIT, and PUNCTUATION pieces/parts.

I'm at a Dept. of Defense site where we deal with things that need to be secure according to DoD rules for FOUO/Sensitive data. SYSUAF and PWDMIX and a good password policy module met that rule and nobody has since bothered me about it. So I know about the security auditors and what they want to see.

Second, once you are logged in, you run into the application-level question. You have an app that requires a tell-me-twice sort of logic. It seems to me that you can make life crazy for yourself here by over-engineering this puppy.

It may well be too late to think this way, but I will ramble along anyway just to give you some ideas, maybe. I think a good model for this would be a detached process that does the real work and you only run a "console" for the app. The console only needs enough privileges to play with temporary mailboxes.

The real app is privileged and detached, so no one controls it except through its special interfaces. In my mind, client-server logic is best for this. The detached app opens one mailbox for input - using CREATE_MBX, for example. Your consoles each open one MBX for input.

Now, your non-privileged session that really can't do squat opens up the console code. You trigger one of the events you want triggered. Your privileged app then sends you a reply "Waiting...." and - it waits for another process. Your partner - on his/her copy of the console - sends a "Do this thing" message and the console replies "Validating...."

The messages can contain three things (minimum): Your PID, your mailbox name, and the code you wanted to execute.

The privileged program in detached mode can then run GETDVI calls on each mailbox to verify who owns it, then GETJPI on the owner to verify that the owner process in question is a validated login. If it asked YOU who you were, you could lie - but if it asks VMS, you'll always get the true answer.

The program, being detached, is not controlled by ANY terminal, can log what it wants to log, can ignore what it wants to ignore, and won't do anything without inputs that follow the rules you have defined. So if you use a detached nucleus to implement the tell-me-twice rule, that might be enough for your auditors.

You could build this detached nucleus from DCL except that when you use READ or WRITE from DCL on a mailbox, you are synchronous. That might not be what you wanted. From a compiled program, the I/O can be asynch if that is better for you.

Using the O/S to ask the questions from behind the separation of process-private memory (in the detached process), that security is harder to break. Still not impossible, but a lot harder.

Other wrinkles would be that the persons authorized to do this have specific rights identifiers - which would be visible to a GETJPI performed by the privileged program.

Anyway, where I'm going with this that you are chasing the wrong fox when trying to make VMS do both parts of this for you. VMS is good for securing logins and assuring that logged-in users presented credentials. Once you are in, your APP has to apply the second layer of rules.

This is why I suggested Divide and Conquer. Let each piece play its part that it plays best and then assure that auditing is turned on when you do it.

Sorry if this turns out to be a distraction, but it might at least let you see that the problem is potentially soluble.
Sr. Systems Janitor
Hoff
Honored Contributor

Re: Dual control using UAF features

Remember that this stuff:

/The messages can contain three things (minimum): Your PID, your mailbox name, and the code you wanted to execute./

is a target for attacks. Given the potential monetary reward here, you're a bigger target than might be usual. Which means somebody can decide to try to fuzz this mailbox, and to feed it deliberately-corrupt data. Mailboxes make a nice interface between secure and insecure processing, but you need to be very paranoid about what's read out of the mailbox. (I've encountered VMS applications that were vulnerable to attack because of insufficiently-paranoid designs.)
Bill Hallman
Occasional Advisor

Re: Dual control using UAF features

Okay - I've seen a lot of great ideas here. All of them will be considered
when we plan a rewrite in the future. But, as you look back at the original question, the 3 requirements mentioned there are what I have to solve in the next (now) 2 weeks. I am commited to having a working prototype to present tomorrow. We passed the same audit last year due to our compensating controls, but were told for this year (less than 2 weeks ago) that it would not fly (new auditor). So if I can solve the 3 original
problems: 1. Complex passwords, 2. Separate users for tracking and 3. encrypted passwords we should be good for now.

I have decided based on this thread that using an app user and PW, even hashed, is not the way to go. So I will use UAF, and thus have the solution to 1 (thanks, Gillings and Hoff) and 3.

Some of the solutions (such a dual UAF PWs aren't appropriate, as the point is to ensure that two of a possible 5 or 6 users are present (they rotate the duty) and the app has a built-in logging function that must record which user is on. I think the same is true of the various lock manager and
related solutions.

Also, I haven't mentioned that this is the only application on this server, and all users will be captive, except for SYS users and Operators, so at least we have a restricted userbase to watch.

So I have come down to two options, both of
which use UAF authorization to validate the user:
1. Require two valid users (current and one other) be logged in, or
2. Do a connect to the node with a valid user and password.

A weakness of 1. is that an existing process does not guarantee a personal presence. We have other compensating controls that the user group manager believes will let us get around that this time (i.e. procedural dual control checking that the processes are logged out at the right time.)

A weakness of 2. is that it requires that the program capture the password, so we still have to prove that the code does not do something nefarious with it.

Option 2 (the non-DECnet DECnet solution) seems to have the problem that you can't provide a command line password to SSH routines, like you can with DECnet or FTP (am I wrong?). I won't write the passwords out to a file to build an SCP2 or SFTP script, and certificates seem to defeat the purpose (I need a valid password entered at connection time.) I might use FTP anyway, since it is still a big improvement over what we have now. More advice on passing the PW info to an SSH utility (SCP2, SSH, SFTP...) would be appreciated.

I'm going to do it 1st with a spawnable DCL routine, and revisit it later when
we do a redesign of the security model.

By the way, Robert, we just passed PCI barely, based on our compensating controls), this is a different audit with different requirements, just to make life more interesting. No doubt PCI will get to it next time. I believe the 2 auditing groups are actively trying to be different from each other because they just don't like us (kidding). (kinda). The physical requirements they want make this stuff into child's play.