How to create a privileged COPY command?

[Clark Powell]

I would like to create a privileged copy command (with a different name like PRIVED_COPY.EXE) I'm guessing that I could make a copy of COPY.EXE as PRIVED_COPY.EXE and install it with privs required to do the copy. But I'm not sure how to do the set command part. I'm thinking it would be most useful to run set command on a process level every time it needs to be used. I would like to not mess with the DCL Tables, of course.

The object would be to create a program that makes an audit log of who, when and what files are copied to a protected production directory. The directory can only be accessed with privilege or by using this program with an audit trail.

Any ideas out there?

[Robert Gezelter]

Clark,

How about skipping the privileged executable and setting the appropriate settings in the target directory to:

- allow the writer to write to the directory; and
- turn on auditing on the directory.

(Am about to go on a conference call, otherwise would sit down and gin up the example).

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Clark,

For a description of ALARM and AUDIT ACEs, see the OpenVMS System Management Utilities Reference Manual (at http://h71000.www7.hp.com/doc/83final/6048/6048pro.html#index_x_34 ), Section 1.3.

Obviously, the documented privileges are required to establish the ACL entries, but they can be defaulted on the directory.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Clark,

Installing images with privileges that weren't designed for that purpose has many pitfalls and potential to create unintended security holes.

Simple example, suppose I used the privileged COPY to overwrite the audit trail with my version of the audit trail?

Much simpler and safer to use appropriate ACLs to allow authorised users to access the directory in question, and generate the required audit messages.

Another option which may not require privilege, look up SUBSYSTEMS in the security manual.

[Clark Powell]

Good idea, Bob. I will explore that. An audit trail is part of what we are looking for.

I should explain that the object is to make our financial auditors happy by not allowing our programmers full, unlogged access to production files. It's not just a matter of keeping the world out, it's keeping almost everyone out except the application itself. Hence my desire to have a program that would only copy certain files to a directory and identify who, what, and when. I'm sure there are other solution so I'm open to suggestions.

[Robert Gezelter]

Clark,

Then you definitely DO NOT want to install a privileged image. However, the ALARM and AUDIT ACEs are designed for precisely this type of requirement.

As they are documented in that way, they are particularly well-suited to satisfying audit requirements.

If I can be of any assistance, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Mike Kier]

I would consider locking down the directory for all users and have an access failure alarm ACE and then add an ACE with access and with audit for one or more designated Identifiers.

Then you can determine just how you want to grant/revoke the Identifiers - manually through Authorize if the usage is low and occurs during hours when a sysadmin can grant it - or write a privileged program with some reasonably good authentication to grant/revoke the Identifier (and log that separately) if there is a lot of activity or you need off-hours access.

[Jess Goodman · Accepted solution]

Clark,

All you have to do after copying COPY.EXE to PRIVED_COPY.EXE and installing it, is to DEFINE COPY as a logical name pointing to PRIVED_COPY.EXE in the login.com of the users you wish to have access to it

That way when these users invoke the standard COPY verb from DCLTABLES, it will launch PRIVED_COPY.EXE.

Be sure to set the file protection on PRIVED_COPY.EXE so that no one can access it except those that were intended to use it. This will probably means you will need an ACL that grants them execute access to the file.

[John Gillings]

re: Jess,

>Be sure to set the file protection on
>PRIVED_COPY.EXE so that no one can access
>it except those that were intended to use
>it. This will probably means you will need
>an ACL that grants them execute access to
>the file.

Yes, but how come you're trusting the ACL on your PRIVED_COPY.EXE to work, when (by implication) you don't trust the same ACL to work on the target directory? Remove the middle entity, just protect the target directly exactly as you're proposing to protect the privileged image.

re: Clark: "it's keeping almost everyone out except the application itself."

This is EXACTLY what a PROTECTED SUBSYSTEM does. You define the subsystem using identifiers, then GRANT the subsystem identifier to an application. Only applications belonging to the subsystem are allowed to access the files. It's much finer control than using general privileges.

See Chapter 14 of Guide to OpenVMS System Security http://h71000.www7.hp.com/doc/84final/ba554_90015/ch14.html

[Robert Gezelter]

Clark,

After considering your question overnight, the ACL solution is IMHO the right path.

Audit requirements include a requirement that all changes be identified, thus the directory needs to be protected against the widest group of users. ACLs on the directory are the solution to this requirement.

A privileged version of COPY does not improve the level of protection. In fact, it restricts operations to COPY operations, which in many situations is not desirable.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

W. (what does that stand for?)

>>>
It's not just a matter of keeping the world out, it's keeping almost everyone out except the application itself.
<<<

Reread John G.'s answer w.r.t. Protected Subsystems!

It can do EXACTLY what you seem to desire, but is NOT limited to COPY operations.

- you need to enable the volume where the application program(s) reside(s) for subsystems
- you need to create (a) SUBSYSTEM identifier(s) (maybe differentiate between Read/Write/Delete functionalities?)
- you install the relevant program(s) with the relevant ident(s)
- you restrict the access to the data structures to be limited to the relevant subsystem IDs.
- create a DIFFERENT set of application IDs, and use those to specify execute access to the application images.

Now,
ONLY authorised users can run (maybe part of?) the application
ONLY users RUNNING the app image have (ONLY the specified) access to the data.

--- In implementing, be sure to read (and understand) the relevant chapter in the Guide to System Security.
It is no magic, but all in all not entirely trivial.

hth

Proost.

Have one on me.

jpe

[Clark Powell]

One thing I'm not getting is how to use the SUBSYSTEM ace. In the docutments there is this line, "The Subsystem ACE applies to executable images only" I'm writing a DCL command procedure.

[John Gillings]

Clark,

Subsystem images need to be INSTALLed, so you can't do it from DCL.

If you can't write an executable image to mediate access to the data files, that takes you back to designing an ACL structure which grants appropriate access.

You're unlikely to be able to write a "secure" DCL procedure to do what you want. If it's possible to do something inside the procedure, it's possible to do it outside as well.

An installed image (subsystem or privileged) is a different beast. You can control exactly what is permitted.

[Hoff]

DCL Tips: Temporarily Granting Privileges:

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

Has some options.

I'd probably use a DECnet task here, since I'm guessing this isn't a heavy-usage application.

There are other options.

Trying to secure a process with privileged and unprivileged code mixed together is to be avoided. That's more difficult to secure, and more vulnerable to attacks.

The subsystem identifier would probably work here, but you can firewall this whole task by passing along a directory specification to a privileged server process via DECnet task-to-task, and have the server do all the work for your user. That's simpler to build and secure, given the only connection between the untrusted and the trusted software is the DECnet link.

If you're just logging stuff and this COPY is a canard, then you might look at the OPCOM REQUEST command:

REQUEST "Hello, I'm Home"

or analogous. That'll log whatever is requested, and where the gremlins can't get at it.

Or look at adding modern operator and system logging onto VMS, rather than the antique OPCOM scheme. syslog and other options do exist.