Re: Is VMS Security being dumbed-down for Java?

Richard Maher wrote:

[deletia]

I'm not in a position to investigate the $imgact code right now, as related to Java. (That will have to wait.)

Q1: Without the use of enhanced privileges and with the Main Executable
Image not having being INSTALLed: - Can a call from an inner-mode UWSS out
to any other shareable image (/PROTECTED or otherwise) be spoofed and
redirected to another shareable image? My testing to-date indicates that the
image activator insists on all shareable images being INSTALLed. Is this
supported and architected behaviour?

This installation requirement is the intended behaviour of OpenVMS system security.

Calling out from a UWSS is intended to be restricted, and anyone coding a UWSS or any inner-mode code must be exceedingly careful not to open up a security hole; any and all code executing within inner-mode is considered part of the Trusted Computing Base (TCB), and thus considered to be security relevent.

Q2: When a LIB$ routine is called from an EXEC Mode UWSS, why does the image
activator consider Non-Trusted, Supervisor-Mode Logical Names when
activating LIBRTL? Furthermore, why does the image activator then appear to
ignore non-trusted logical names when activating other shareable images? Is
there something peculiar about LIBRTL?

Calling LIB$ from inner-mode code is not supported, and known to have various failures -- the most common failures involve VM allocation and mode protections on memory pages. UWSS calls operate in executive or kernel mode, and are thus limited to exec-based system services and the kernel-mode C library. Inner-mode calls to anything other than exec-based system services are not generally considered supported.

.