It's not personal (Was: Re: APACHE$PRIVILEDGED)

Hi Steve,

So I'm the designated tall poppy? I'm flattered; thank you. :-)

I think you'll find that it is *I* who am the injured party here, and the
victim of thuggish bullying. Having said that, after my robust defense, I
don't think anyone else will be trying to take my lunch-money again anytime
soon. So, as you're now being so incredibly reasonable about the whole
thing, let us make the business: -

You can have the CDs, but I'm keeping the dog :-)

On 26 June 2006, Hoff wrote:-
a modicum of respect

On this basis we can proceed. . .

I agree with *everything* you've said below! It is light on opinionated
rhetoric, and contains much useful information. Could be good somewhere in
the programming concepts manual. The/a problem I still have is that you've
gone much further than that, many times here in COV. Now, neither of us have
the spare time for this so let's draw a line under it:-

1) You have stated/inferred/scare-crowed/"Wolf"-cried/FUDded that it is
"Intrinsicly and architecturally *impossible* to *securely* call out to
*any* RTL routine from an inner-mode UWSS with an *untrusted* caller!" If
you simply agree *unequivocally* to the following statement then I'm
prepared to walk-away: -

"It is perfectly possible, however difficult and dangerous the task may be,
to securely call out to an RTL routine that is architected to function at

2) We must come to an accomadation on your use of the emotion-laden word
"unsupported". Let's face it, *no* RTL routine is "supported" to function
with threads unless it publishes its tolerence explicitly. Yet VMS says
"Unlesss it explicity says it doesn't support threads then we'll just
proceed on the basis that everything is peachy." The half-truth in what
you've had to say about UWSSs is that *many* and varied (and often
essential) RTL programming practices render a routine "inappropriate" to be
called from inner-mode. (Especially, and routine that is stateful at
user-mode like lib$*_vm*)

Let's face it, correct system development and design is challenging, and so
it should be! That's why we (used to :-() get paid the big bucks. But if we
took your attitude (and a lot of sites are!) then there would be no in-house
development at all!

"Ooooh! I wouldn't do any programming if I were you. It's absolutely fraught
with danger! There are integer underflows and overflows and divide by zeros
errors (not to mention rounding issues). Then there's having to check for
EOF and remembering to reset the LINE_CNT to zero after a page-throw, where
will it all end? I buy software off-the-shelf, what other folks do is up to
them but if a support call gets anywhere near me then my input is that it is
unsupported to touch the keyboard!".

And Mr Maher, are you going to submit your FAKE_VM tool update to the
OpenVMS Freeware?

Not sure what you're refering to here? If it's my FAKE_RTL.COM then it's
just Gillie's with about twenty extra lines and 1/2 doz modified lines.
Nothing very clever and whoever owns fake_rtl can take (or leave) the
changes I've made. FAKE_RTL itself It's quite clever with what it does and
if my changes make it a bit more useful then I'll happily hand them over to
whoever. If you were refering to some VM tool (especially one that protects
it's inventory(s) at CURR-Mode and tolerates inner-mode allocating and
freeing memory from outer-mode pools then I don't have one :-( I think we
all want one of them!) I was going to submit the WAITFR_FILE stuff but I
think it loops if the Lock Value Block is trashed as I balked at
revalidating it myself. As (IMHO) it is a very useful example of UWSS
programming (and would be the only *MACRO* example available) I think
SYS$EXAMPLES would be a far more suitable home, and if we can thrash out a
few more details then I'll tighten it up a bit and we're done.

Cheers Richard Maher

PS. My currency is starting to suffer from over-exposure but I am hell-bent
on banging-on about this issue untill you put-up of shut-up.

"Hoff Hoffman" <hoff-remove-this@xxxxxx> wrote in message

So I'm the designated tall poppy? I'm flattered; thank you. :-)

Some background on security and privileged application code...

The primary security on OpenVMS and on most other multi-processing
operating systems is implemented via the memory management system (the
page tables) and via what VAX calls the change-mode routines, via the
Alpha SRM PALcode change-mode equivalent, or via what the IA-32 and
IA-32e architectures refer to as the call gate. The operating system
protects itself by restricting access into the inner memory access modes
and to the pages of memory.

With any privileged code, the code has to ensure that an accidental or
induced corruption in shared resources does not compromise security.
Most folks working with such a construct know to probe the argument
lists, though a few folks might well miss the second-level probe
involved when descriptors or such are involved within the argument list.
Far more subtle (but no less hazardous) can be security attacks via
intentionally or unintentionally shared resources, such as the image
pool (if and as applicable) or (again, if applicable) the stack. One of
the most subtle attacks is to either induce a run-time error within
inner-mode code, or (worse) to fully hijack the inner-mode code. This
is the usual target intent for a buffer-overrun attack, obviously --
either to destabilize the code, or to hijack it.

With OpenVMS constructs including device drivers (or drivers an
ancillary control processes (ACPs))and user-written system services
(UWSS; also known as privileged shareable images), these constructs
operate in inner processor modes. (I'll leave execlets for another
day.) Device drivers and UWSS interfaces both have APIs, with the
former built into and through $qio[w] and $io_perform[w] and the latter
using the so-called privileged library vector and the associated change
mode handlers.

Drivers, ACPs, UWSS images and execlets are all part of the so-called
trusted computing base (TCB), and such hunks of code are accordingly
responsible for maintaining system security.

The device driver interface provides routines that probe buffers for
read or read and write access, while the UWSS interface requires the
code more directly perform the probes using built-ins, PALcode calls or
such. Performing the individual argument list and buffer probe
operations is easy. Determining and performing all of the various
potential cases in a non-trivial argument list is somewhat more
involved. Code must also buffer information in a trusted area
as required and/or must re-probe the arguments upon completion to avoid
having the argument list to avoid attacks based on changing the data.

One of the more hazardous situations for system security is a mixed
environment; where there are resources shared between trusted and
untrusted environments. On an OpenVMS system, this can include ASTs,
the heap, the stack, argument lists, or -- such as in a threaded
environment -- most anything. Here, as with most other environments,
the memory page protections are your best resource. But within the same
address space of a process, this can be more difficult than it seems.
For UWSS code that uses RTL services, for instance, attacks can be
via deliberately-induced heap or stack corruptions, or even through
hijacking the contents of unprotected pages. Context arguments often
used in multi-part calls are and must be carefully secured, and the code
must be willing and able to accept any corruptions to the values.
(Drivers can tend to avoid the need for context arguments by being able
to store data in trusted regions of memory.)

And probably the most hazardous environment is where application code is
performing security-related functions, such as authentication or evasion.

As for the UWSS, calling into a routine that isn't intended to be called
from privileged environments can open up various subtle exposures.
Installing an executable image, for instance, and specifically an image
that wasn't intended to be installed, can cause security exposures as
the tool might be able to read or write files or objects not otherwise
accessible. Not only will the operation that requires privileges now be
permitted, but other and potentially unintended operations can also be
permitted. This is where a security investigation into the called code
can be potentially involved, as well -- since the called code may or may
not expect the inner-mode call, you need to ensure it will function
correctly for your environment. (If the environment has untrusted users
and if it needs to be secured.)

If you can trust the calling environment -- and anybody that can link to
an activate the UWSS when installed -- then the coding involved in a
UWSS is trivial. (If I trust the calling code but not the environment,
then I tend to install the executable image with privileges. If I can't
trust the calling code (or the environment), then I start to get
seriously paranoid. This can be a UWSS, a driver or a driver and ACP --
as has been obvious in variations of this thread, I tend to prefer to
call RTL services from user-mode, for instance, and an ACP or an AST is
the usual path.)

Now as to what other folks might choose here and how a particular
programmer might choose to implement something, well, that's up to them.

And Mr Maher, are you going to submit your FAKE_VM tool update to the
OpenVMS Freeware? We're past the deadline, but if you can get the tool
packaged and submitted Real Soon Now, I can add it into the packaging
that's presently underway.