An image can not be activated

[yaron1]

Hi,

When user tries to run an application executable image, it fails and he gets this message:

%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR
-CLI-E-IMGNAME, image file DA0:[SYS1.SYSCOMMON.][SYSLIB]CMA$TIS_SHR.EXE;
-RMS-E-PRV, insufficient privilege or file protection violation

It seems to be a shareable image that cant be activated. Does this shareable need to be installed? Is the INSTALL utility sets the security for this shareable (thus bypassing the file protection)? If needs to be installed what qualifiers?
It's VAX/VMS 5.5

Thanks for the answers, Yaron.

[Robert Gezelter]

Yaron,

Please check the protections and ownership on this file (e.g., DIRECTORY/SECURITY, if it is available on 5.5; I do not have a 5.5 system online to check the HELP text).

A shareable executable does not generally need to be installed; unless it is privileged.

When did this problem start? Was everything functioning normally in the past?

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

[Hein van den Heuvel]

Like Robert asked... did it ever work? What changed?

>> -RMS-E-PRV, insufficient privilege or file protection violation

So... what is the protection for the object, and who is trying to use it?
Use $DIR/SECU or the good old $DIR/PROT/OWN as Robert suggests.

>> Does this shareable need to be installed?

CMA$TIS can be used without installing, and in fact that may be a useful test:

$DEFINE CMA$TIS_SHR SYS$SHARE:CMA$TIS_SHR;

The trailing ";" will tell the system NOT to try use a previously installed image, but to activate the file itself.

I've seen it being installed with no options or /SHARE through "/open /header /shared=address_data /resident " (On Alpha 8.3).

If problems persist be sure to try with (CMKRNL required) $SET WATCH FILE/CLA=MAJOR making sure no surprise files/directories pop up.
Good luck!
Hein

[yaron1]

Hi,

The file protection doesnt have WORLD RE. But I checked in another node and that seems to be normal for this shareable image. So my question is how permission is normally granted to activate this image? How the file protection is bypassed? For example, ACL has priority over file protection.

Thanks, Yaron

[marsh_1]

yaron,

can the same user activate this image on the other node you mention ? are the user accounts set up exactly the same ?

[Volker Halle · Accepted solution]

Yaron,

ACLs could bypass the UIC protection, if they grant access to the file. A system UIC or privileges can also allow that image to be activated.

I checked a couple of systems and CMA$TIS_SHR.EXE seems to always allow WO:RE

Volker.

[Hein van den Heuvel]

Surely every image in sys$share, sys$library, and sys$system can safely be made world:RE. There is nothing to hide, as OpenVMS does not believe in security through obscurity, but instead protects critical objects permission/ACL based.

Not have world:re on those standard images is asking for trouble imho. I have a customer granting READ priv to all users because a stupid auditor told them to protect the images... so now it whole system is insecure. Oh well.

So when we asked 'what changed', was that per chance a attempt to audit and protect the system? :-)

Cheers,
Hein.

[Jess Goodman]

Hein said:
"Surely every image in sys$share, sys$library, and sys$system can safely be made world:RE. There is nothing to hide, as OpenVMS does not believe in security through obscurity,..."

VMS does come that way, so I won't say it isn't "safe" to keep all the .EXE files set to W:RE, but I do maintain that it can be "safer" to set selective images to no world access.

One simple example file is LINK.EXE. As long as your developers can access it, why would you want to allow untrusted users to create their own programs to attack your system with?

I hope nobody is going to claim the VMS has no security holes that an unpriviledged user could exploit. Hopefully we all recently learned our lesson (SMGSHR).

Protecting LINK.EXE is not "security through obscurity"; it is an added lay of security - like locking your gun cabinet even when all your doors are locked.

[Hein van den Heuvel]

>> One simple example file is LINK.EXE. As long as your developers can access it, why would you want to allow untrusted users to create their own programs to attack your system with?

hah! Spoiled brats. When I was young, plain old DCL and a bucket of recycled bits was enough to create an executable image. :-)

Absence of a linker is a minor hurdle for the devious, and might create a false sense of security for the ignorant.
You may be better of monitoring (audit) linker usage.
DCL is at least as dangerous IMHO.

Then again, security is not really my focus area.

Cheers,
Hein.

[Robert Gezelter]

Jess,

I would have to agree with Hein on the question of protecting the linker. Put simply, it is too straightforward to get the necessary bits on a machine one way or another. It is straightforward to link an image on another system, and then hexify the result and transcribe it. All quite doable in a variety of ways with nothing more than access to DCL (at one point, I believe there was a command file for doing almost precisely that for bootstrapping Kermit onto a system).

Simple speed bumps do not effectively increase security. What they often do, as in the discussion about SSID Broadcast for WiFi, is give the illusion of security, without really affecting any serious attack. In that case, even the newer PCI DSS standard no longer requires that SSID Broadcast be disabled.

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