How to use SUBSYSTEM ACL's

[Clark Powell]

I am messing with a copy of COPY.EXE which I have renamed to SECURE_COPY.EXE. I have created an identifier with subsystem attirbute and applied the attribute to SECURE_COPY.EXE.

SECURE_COPY.EXE;1 138 4-MAR-2011 [100,3567] (RWED,RWED,RE,RE) (SUBSYSTEM,IDENTIFIER=SECURE,ATTRIBUTES=NONE)


I have create a directory with with the SECURE identifier:
OVERRIDE.DIR;1 1 4-MAR-2011 14:14:01.45 [GRP_10,SPGJXT] (,,,)
(AUDIT=SECURITY,ACCESS=WRITE+DELETE+SUCCESS+FAILURE)
(SUBSYSTEM,IDENTIFIER=SECURE,ATTRIBUTES=NONE) (IDENTIFIER=SECURE,ACCESS=READ+WRITE+EXECUTE+DELETE)

I defined COPY to point to SECURE_COPY.EXE but I still am not able to copy. What is missing to make the subsystem acl work?

thanks
Clark Powell

[Hoff · Accepted solution]

This question appears to be a continuation of this thread:

http://h30499.www3.hp.com/t5/System-Management/How-to-create-a-privileged-COPY-command/m-p/4750164#M28245

For subsystem identifiers, here is the relevant manual:

http://h71000.www7.hp.com/doc/84final/ba554_90015/ba554_90015.pdf

Within that document, here are the relevant sections...

Create the identifier per page 183, with the subsystem attribute.

Configure the ACL per page 291 and following.

Enable subsystem identifiers on the volume per page 294, if the target disk is not the system disk.

Ensure the directory path is accessible appropriately, per page 296.

See a complete example of the sequences and command involved starting on page 301.

Troubleshoot access errors using security audits (and preferably on a relatively quiescent system), circa page 228 and elsewhere in the documentation, and typically via a one-shot enable command similar to this:

SET AUDIT /ALARM /ENABLE=ACCESS=FAILURE=ALL

And then with a process configured for receiving the audits via ANALYZE /AUDIT command or (often faster) via alarms via REPLY/ENABLE=SECURITY or analogous.

These alarms can be useful in tracking the specific trigger for the error. This can be a file or directory other than expected, depending on (for instance) the directory path.

The full VMS documentation set is available at:

http://www.hp.com/go/openvms/doc

and the documentation shelf is well worth a review when you have a question. Google can be used to search within the shelf by adding the following somewhat arcane keyword onto your search:

site:h71000.www7.hp.com

To target the specific host server with (most of) the OpenVMS materials available at HP.

As for alternatives for the task discussed from the other thread, here is DCL Tips: Temporarily Granting Privileges:

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

For the original question, consider 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 best avoided. That's more difficult to secure, and more vulnerable to attacks.

While the subsystem identifier would probably work here, you can more easily 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 the core requirement is logging, then you might look at the OPCOM REQUEST command:

REQUEST "Hello, I'm Home"

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

Also look at adding modern operator and system logging onto OpenVMS, rather than the antique OPCOM scheme that is the default. Versions of syslog and other more modern logging options do exist for OpenVMS.

[Ian Miller.]

Did you mount the disk /SUBSYSTEM ?

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

[Shriniketan Bhagwat]

Hi,

Refer the HP OpenVMS System Management Utilities Reference Manual which explains about the ACEs from the below link.

http://h71000.www7.hp.com/doc/83final/6048/6048pro_001.html

Refere the Example of a Protected Subsystem from the below link.

http://h71000.www7.hp.com/doc/84final/ba554_90015/ch14s09.html

May be helpfull.

Regards,
Ketan

[John Gillings]

Clark,

What you're proposing probably won't work the way you intend.

If you take the EXISTING COPY.EXE image and configure it as a subsystem image, anyone who can execute the image can access the subsystem files.

If that's all you want, then just protect the files with an ordinary ACL in exactly the same way as you're intending to protect the copy of COPY. The net result will be exactly the same, with far less complexity.

The point of a subsystem is to allow you to write your own image, with the knowledge that acccess to subsystem objects will only be permitted while the image is running. You can therefore write your own checks, audits and other stuff in a secure manner.

Taking an existing image, the internals of which are out of your control, which was never intended to be used as a subsystem image is unlikely to work.

[Robert Gezelter]

Clark,

I agree with John, and repeat my comments from the earlier thread.

Subsystems IMHO are for a different purpose. The correct method is to put the ACL on the directory and use the Audit Logs. This is far safer.

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

[EdgarZamora_1]

Clark,

I agree with John and Bob. You're making this a lot more difficult than it has to be. Your original goal:

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

All you need to do is:

1. Turn on auditing for that production directory and its contents (see SET SECURITY /ACL=(AUDIT=SECURITY...))
(Make sure to send the alarms to audit file)

2. Create an ACL identifier which you will grant to non-privileged users who will access the files in that production directory. (See AUTHORIZE... ADD/IDENTIFIER and GRANT/ID)

3. Add this ACL to the production directory and contents

4. Write a script to automate the reporting of the accesses to the directory/files and make your reporting as fancy as you like. (See ANALYZE/AUDIT)

Hope that helps to get you started.

[Clark Powell]

I'm still interested in the SUBSYSTEM ACL's so can anybody tell me why disks are not mounted with the /SUBSYSTEM qualifier as default? Is it just to save memory (and probably not a big deal in these days of cheap memory,) or is there an IO performance hit associated with mounting /SUBSYSTEM?

[EdgarZamora_1]

I don't know the answer to your question about mounting /subsystem. I'll leave that to the internals guys to answer.

I am attaching a sample log of the steps I had outlined in my previous response... to help out. Customize to suit your needs...
Most of your effort would then be in writing DCL code to retrieve records from the audit file and format and report the information the way you desire.

Hope this helps.

[EdgarZamora_1]

Oops... forgot the attachment?