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

[Jess Goodman]

(exasperated _sigh_to those who don't understand the concept of security LAYERS.)

Yes, it would be possible for a skilled hacker to get the necessary bits in a file to create an .EXE file anyway. That doesn't mean protecting LINK.EXE is useless.

Hein, Robert - I assume you don not bother to lock your front door. After all, anyone with an axe would be able to get through, so locking it would only give you a false sense of security.

[Jess Goodman]

Hein wrote:
"You may be better of monitoring (audit) linker usage."

Clearly you don't get the "layer" concept. You are not better off using auditing INSTEAD - you are better off using auditing IN ADDITION to all other security measures you can implement, including setting images to no world access that untrusted users have no business running.

[Robert Gezelter]

Jess,

With all due respect, I do lock my front door, and my car for that matter.

However, I do recommend caution on protecting "normal" non-privileged utilities. I have encountered references to them in far too many surprising contexts over the years to want to find additional dependencies as security alarms.

One can also remove things from DCLTABLES, but at the risk that command procedures will suddenly stop working when an otherwise innocuous change is made.

Security can indeed be subtle, and reasonable professionals can disagree on issues like these.

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

[John Gillings]

re: Jess and "protecting" LINK.EXE

LINK is an unprivileged image. If I have access to DCL, and a network, or any external media, I can easily get a copy of LINK.EXE from distribution media, or any other system (I'm sure it wouldn't take long to find a copy somewhere on the web). Place the image anywhere I like, point the logical name LINK at it and I'm back in business.

This is nowhere near the domain of "skilled hacker", it's a very basic understanding of how command and image activation work.

It's not like locking the gun cabinet at all, it's more like putting sign on the unlocked cabinet saying "locked". The real problem is the illusion of security where none exists.

The same is true for any image in SYS$SYSTEM that is not required to be installed with privilege to function.

Similarly removing verbs from DCLTABLES and creating a rod for your own back on every update. It's trivially simple to add a command back - even if you also protect the CLDs in SYS$UPDATE (again they're public domain and easy to reconstruct)

[Jess Goodman]

We don't allow our untrusted users to download files from the internet. But even if you do, every extra step you make an attacker take leaves another footprint.

John, you have mentioned in this and other threads that you think it is trivial for a user to put missing commands back into their command tables.

Assuming, of course, that the deleted commands include the SET COMMAND syntax, and the user has the restricted flag, please tell me how to do this trivial act? I can't figure it out.

[John Gillings]

Jess,

> We don't allow our untrusted users to
>download files from the internet

Can they receive mail (even just text)?

>every extra step you make an attacker take
>leaves another footprint.

In this case you'd probably be better off leaving LINK unprotected, but audited. You then know when someone uses it, without tipping your hand. If someone gets a private copy, you don't know when or how it's being used.

>I can't figure it out.

Maybe for the sake of your security I'd better not say ;-)