Open VMS BASIC programming Doubt

[sreeraj7]

Hi All,
I have a doubt on the follwing scenario,
A program written in BASIC that run under a user account tries to rename a file in a disk.
This user has been denied privilege to do rename,delete,copy etc on this disk.Hence the program bombs.Is there any soulution to rename the file under user account through the program?
I would appreciate if you could help me to sort out this issue?
Looking forward to hear from you.

[Jan van den Ende]

sreeraj7,

To begin with,

WELCOME to the VMS forum!!

Your question essentially has 2 solutions.

The quick one: INSTALL the program with privilege. If the file owner is in the same UIC group as the user, then GRPPRV is sufficient, else, SYSPRV is needed.

This is maybe a crude weapon for the problem.

The second one is much more sofisticated, but also much more system management work.

- enable protected subsystems on the device that holds the .EXE
- create an identifier specific for this purpose
- INSTALL the .EXE with this identifier as SUBSYSTEM identifier
- add an ACL entry to the files to be protected, requiring the susbsystem identifier for the protected access modes.

Now, only when running the .EXE does the user have the specified rights to the file.

--- and it is also possible to add (another) identifier as EXECUTE ACL to the EXE file, requiring the user to hold THAT identifier to be allowed to RUN that image!

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

sreeraj7,

I concur with Jan, to the extent that a protected subsystem is the best answer. Installing the program with privileges in this context is far more power than is needed.

In a protected subsystem, the ability to manipulate the file (and only that ability) is available to the user only when running the identified image. Thus, there is no danger of unexpected and unintended leakage.

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

[sreeraj7]

The program which the user run is from a menu.

[Jan van den Ende]

sreeraj7,

well, if the program is run from a menu, AND, the user is NOT allowed out of the menu (nor are other users), THEN (and only THEN) you can SET PROTECTION on the file to W:RWED.
(on more modern versions of VMS that has been superceded by SET SECURITY, but SET PROTECTION still works, and is good on all versions)

hth

Proost.

have one on me.

jpe

[Robert Gezelter]

Jan,

With all due respect, I cannot disagree more strongly.

Just because the user is supposed to be trapped in a menu, does not guarantee that other programs available from the menu are well behaved (and for that matter, nowhere was it stated that the users were CAPTIVE).

If an auditor looked at the security properly, then the only solution that addresses the problem is a secured subsystem.

Otherwise, there are potentials out there.

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

[Jan van den Ende]

Bob,

it all depends.

Fundamentally, you are right.
In todays, environments, trained to handle things "the Micro$oft way", the non-availability of Quick & dirty (but non-secure) solutions is considered a deficiency.
This is such a solution.

I do admit that I should have stressed the security issues (much) more.

fwiw

Proost.

Have one on me.

jpe

[Hoff]

That the program "bombs" implies that the program contains errors in its handling.

Installing an image with privileges is tossing the programmer into the deep end of the programming pool. I know how to code a program to operate as an installed and privileged image, and it can be a massive security hole if you're not really careful. It can be a security hole if you are careful.

For instance, you have to have some sort of filtering to avoid one of these applications from, say, renaming SYSUAF into the weeds. Or a file within the application environment, but one intended not to be overwritten -- such as the application LOGIN.COM.

As for required programming practices with an installed image, you have to ensure the privilege is reliably shut off immediately after image activation, and only enable the privilege around the particular rename.

The quick-and-dirty approach may well involve a resource identifier, and operate the whole of the shared file storage environment under the identifier, and grant the identifier to the user and/or to the application. But then yes, the next solution in sequence is to use a traditional subsystem identifier.

If identifiers are not sufficient for the task (which is unlikely in this case), the next step would be to communicate with a (trusted) server process that performs the privileged operation(s); a design that disconnects the user-accessible pieces from the privileged pieces, and puts in place some basic messaging that can block typical attacks. (And if you use this client and privileged server approach, just like you would code a network connection, don't trust anything provided by the client.)

Privileges are a last resort approach in my usual playbook. Auditors absolutely zero in on privileges; installed privileged images are absolute audit magnets. And privileged images require approaching the environment with a level of defensive programming that is rarely usual, and rarely needed with an approach based on subsystem identifiers.

Stephen Hoffman
HoffmanLabs LLC

[Dean McGorrill]

I used to cringe at installed images with privs while doing system management at DEC. esp in house applications where management
ordered it. re throwing the programmer in the deep end of the pool, I like that. Dean

[John Gillings]

Hang on! What's the issue here? All this talk of installing images assumes the problem is to allow the user to perform an operation on a file that privilege and protection settings deny.

First step is to handle the NOPRIV condition, so the program doesn't crash. Just issue the NOPRIV message and continue.

Second step... if there are files which the current security settings are denying access to, BUT you WANT the user to have access, then the security settings are wrong (by definition!). So, grant access to the user, either by protection mask or ACL.

Granting privilege to the image, or implementing a protected subsystem is a very complex and costly way of fixing a flawed security model. Yes, they have their place, as far as I can tell from the problem description, this isn't one of them.