SSH / SFTP file transfers and rights identifiers

[Richard W Hunt]

Site is U.S. Dept. of Defense. Host is Alpha ES40 running OpenVMS 8.3, patched fairly well, and TCPIP Services for OpenVMS 5.6-9 ECO4.

Problem: We have a class of user bound to a character-graphic menu system. We cannot upgrade the s/w to use X-Windows menuing because of the cost of such an effort.

The menu application provides its own security by not giving the user any kind of browsing capability. They can only run what the menu presents to them and cannot specify file names or paths.

Normally we just e-mail their reports in cleartext. However, at least a couple of files that need to be copied to a user workstation involve Privacy Act information. The project manager wants to grant Secure FTP access to some users to transfer the files. Here is where the wicket gets sticky.

The user workstations are non-VMS Dept. of Defense desktops that don't have access to encryption or decryption utilities. So I can't encrypt the file before sending it and just have the user decrypt it.

Under the menu application, we use rights identifiers to grant users access to other directories. The application makes the decision as to when it needs to make that file call transparently to the user. The rights identifiers are there so that the file system won't get in the way.

What we want is if they come in through Secure FTP that we would take away the rights identifiers and LET the file system get in the way of cross-directory operations in that case. The SOGW masks are set consistently to force that to occur anyway, so no big deal. Except...

SFTP is a sub-protocol of SSH. When you come in through SSH you don't know until the user's connection is established by TCPIP$SSH whether this will be an interactive or SFTP session. The session that decides this runs as non-privileged TCPIP$SSH, not as the user. So TCPIP$SSH cannot "adjust" the user's settings. I cannot find a script associated with invocation of the TCPIP$SFTP_SERVER2.EXE process.

When the session is interactive, you go through SYLOGIN.COM and LOGIN.COM normally. In that context, you could alter the identifiers and take other tailoring actions in one or both of those login files.

But SFTP is a sub-process that does not go through either .COM file, even though it is running as the individual user and its parent is a TCPIP$SSH process. (I've checked. It just springs into existence.)

I'm looking for a "hook" that I can use to trap the new child process and force it to execute some sort of DCL sequence so that we can do something like

SET RIGHTS_LIST ident /DISABLE

in the case where it is an SFTP operation.

We also looked at the reverse logic of bringing up the identifier already disabled and then using the LOGIN.COM to re-enable the identifier if it is an interactive process. However, identifiers are not like privileges. I can grant a privilege but make it not be a default privilege. I can't do the equivalent operation on an identifier. If you have it, you have it immediately, period.

TCPIP$SSH goes through these logins, but setting or clearing the identifiers there does no good. TCPIP$SSH isn't the account that has the identifiers in question.

I'm looking for any place to hook in this kind of operation to enable or disable identifiers, but so far no joy. I've read the manuals but they offer no insights about this level of tailoring. Can anyone offer suggestions on how to get past this roadblock?

[Hoff · Accepted solution]

Try combining a subsystem identifier on the SFTP executable with a composite ACL on the target object. If the user has both (for instance) SFTP_IDENTIFER+USERFOO (identifiers can be cumulative in an ACE), then the ACL on the object grants access, or denies access. The former identifier is from the subsystem identifier, and the latter is assigned to a specific user, or group of users.

Massive hack, of course.

Given your particular environment, it may be viewed as far more appropriate to do what your management seems to expect here and to cease attempts at security innovation within the assigned constraints, and to simply ask your management for guidance on how to configure security.

[Jim_McKinney]

> a "hook"

I imagine that this SFTP is essentially the same as the one bundled with MultiNet that I'm familiar with. If it is, you can see the SFTP command procedure that activates the SFTP server by using two sessions - in the first session, SFTP to localhost and log in - in the second session, a "SHOW DEVICE/FILES" of the first session's default disk will reveal the command procedure's name. You can TYPE it out. Hooks, none apparent...

...anyway, this is not really a hook, but, I imagine it will work. Consider coding up a little program that performs only a lib$do_command() where the argument is a descriptor pointing to the string "@your_command_procedure". your_command_procedure will contain all that stuff you wanted to hook in (perhaps make this conditional so that only the chosen experience it). Copy the original TCPIP$SFTP_SERVER2.EXE elsewhere. Call your new program TCPIP$SFTP_SERVER2.EXE and place it where TCPIP$SFTP_SERVER2.EXE is located (SYS$SYSTEM I presume?). And finally, in that command procedure that you've written, RUN the copy of the original TCPIP$SFTP_SERVER2.EXE from whereever you've placed it. If the original TCPIP$SFTP_SERVER2.EXE was installed with privileges you'll have to replicate those on the copy.

Should you take a route like this you will have to consider that future upgrades may want to replace your program with a new one - in that event, you'll need to shuffle. That new one will have to replace your copy of the original and you'll have to refresh your lib$do_command() program.

[Richard W Hunt]

Thanks, Hoff, but our managers finally bowed to the inevitable once I showed them hard and fast evidence that there was no hook from which to hang this hat in any reliable way.

We are going to make a MINOR mod to the app for the users who need this feature. When they write one of these files, we will write it to an area other than their home directory. It will be the directory of a second account that is network-enabled but has NO identifiers and is in a radically different user group.

The SOGW masks for the directories that worried us all had W:nil so this will keep the files secure enough. It was the identifiers that cause the headache.

If the user really, really, REALLY wants that file, they can build it from account A and retrieve it securely through account B. If they are going to make us go through the trouble of doing this, we'll let them go through some of that trouble in return, including a second login.

In a way, Hoff, I'm glad that you had to suggest a somewhat "hacky" way of getting around the problem. I would hate to think I had totally missed something somewhere.

[Hoff]

The ACL solution using subsystem identifier does use only supported interfaces, BTW. It's just not a solution anybody building and maintaining sftp probably ever thought of.