On Fri, 29 Oct 2010 10:36:24 -0500, McKown, John wrote:
>
>Or perhaps what you have is a UNIX based program which does some function(s).
>You want people to be able to use that, perhaps even via TSO OMVS. But you
>don't want them to have general access to a UNIX shell. But if they could
>control their own shell, then they could read the books and just do an ALU to
>change it. Granted, these "restricted" uses are few, but better to have a
>function than not. Also, given how often users muck up their Windows
>environment, I'd sooner that they not muck up their z/OS environment as well.
>It would be similar to allowing them to use whatever TSO proc they want
>instead of the one they are assigned.
>
For example, if zMan committed a typo changing his shell, he'd never
be able to login to Unix again. Unless he used FTP to rename his .profile.
But beware of being smugly confident that restricting shell access
limits users' access to UNIX facilities, since z/OS provides an
enormous back door in the form of BPX1* callable services and/or
the Rexx "address SYSCALL ..."
Likewise, restricting use of TSO procs can be readily circumvented
by "EXEC PGM=IKJEFT01". Too many of these restrictions exist primarily
to prevent the support desk's phones from ringing too often.
I believe our default user's login command is set to something like:
/Shell/access/prohibited.
As ever, resources and integrity should be protected by the security
product, not by restricting access to tools which otherwise have
harmless uses.
-- gil
----------------------------------------------------------------------
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
