On 10/19/2005 10:20 AM, [EMAIL PROTECTED] wrote:
In a recent note, Walt Farrell said:
If you see some relationship that I don't, please explain further.
Perhaps you're considering something to be "security" that I don't.
I was trying to imagine how support for modal applications could
be implemented in a modular and extensible fashion, so that a
programmer might even be able to code his own modal applications
with no specific modifications to the TMP.
Modal apps don't need an extension to the TMP. The TMP has, for
example, no specific support for EDIT. EDIT is simply a command that
prompts the user for subcommands, and processes them, and eventually
returns to the TMP so the TMP can invoke the next command. Any user can
write such a modal command.
Suppose the modal application were ATTACHEd (or spawn()ed) and
control were returned to the TMP without doint a WAIT (or waitpid),
but leaving a communication channel open between the application
and the TMP; perhaps ECB semaphores, POSIX pipes, or sockets.
(I suspect the implementation of the modal EDIT is somewhat like
this.) Further line input from the TMP, CLIST, or EXEC would
be passed to the modal application, which would return messages
and status. This interaction would continue until the TMP passed
the application an END command and the application returned a
status indicating it exited.
The modal app does not return to the TMP. The app simply issues a
PUTGET to prompt and obtain a subcommand. If the app is running in a
CLIST the "get" part of the PUTGET is satisfied when the CLIST
eventually reaches something that is not a CLIST statement, but a
command, and the app gets that returned to it.
If the app is running in REXX, it gets the next input line from the
current input stack when it does the GET. The REXX exec itself is
suspended and not running until the app ends.
But I understand, however poorly, that part of TSO security depends
on preventing concurrency, so a task/process left in background
can't meddle with storage of a possibly authorized command. Permitting
the concurrency I envision above might compromise this protocol.
No, that's not part of the security processing. If the user or app
invokes an authorized program (vie IKJEFTSR, eventually) then all
earlier tasks in the address space are frozen, and cannot compromise
integrity while the authorized code is running.
Note, too, that the TMP supports what it calls "platform commands" which
run in a special TCB under the TMP. Even here, though, the expectation
is that a command will return to the TMP only when it is finished.
Modal commands retain control until they are done.
By the way, ISPF is another modal command, for example.
As an experiment, I wrote an EXEC which does a SYSCALL spawn and
exits without waitpid() for the child. With _BPX_SHAREAS = NO, it
returns normally and leaves the child running in the background
until it terminates. With _BPX_SHAREAS = YES, it ABENDs with
SA03. So I can leave a concurrent process in a different address
space, but not in the same address space where it might meddle
with working storage of subsequent commands. I suspect this
is routine operation of Classic MVS; not code added specifically
to protect the TMP from spawn().
SA03 indicates you did not clean up your subtasks, and is indeed very
old, classic processing.
The TMP doesn't really care what may interfere with working storage of
commands, except for authorized commands, and it isolates them so
nothing can interfere with them.
For non-authorized commands, as they're all running under the same
identity, security does not come into play. And as they're running
unauthorized, system integrity does not come into play, either. It's
just a user (problem state) program messing around with other user
programs, and if problems result they're not security problems, just
unwanted side effects or bugs.
I don't know EDIT or IPCS enough to try an experiment to see whether
the flavor of "address TSO" peculiar to Rexx programs started from
z/OS Unix shell plays well with those commands. (Too bad WJS
doesn't follow this list; he'd likely know.)
I don't know either.
Is execution of the modal EDIT from ISPF 6 fully supported?
Yes. EDIT runs until it terminates, then other things can run. You
lose access to everything in the ISPF environment while the EDIT runs.
Walt Farrell, CISSP
z/OS Security Design, IBM
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
