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

Hi Steve,

(Thanks for the reply and sorry for taking a while to get back. I was
unavoidably distracted.)

Hoff wrote: -
This installation requirement is the intended behaviour of OpenVMS
system security.

Yippee! Any doc reference? (Not necessary, but still nice to have.)

Calling LIB$ from inner-mode code is not supported,

Why not? Is that written anywhere? If you do an analyze/image of
TCPIP$CFS_SHR (for example) it looks like it calls LIBRTL, and LIBOTS, to
me. Is that not correct? Is it not a UWSS? I'm not trying to be clever, I'm
not trying to catch anyone out, I just want the facts! (The documentation is
*very* out of date and sadly lacking in the first place.) RDB$COSIP is
another example. It (like many, many others I'd wager) calls DECC$SHR and
without even looking it up, I'm sure that image in turn calls LIBRTL. So are
these products (Rdb and TCP/IP) unsupportable? I've spoken with you about
other cases before, they seem to be all over VMS. What people tell me are
the rules seem to be diametrically opposed to my perception of the reality.

Look, I do understand the potential pitfalls. 1) LIB$x how do we know what
other routines are subsequently called? 2) You can bet the house that all
the memory it uses is User-Mode Read-Write so If we rely on anything
statefull between calls then we're in trouble. 3) Likewise I'm sure any i/o
channels or logical names that are used can be corrupted from user mode. 4)
The LIB$x routine now has SYSPRV, SYSLCK, SETPRV, CMKRNL etc things that
should've failed (and were expected to fail) suddenly fly through. 5) A
whole lot of other scary ***. . .

Having said that and on the plus side, ONLY code that the System Manager (or
someone else with CMKRNL) has certified as being legitimate will be
executed. Spoofing cannot occur.

I was about to say that the *now recommended* way of locking
code/data/linkage into memory is LIB$*LOCK_IMAGE, but I see from VMS V8.1
that $LKWSET does the same thing *but* has an "acmode" argument. Hold-on,
there's only one depth-count not 1:mode, so what if a user-mode
lib$unlock_image unlocks an EXEC mode $lkwset? But you shouldn't exit
without unlocking so this won't happen? Scrub this whole paragraph - too
hard!

Let's look at LIB$*_EF. Even within the inner mode of a UWSS, would it not
be nice to support the convention of allocating event flags via LIB$GET_EF
thus avoiding potential conflict with the User-Mode code. Yes, I know about
$SYNCH but surely LIB$*_EF were written for a purpose? The convention can be
trashed from User-Mode, but as long as we $SYNCH with EXEC mode IOSBs we're
safe, and we've still done our best to be nice.

and known to have
various failures

Please point out any that come to mind. (I'm not questioning they exist! On
the contrary, I know they're out there and could have missed many)

the most common failures involve VM allocation and
mode protections on memory pages.

We discussed this some years ago and you taught me about the LIB$*_VM
vulnerability in that, although it is fully AST re-entrant, this is not the
case across different access modes. I concede fully the LIB$*_VM ground to
you - no question. One Heap - Too many access modes. (Having said that, in
the Programming Concepts Manual where it explicitly states "In particular,
do not call LIB$GET_VM and LIB$RET_VM from an inner mode." Lib$*RET*_vm? Did
it used to be called that 100 years ago? Docs up to date?)

Anyway, theories out the door and let's get down to it. This is what I
propse to do. Please tell me what's wrong with it: -

1) One of my Exec-Mode AST's is triggered and needs to pass data to User's
User-Mode AST
2) 1 Million of my Exec-Mode ASTs could fire before one User-Mode AST so I
need to dynamically allocate memory to hold User-Mode AST parameter.
3) LIB$*_VM is out of bounds
4) $expreg is a pain in the bottom! (How often does the rest of the process
really get to re-use the memory? When does $DELTVA contract the region?) So
the answer is, we call LIB$GET_VM_PAGE from the UWSS in Exec-Mode.
5) DO NOT $setprt up to UREW! Leave it at User-Mode trash access. We package
it up and deliver it to your letter box. If you rip it up before getting
inside then bad luck.
6) $DCLAST PSL$C_USER *my* AST using the memory from LIB$GET_VM_PAGE as the
parameter.
7) My user-mode AST (eventually) receives control and if a dodgy or
malicious pointer (or unplanned call to LIB$FREE_VM_PAGE has taken place
then tough-titties and a subsequent User-Mode Access Violation will occur.
8) CALL the User's code with the parameter
9) * Upon Return, Call LIB$FREE_VM_PAGE and make it available to all the
other lovely threads in the process that adhere to the Page-Pooling
convention. (Including my next Exec mode AST.)
10) Everyone's a winner chickens for dinner!

* Do you think I should go back into Exec Mode then Probe the page for
User-Mode write access before Freeing it? I Don't think so. If we we trying
the LIB$*_VM strategy with a seperate Zone then maybe but we've already
ruled that out.

Why do I think this is safe?

1) From the LIB$ RTL reference manual: -
"All memory allocated by LIB$GET_VM_PAGE has user-mode read/write access,
even if the call to LIB$GET_VM_PAGE is made from a more privileged access
mode." So LIB$GET_VM_PAGE *is* architected to work "from a more privileged
access mode". How would one get there apart from a UWSS and $CM****?
2) Same manual.
"LIB$GET_VM_PAGE is fully reentrant so it can be called by routines
executing at AST level or in an ADA multitasking environment". I bet ya an
EXEC mode AST can't interrupt a USER-Mode AST call to the same routine that
is already in progress. Should I look at the source?
3) 14.3 in Programming Concepts Manual
"You can change the protection on pages your program has allocated by
calling the set protection (SYS$SETPRT) service". It would make sense to me
to LIB$GET_VM_PAGE and SYS$SETPRT in the same UWSS and avoid User-Mode
corruption in a multi-step process. (In my case I can't verify that the EXEC
owned page that the User-Mode code would be giving me to FREE is in fact
mine :-( Facility prefix on pages :-)

UWSS calls operate in executive or
kernel mode, and are thus limited to exec-based system services and the
kernel-mode C library.

What's the filespec for this "kernel mode C library"?

But not so long ago you thought it was unsupported to call SYS$GETUAI (in
sys$share:secureshrp.exe) from a UWSS. Have you changed your mind?

Inner-mode calls to anything other than
exec-based system services are not generally considered supported.

Under which circumstances then are they "specifically" supported?

And I don't want to scare you, but I think you'll find that everyone else is
at it like rabbits!

Any and all UWSS facts welcome!

I always write too much. Sorry.

Regards Richard Maher

PS. You still haven't answered the "Why does the Image activator treat
logical names for LIBRTL differently?" question.

PPS. Hope I didn't get any coder into trouble over the JAVA comment. It
would be a shame to see it removed. (But things have a habbit of
disappearing lately)

"Hoff Hoffman" <hoff-remove-this@xxxxxx> wrote in message
news:61FSf.4880$Pf7.1238@xxxxxxxxxxxxxxxxxxx
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.



.