topic Re: Open VMS BASIC programming Doubt in Operating System - OpenVMS

Open VMS BASIC programming Doubt

sreeraj7 — Fri, 19 Oct 2007 04:56:27 GMT

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.

Re: Open VMS BASIC programming Doubt

Jan van den Ende — Fri, 19 Oct 2007 05:34:30 GMT

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

Re: Open VMS BASIC programming Doubt

Robert Gezelter — Fri, 19 Oct 2007 06:29:25 GMT

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

Re: Open VMS BASIC programming Doubt

sreeraj7 — Fri, 19 Oct 2007 06:33:52 GMT

The program which the user run is from a menu.

Re: Open VMS BASIC programming Doubt

Jan van den Ende — Fri, 19 Oct 2007 06:49:16 GMT

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

Re: Open VMS BASIC programming Doubt

Robert Gezelter — Fri, 19 Oct 2007 07:17:38 GMT

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

Re: Open VMS BASIC programming Doubt

Jan van den Ende — Fri, 19 Oct 2007 08:38:52 GMT

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

Re: Open VMS BASIC programming Doubt

Hoff — Fri, 19 Oct 2007 10:16:43 GMT

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

Re: Open VMS BASIC programming Doubt

Dean McGorrill — Fri, 19 Oct 2007 11:39:00 GMT

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

Re: Open VMS BASIC programming Doubt

John Gillings — Sun, 21 Oct 2007 17:09:05 GMT

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.

Re: Open VMS BASIC programming Doubt

Willem Grooters — Mon, 19 Nov 2007 07:05:39 GMT

Does "Secure subsystem" mean the following:

* Define an identifier (named after the application), with attribute RESOURCE
* Make that identifier OWNER of the files of the application
* Set these files O:RWED, or (better) craete an ACE to the file that allows DELETE for this identifier
* Grant the identifier to the user that needs ro handle the file (that is: DELETE access for RENAME)

If so, I learned something. If not, take it in consideration.

Aopart from that: The program should be aletered to handle conditions the RIGHT way. A foreseeable condition like this should NEVER blow the image.

Re: Open VMS BASIC programming Doubt

Richard W Hunt — Wed, 05 Dec 2007 13:23:48 GMT

I think I agree with John G. This is a bad case of re-inventing a wheel.

If the user doesn't have privilege to do X but you want that user to have the privilege when running Y but you don't want that user to have the privilege when running Z...

This sounds like a confused security design. You want to have your cake and eat it too. In essence, this design GUARANTEES job security because no one will ever figure out what you did. (Oops - may have answered my own question of WHY BOTHER...)

Seriously, either the user can or cannot delete a given file. It is either fish or fowl, no middle ground. So... what would be the value added to such a situation?

Logging? Put an Audit ACL on the directory or write logging code for every action of a certain class to occur in your menu system.

Extra security checks? OK, I could see that - but why? In the final answer is still going to be "can delete" or "can't delete." What is the REAL purpose here? If you tell us what you REALLY wanted, we might be able to help you rethink the problem in a clearer light.