How to create a privileged COPY command?

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