Re: Here's a silly question



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".
.



Relevant Pages

  • Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?
    ... >> The way I understand async programming is if u need to do other ... >> request to webservice nothing more can be done until the result ... > The thread executing code literally calls into Function1, ... > the act of sending back the response using data that has been ...
    (microsoft.public.inetserver.iis)
  • Re: DBD ODBC question - $dbh->{odbc_exec_direct}
    ... because they're doing nothing but executing more ... Request was not opened or has been closed. ... Force DBD::ODBC to use SQLExecDirect instead of SQLPrepare() then ...
    (perl.dbi.users)
  • Re: Postback in Firefox and IE
    ... Does having a querystring makes a request a new request each time it is ... >> time a page is posted back to the server on firefox and netscape ... >> navigator. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Need to break a while..
    ... finished the default behavior is for PHP to abort the script. ... I solved the problem with an <iframe> and a small file, ... No, once you execute a request, you cannot "inject" additional values ... to the executing script on the fly. ...
    (comp.lang.php)