Dual control using UAF features

[John McL]

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]

>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.

[Richard W Hunt]

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.

[Hoff]

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]

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.

[Hoff]

With that three-week schedule cited earlier, you're getting a little short on time to get this stuff designed and reviewed and developed and debugged and deployed.

You could use the referenced $acmw code to implement two one-person logins using two calls into the posted code, or could implement a two-password login using a variation of that $acmw code; the two-password login mentioned earlier. This latter case if you need have neither user individually with the extra access that username grants. These two could each comprise your option one. And they get your code (mostly) out of the loop; you're using OpenVMS authentication and rather less of your code.

Either of these solutions (depending on how it is implemented) might not be completely secure, but less code and simpler code is generally better code when security is involved.

Certainly get the auditors and your management looking at and approving the design, whatever you choose to implement here.

I personally won't try to get an approach based on DCL and SPAWN and such past the auditors. Not with credit card data.

[John McL]

Bill, just a thought ...

If you, or more importantly the auditors, are satisfied with the security of individual user logins then maybe you can devise an app password system that can be transmitted in an SSH command in plaintext.

You could use single-use passwords where seeing one or even a few of them provides no useful information to break into the system. The sender and receiver just have to agree on what's in the transmission. Typically you'll have a long sequence of agreed passwords and when one password is used, both step to the next one password in the sequence. Naturally the sending of a password will be outside manual control.

Maybe have an encryption key at both ends that gets XOR'ed with the one-time password and make sure you regularly change that XOR key. You could even get right into how ATM machines make connections to their hosts (which I vaguely recall is 128 bit use of the system prior to DES).

I see an issue if you are using SYSUAF to verify the password at the receiving end but maybe for this particular application you either have no VMS passord and handle it yourself or you introduce a new VMS password algorithm on your system that for the application account does its own handling but passes all other usernames to the normal password algorithm.

As I said, just a thought ... better to have too many options than not enough.