Re: Here's a silly question
- From: Jeremy Nicoll - news posts <jn.nntp.scrap004@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 9 Jun 2009 01:33:48 +0100
rony <Rony.Flatscher@xxxxxxxxxxxxx> wrote:
Barney Badass wrote:
In a z/OS environment, one can (presuming the rexx compiler is installed
on the z/OS environment) "Compile" the rexx code in a way such that the
original REXX Source code can not easily be read.
Is this kind of feature implemented in any version of ooREXX?
Sorry rony, I'm really replying to Barney (I've lost the original post).
In S/390 in an ACF2 site I remember noting that ACF2 supported the idea of
PDSes being execute-only, and was sorry to find that that didn't work for
rexx execs. I don't know if RACF has a similar concept.
It might be possible to define an ACF2/RACF rule that makes a PDS-ful of
execs readable only if the program doing the reading is the EXEC command
processor (which if I recall makes the determination whether something being
EXECuted is CLIST or EXEC) or failing that one of the IRX modules.
I don't know if that'd mean that another rexx exec could then read the one
you'd be trying to restrict access to.
I wrote some 'secure' systems based on rexx execs, and because of this
problem was not able to prevent users from seeing the source. So, I adopted
the principle that seeing the source must not be a problem. In practice this
meant that the apps were split into foreground portions which set up
requests, albeit with lots of checks of who wanted to do what (some using
extended ACF2 resource rules), and the details of what was to be done were
written to a request file (obviously the user executing the dialog needed to
have alloc & write access to the request file, which in itself made it
harder to violate the system). Still, a user lawfully able to set up one
sort of request might think to fake a different sort of request that way...
Once a request was set-up the foreground dialog issued a WTO (so creating a
good audit trail in syslog). SA/390 automation responded, and at the first
stage checked that the WTO was issued by someone allowed to make this type
of request. If so a STC was started to examine the request and perhaps to
execute it. Up to this point it was theoretically possible for an
unauthorised user to run their own modified copy of the foreground execs and
set up an unauthorised request of their own.
The STC ran under a production userid which was ultimately able itself to do
the thing being requested (or trigger it elsewhere), and would read a file
containing details of what was being requested by the user concerned. But
the STC repeated all the simple and more complex (ACF2) checks of what the
purported user was trying to do, and this time it must be executing the
proper code, not a user's modified copy. The STC then decided whether or
not to carry out the request.
Just because users could see the code didn't mean they could circumvent it.
At least, I hope not!
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsreplynnn@xxxxxxxxxxxxxxxxxxxx replacing "nnn" by "284".
.
- Follow-Ups:
- Re: Here's a silly question
- From: Swifty
- Re: Here's a silly question
- References:
- Here's a silly question
- From: Barney Badass
- Re: Here's a silly question
- From: rony
- Here's a silly question
- Prev by Date: Re: PC REXX to mainframe REXX I/O
- Next by Date: Re: Limitation on SysFileTree?
- Previous by thread: Re: Here's a silly question
- Next by thread: Re: Here's a silly question
- Index(es):
Relevant Pages
|