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