Itschak Mugzach <[email protected]> wrote: >I don't care that the user will look at the program logic. He is not >authorized to execute some of the commands in the program. The thing is >that I do not want the user to get control when the program run as they can >see run-time results of the program or even exit from the program.
That says to me that foreground REXX as the only part of this is the wrong solution. When I had, long ago, to provide something secure, I did it with foreground ispf dialogs written in a mix of rexx and assembler to set up action requests, validated by ACF2... but the actual actions happened in started tasks. When user requests needed actioned the dialogs issued WTOs; SA/390 automation started the required STCs with parameters which were extracted from the WTO text. There wasn't a security issue if someone managed to issue a WTO themselves with dummy parameters as the STCs concerned wouldn't be able to find corrresponding files supposedly created by the foreground part of the system. Syslog would clearly show who issued the fake WTO - I always preferred simple visible audit trails like that. The only people who could, in theory, create request files with certain parms in them, without using the dialog, then issue a WTO to have those request files acted on... were people who already had the ACF2-controlled permission to use the dialog to set the requests up & trigger the actions. That's because the request files had a strict naming structure so to set up a type-A request one had to have the authority to create a dataset which had the "A" in a particular part of its name (etc). There was no reason anyone would bother to do things manually (the hard way). Nevertheless there was an outside chance that a user authorised to use the dialog to request action A could try to fake a request for action B (by putting B-specific subparms into a valid type-A file). The ACF2 stuff happened twice - once in the dialogs to discourage users from trying to ask for things they were not allowed to do, but it all happened again in the started tasks. A request in this system went through a series of states. Not only the original request but also the validation of the request and its initiation and completion, post execution tidy-up, and indication to the caller whether the thing had worked all required name changes in the request file(s). Each transition needed the foreground TSO user(s) or started task(s) or SA/390 automation to have the ACF2 access that permitted that name change to be done. It was possible for example for one set of users to set up requests but not be able to release them for execution; someone else could have the ability to approve something, someone else again could release an approved request. Again, like the use of WTOs, making transition changes based on datasetnames made it easy for anyone to see the execution state of a particular request (eg by looking at a specific part of its dsname) but that didn't mean anyone could see or edit what was inside such a request file, not even the person who initiated a request, once it was on its way. There were also a great deal of ACF2 rules governing various aspects of the foreground dialogs, so someone attempting unauthorised use of the dialog would hit several problems on the way. -- Jeremy C B Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
