Re: Allowing Joe User into TSO

[Knutson, Sam]

It can be done.  We provide logons for some of our operations people
which could be considered very restricted with  privileges needed to
manage printers for instance.

RACF-L is the best place to go for HOWTO advice on RACF but IBM-MAIN
covers just about anything too.

RACF-L

From
http://www-1.ibm.com/servers/eserver/zseries/zos/racf/racf-l.html

The RACF-L Discussion List 
 
 
Customers and IBM participants may also discuss RACF on the RACF-L
discussion list. RACF-L is not operated or sponsored by IBM, but is run
by the University of Georgia.

To subscribe to the RACF-L discussion in order to receive postings, send
a note to:

[EMAIL PROTECTED]
Include the following line in the body of the note, substituting your
first name and last name as indicated: subscribe racf-l first_name
last_name

To post a question or response to the RACF-L forum, send a note to:
[EMAIL PROTECTED] Please include an appropriate subject line in
your posting.



The RESTRICTED attribute assigned to the USERID should help a lot.

RESTRICTED  
specifies that global access checking is bypassed when resource 
access checking is performed for the user, and neither ID(*) on 
the access list nor the UACC will allow access. The 
RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV class can 
also be used to bypass the z/OS UNIX 'other' permission bits
during file access checking for RESTRICTED users.   

Note:  If your installation has profiles defined in the PROGRAM 
   class, and the user ID with the RESTRICTED attribute 
   needs to load programs covered by one or more of these   
   profiles, the user id must be put on the access list 
   with EXECUTE or READ authority. 

We built out users long before RESTRICTED became available so we did
much the same thing with a group called NOACCESS and permitted them NONE
to virtually everything.  Today I think RESTRICTED is a better way to go
but in full disclosure I have read about but not implemented with it
yet.

As far as TSO/E you should not need anything more than a unique LOGON
PROC and you might consider to make the allocations and throw them
directly into the application using the an EXEC run by the LOGON PROC.

Good Luck!

Best Regards,

Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office)  301.986.3574

"Think big, act bold, start simple, grow fast..."

  

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Steve Grimes
Sent: Tuesday, October 25, 2005 7:11 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Allowing Joe User into TSO

Hello, z/OS 1.4 here.

I apologize in advance for not knowing the best list to send this
question to.  (Perhaps ISPF-L?  But I'm not a subscriber there.)  I'm
proposing to our systems folks that we allow a "user" to use TSO to get
to the Zeke Work Center function.  I'm being told that there is no way
for us to limit what the user can do if we let them intoTSO.
(Historically, we had RACF practically emasculated.  This has been
tightened down recently.  Our application programmers no longer, for
instance, have update access to SYS1.PARMLIB, etc.)

I'm going to counter this assertion with my own, namely:  We can create
a sign-on PROC that executes a CLIST and panel that only gives this user

access to Zeke.   Once they're in Zeke, I'm confident (using the Zeke 
security functions) that I can limit them to just what I want them to be

able to do.   I'm hoping no RACF changes will be required, except
perhaps 
for authorization to execute the sign-on proc.

The only catch I see is that we currently select (from our initial menu)
the "Altai/Platinum" product support menu which has Zara and Zeke, and
choose Zeke from there.  We don't want this user to see Zara, only Zeke.

Am I making sense?   Is my position sound?  Any tips?   I have been 
looking at the TSO/E Customization  manual.

The two-step I'll face is:

1) It can't be done. 
2) It would take a long time to do that.

TIA!

Stg

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

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instruction

Re: Allowing Joe User into TSO

[Brian Westerman]

Hi,

This is actually able to be accomplished in several ways.  You can use a
program like CMDLGOFF on file 416 of the CBT tape, or, (even easier), you
can set up the "logon" rexx exec (the parm on the execute statement of the
logon proc) to have the following:
(this example lets a user into VPS's VMCF option only, if they exit it in
any way, it logs them off)

signal on novalue
signal on halt

"ispfallo"   [this is your normal ispprof allocation clist/rexx stuff)]


"ISPSTART PGM(VM81ISPF) NEWAPPL(VMCF) PARM(SRV(VSV))"  [load them to VMCF]

halt: "LOGOFF"
exit

pretty simple, and it works, which makes it even better.

You can also use the STACK command (or one like it) from the CBT tape, but I
think the example above is better because it's simple and effective.

Brian Westerman

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

Re: Allowing Joe User into TSO

[Edward E. Jaffe]

Steve Grimes wrote:

I apologize in advance for not knowing the best list to send this question 
to.  (Perhaps ISPF-L?  But I'm not a subscriber there.)  I'm proposing to 
our systems folks that we allow a "user" to use TSO to get to the Zeke 
Work Center function.  I'm being told that there is no way for us to limit 
what the user can do if we let them intoTSO.




Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will 
require that _every function_ they need be explicitly authorized, 
regardless of any existing UACC settings.


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

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

Re: Allowing Joe User into TSO

[Joel C. Ewing]

Edward E. Jaffe wrote:

Steve Grimes wrote:

I apologize in advance for not knowing the best list to send this 
question to.  (Perhaps ISPF-L?  But I'm not a subscriber there.)  I'm 
proposing to our systems folks that we allow a "user" to use TSO to 
get to the Zeke Work Center function.  I'm being told that there is no 
way for us to limit what the user can do if we let them intoTSO.




Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will 
require that _every function_ they need be explicitly authorized, 
regardless of any existing UACC settings.


One of the things to keep in mind, simply restricting what menus they 
see in ISPF by restricting the logon PROC, even if you do auto logoff 
when they exit ISPF, doesn't really restrict what they can do in 
TSO/ISPF as long as they have access to an ISPF command line from which 
any TSO command or program in LINKLST can be potentially invoked; and 
many ISPF panels support a command line or have menu pulldowns that may 
lead to such panels.


You would want to guarantee through appropriate RACF security (like 
RESTRICTED with minimal explicit RACF permits mentioned by Edward) that 
they have no access to any datasets they don't need and that they can't 
access any programs other than the ones they need for their intended 
function.  It ought to be possible, but to give them the minimal 
required access will no doubt require a tedious repetitive process to 
gradually add all the needed permits to DATASET and PROGRAM profiles 
until they can do what is required without being blocked at some point 
by RACF access failure messages.  Depending on the ISPF application, you 
could run into situations where granting access to some program or 
dataset required by the ISPF dialog might also open up avenues for abuse 
from the ISPF command line.


In order to run ISPF they will have to have UPDATE access to a user ISPF 
PROFILE PDS (or PDSE) dataset.  If they have any way to introduce their 
own member into that dataset (batch, TSO EDIT, ISPF EDIT, etc.), they 
could potentially use a REXX program to display many parts of COMMON 
storage, probably not a serious breach in most installations, but a 
potential unintended capability.




--
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]

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

Re: Allowing Joe User into TSO

[Martin Kline]

>> I apologize in advance for not knowing the best list to send this
>> question to.  (Perhaps ISPF-L?  But I'm not a subscriber there.)  I'm
>> proposing to our systems folks that we allow a "user" to use TSO to
>> get to the Zeke Work Center function.  I'm being told that there is no
>> way for us to limit what the user can do if we let them intoTSO.
>>
>
> Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will
> require that _every function_ they need be explicitly authorized,
> regardless of any existing UACC settings.

I find this interesting. Just recently, list members were objecting that
limiting a user's access to resources (in that case it was memory) was
probably keeping them from doing their job. Where are they now?

The argument was that if a user was requesting a resource, they MUST NEED
IT for their job. This seems like a very similar situation. Why not allow
the users access to all of ISPF, and depend on their honorable nature to
only use those functions that they need to do their job?

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

Re: Allowing Joe User into TSO

[Paul Gilmartin]

In a recent note, Martin Kline said:

> Date: Fri, 28 Oct 2005 07:41:03 -0500
> 
> I find this interesting. Just recently, list members were objecting that
> limiting a user's access to resources (in that case it was memory) was
> probably keeping them from doing their job. Where are they now?
> 
Weary from the last time around?  But since you ask ...

> The argument was that if a user was requesting a resource, they MUST NEED
> IT for their job. This seems like a very similar situation. Why not allow
> the users access to all of ISPF, and depend on their honorable nature to
> only use those functions that they need to do their job?
> 
"depend on their honorable nature" is appropriate for functions,
but inadequate for resources.  But the approach should be to
protect resources with RACF, not to restrict a targeted class
of users.  Don't stigmatize a group and confine them to reservations,
or to ghettos, or with house arrest; rather secure the bank vaults
to prevent theft.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Allowing Joe User into TSO

[Martin Kline]

HI Gil. You said:

> "depend on their honorable nature" is appropriate for functions,
> but inadequate for resources.

So, you believe that resources, e.g. memory, should be protected, while
functions, like TSO commands, should not?

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

Re: Allowing Joe User into TSO

[Paul Gilmartin]

In a recent note, Martin Kline said:

> Date: Fri, 28 Oct 2005 08:15:26 -0500
> 
> So, you believe that resources, e.g. memory, should be protected, while
> functions, like TSO commands, should not?
> 
I was thinking more of data sets than memory (Resources like the
"R" in "RACF"), but yes.  If you wish to prevent a user's
deleting SYS1.LINKLIB, don't try to prevent the user's use of
the TSO DELETE command, and ALLOC DISP=(...,DELETE), and IDCAMS,
and any number of commands that might delete a data set.  Simply
protect SYS1.LINKLIB with RACF (probably a good idea anyway).

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Allowing Joe User into TSO

[Edward E. Jaffe]

Martin Kline wrote:


I find this interesting. Just recently, list members were objecting that
limiting a user's access to resources (in that case it was memory) was
probably keeping them from doing their job. Where are they now?

The argument was that if a user was requesting a resource, they MUST NEED
IT for their job. This seems like a very similar situation. Why not allow
the users access to all of ISPF, and depend on their honorable nature to
only use those functions that they need to do their job?
 



Your confusion is due to an unfortunate use of the word "resource" in 
two wholly-different contexts.


RACF stands for Resource Access Control Facility. But, the "resources" 
it protects have nothing whatsoever to do with CPU time or virtual storage.


I suppose, if we could convince Mr. Peabody to use the Wayback Machine 
to take us to the meeting where RACF's moniker was invented, we could 
insist on a more-appropriate one, like PCF = Permissions Control 
Facility.   :-\ 


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

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

Re: Allowing Joe User into TSO

[Martin Kline]

> Your confusion is due to an unfortunate use of the word "resource" in
> two wholly-different contexts.

On the contrary, I am not confused at all. Clearly, users should be
prevented from deleting datasets they shouldn't delete. However, who's to
say Joe user shouldn't delete dataset JOE.yyy.zzz? Is it a requirement of
the job?

Likewise, who's to say Joe user shouldn't allocate 100Gb of virtual memory
to load a table? Is it a requirement of the job?

Should the approach be to protect all datasets, and require every user to
get authorization before accessing them? Won't this interfere with their
ability to do their jobs?

What about memory? Shouldn't excessive memory requests be restricted, and
require authorization as well? Would that interfere with the ability of
users to do their jobs? Is it any worse than setting up dataset protection?

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

Re: Allowing Joe User into TSO

[Walt Farrell]

On 10/28/2005 10:16 AM, Edward E. Jaffe wrote:
RACF stands for Resource Access Control Facility. But, the "resources" 
it protects have nothing whatsoever to do with CPU time or virtual storage.


I suppose, if we could convince Mr. Peabody to use the Wayback Machine 
to take us to the meeting where RACF's moniker was invented, we could 
insist on a more-appropriate one, like PCF = Permissions Control 
Facility.   :-\


The internal tool which became RACF did have controls for CPU and DASD 
storage utilization (though I don't think it had controls for virtual 
storage).


If you were going to go back and change something, I'd prefer you 
convince them to make those controls part of the product, too, rather 
than changing the product name.



Walt

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

Re: Allowing Joe User into TSO

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 10/25/2005
   at 06:11 PM, Steve Grimes <[EMAIL PROTECTED]> said:

>I apologize in advance for not knowing the best list to send this
>question  to.  (Perhaps ISPF-L?  But I'm not a subscriber there.) 
>I'm proposing to  our systems folks that we allow a "user" to use TSO
>to get to the Zeke  Work Center function.  I'm being told that there
>is no way for us to limit  what the user can do if we let them
>intoTSO.

Then you'd better not let them submit batch jobs either, because they
can cause the same damage as a TSO session.

>(Historically, we had RACF practically emasculated.

And *that* is your security problem, not the red herring of TSO
access.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Allowing Joe User into TSO

[Edward E. Jaffe]

Martin Kline wrote:


Your confusion is due to an unfortunate use of the word "resource" in
two wholly-different contexts.
   



On the contrary, I am not confused at all. Clearly, users should be
prevented from deleting datasets they shouldn't delete. However, who's to
say Joe user shouldn't delete dataset JOE.yyy.zzz? Is it a requirement of
the job?

Likewise, who's to say Joe user shouldn't allocate 100Gb of virtual memory
to load a table? Is it a requirement of the job?

Should the approach be to protect all datasets, and require every user to
get authorization before accessing them? Won't this interfere with their
ability to do their jobs?

What about memory? Shouldn't excessive memory requests be restricted, and
require authorization as well? Would that interfere with the ability of
users to do their jobs? Is it any worse than setting up dataset protection?
 



You're getting waaay off track here...

The OP (Steve Grimes) wishes to provide some of his users with access to 
Zeke. Apparently, that is how they do their jobs. The fear from the 
system programmers at his shop is that, because RACF has been 
emasculated, these users would get too much authority if logged on to 
TSO. Specifically, he was told, "... there is no way for us to limit 
what the user can do if we let them into TSO." So he began contemplating 
ways to limit their access and posted to the list.


What Steve was told is untrue. Establishing ACCESS=RESTRICTED for a user 
(or group of users) ensures they cannot break things no matter how lax 
the existing rules are. These users will require specific authorization 
to any RACF-protected "resources".


ACCESS=RESTRICTED does not stop JOE from deleting JOE.yyy.zzz. Not sure 
where you got that impression. This feature in no way changes the 
behavior of generic vs discrete profile profile processing. Rather, it 
simply treats UACC as NONE in all cases.


I've set this up here for an outside consultant and I recommend it highly!

--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

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

Re: Allowing Joe User into TSO

[Edward E. Jaffe]

Walt Farrell wrote:


On 10/28/2005 10:16 AM, Edward E. Jaffe wrote:

RACF stands for Resource Access Control Facility. But, the 
"resources" it protects have nothing whatsoever to do with CPU time 
or virtual storage.


I suppose, if we could convince Mr. Peabody to use the Wayback 
Machine to take us to the meeting where RACF's moniker was invented, 
we could insist on a more-appropriate one, like PCF = Permissions 
Control Facility.   :-\



The internal tool which became RACF did have controls for CPU and DASD 
storage utilization (though I don't think it had controls for virtual 
storage).


If you were going to go back and change something, I'd prefer you 
convince them to make those controls part of the product, too, rather 
than changing the product name.



If such controls were present in the product, the RACF name might have 
been more appropriate. In any case, you guys have already changed its 
name more than enough times. :-D


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

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

Re: Allowing Joe User into TSO

[Thomas Berg]

==  Steve Grimes  ==  wrote2005-10-26 01:11:
Our  application programmers no longer, for instance, have update access to 
SYS1.PARMLIB, etc.


8-O   :-D
ROFL!


--

--
Mundus Vult Decipi
--

 They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety.
 - Benjamin Franklin

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

Re: Allowing Joe User into TSO

[Martin Kline]

> Your confusion is due to an unfortunate use of the word "resource" in
> two wholly-different contexts.

> You're getting waaay off track here...

I'm confused and off track? Please do not attacking me personally.

I got into this discussion just to highlight the inconsistency of two
arguments. In one case it was argued that any user who used a resource must
need it to do their job, otherwise they would never have used it. In the
other case, it's argued that all resources should be protected, and only
specific authorizations given out, because accidents and bad intentions
happen.

The resources involved are different, but the reasons for protecting them
are essentially the same.

If the business requires that a user access a specific set of resources,
and no other resources, then the other resources have to be protected.

If the business would like a user to access a set of resources and would
like (but not require) them NOT to access other resources, then a note
saying, "Please don't touch these other resources" might suffice.

Each business' requirements are different. Perhaps the originator is
satisfied with a logon proc that only points Joe user to Zeke. Maybe the
requestor isn't interested in the myriad methods of bypassing security, and
is only interested in satisfying the immediate needs of Joe user. After
all, the original request said, "I'm hoping no RACF changes will be
required, except perhaps for authorization to execute the sign-on proc."

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

Re: Allowing Joe User into TSO

[Wayne Driscoll]

Martin, 
If a persons job function requires that they be able to use ISPF and edit a
file that requires 128M of virtual storage, then they should have access to
that much storage.  If their job functions requires that they have update
access to SYS1.PARMLIB, then the should have it.  However, giving them
update access to the FILE that requires 128M of virtual storage to edit, but
limiting the user to 32M of virtual storage will not allow them to perform
there job function.  I don't believe that anyone is saying don't have
limits, just that the limits should be so restrictive that the computer
doesn't get used.
Wayne Driscoll
Product Developer
Western Metal Supply
NOTE: All opinions are strictly my own.
  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Martin Kline
Sent: Friday, October 28, 2005 9:37 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Allowing Joe User into TSO

> Your confusion is due to an unfortunate use of the word "resource" in 
> two wholly-different contexts.

On the contrary, I am not confused at all. Clearly, users should be
prevented from deleting datasets they shouldn't delete. However, who's to
say Joe user shouldn't delete dataset JOE.yyy.zzz? Is it a requirement of
the job?

Likewise, who's to say Joe user shouldn't allocate 100Gb of virtual memory
to load a table? Is it a requirement of the job?

Should the approach be to protect all datasets, and require every user to
get authorization before accessing them? Won't this interfere with their
ability to do their jobs?

What about memory? Shouldn't excessive memory requests be restricted, and
require authorization as well? Would that interfere with the ability of
users to do their jobs? Is it any worse than setting up dataset protection?

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

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

Re: Allowing Joe User into TSO

[Edward E. Jaffe]

Martin Kline wrote:


Each business' requirements are different. Perhaps the originator is
satisfied with a logon proc that only points Joe user to Zeke. Maybe the
requestor isn't interested in the myriad methods of bypassing security, and
is only interested in satisfying the immediate needs of Joe user.



Perhaps. But he solicited advice from the list and that's what he got.


After
all, the original request said, "I'm hoping no RACF changes will be
required, except perhaps for authorization to execute the sign-on proc."
 



And I'm hoping to win the MEGA Millions California Lottery. Chances are 
both Steve and I will be disappointed. ;-)


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

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

Re: allowing Joe User into TSO

[john gilmore]

There are two polar attitudes toward problems of this sort, viz.,

Was ist nicht erlaubt is verboten (What is not allowed is forbidden).

and

Was ist nicht verboten ist erlaubt (What is not forbidden is allowed).

The second of them has three great merits:

o It does not require uncommon, even God-like prescience;

o It does not cumber the working environment with barred windows and culs de 
sac; and


o It is much less labor-intensive than the first.

Computer-security problems are real; but we now have a large and growing 
group of computer-security specialists who have a vested, bureaucratic 
interest in devoting more and more resources to treating these problems 
simplistically; and these 'specialists' are hard to oppose without being 
attacked as naif or in league with the villains.



John Gilmore
Ashland, MA 01721-1817
USA

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: Allowing Joe User into TSO

[Martin Kline]

> If a persons job function requires that they be able to use ISPF and edit
> a file that requires 128M of virtual storage, then they should have
> access to that much storage.  If their job functions requires that they
> have update access to SYS1.PARMLIB, then the should have it.

I agree, Wayne. just because one user needs to have update access to
parmlib does not mean all users should have update access.

But the previous discussion had some users suggesting that memory limits
for all users should be set higher than the maximum requirement for any
user. I believe this leave the organization vulnerable to problems.
Instead, allow the one user to have lots of memory, and restrict others to
a lower limit, that the system can tolerate.

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

Re: Allowing Joe User into TSO

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Martin Kline
> 
> > Your confusion is due to an unfortunate use of the word 
> "resource" in 
> > two wholly-different contexts.
> 
> On the contrary, I am not confused at all.

I'm inclined to think you are, because you're in effect comparing a
restriction on how fast you can drive a car (storage/CPU) vs. a restriction
on where you can or cannot drive it (TSO, SDSF, Zeke, etc.).

-jc-

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

Re: Allowing Joe User into TSO

[Martin Kline]

>> On the contrary, I am not confused at all.

> I'm inclined to think you are, because you're in effect comparing a
> restriction on how fast you can drive a car (storage/CPU) vs. a
> restriction on where you can or cannot drive it (TSO, SDSF, Zeke, etc.).

If this discussion is about a car, then I am definitely confused. ;)

But, if we were talking about cars, I think we'd be discussing you stealing
100 gallons of my gas (Gb of memory) vs. you driving on my lawn and running
over my azaleas (anything other than poor ol' Zeke).

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

Re: Allowing Joe User into TSO

[Howard Brazee]

On 28 Oct 2005 09:14:03 -0700, [EMAIL PROTECTED] (Martin
Kline) wrote:

>But the previous discussion had some users suggesting that memory limits
>for all users should be set higher than the maximum requirement for any
>user. I believe this leave the organization vulnerable to problems.
>Instead, allow the one user to have lots of memory, and restrict others to
>a lower limit, that the system can tolerate.

If it's not good for the system, I like working on a way to allow
anybody to get those resources - but to have to do a bit of work every
time, so that they don't set up parameters to *always* use those
resources.

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

Re: Allowing Joe User into TSO

[Steve Grimes]

Hello again!

We'll I'm certainly enjoying the exchange.  I think the initial responses 
covered what I was after.

An additional detail for the curious -- Joe User currently has a Roscoe 
account and uses it to submit jobs that do updates.  So, he has a 
reasonable amount of RACF authority already.  But, alas, not enough due to 
recent (long overdue) tightening of RACF rules.So he calls us, and we 
submit this one job.

Zeke has the authority to submit what they want, and the Work Center 
function (within) can be set up so they can only submit that -one- job.

This would also serve as a "proof of concept" for migrating JCL stuff away 
from users (and Roscoe) and toward better (I think) control via the Zeke 
Work Center.

Stg

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

Re: Allowing Joe User into TSO

[Klein, Kevin]

We got around the TSO need by implementing Zeke's CICS interface, then 
controlling it with transaction security.  I think that interface comes 
standard with Zeke.  Another option to consider for you.  Local policies and 
politics notwithstanding.  Also assuming you have CICS/TS.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Steve Grimes
Sent: Friday, October 28, 2005 2:06 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Allowing Joe User into TSO


Hello again!

We'll I'm certainly enjoying the exchange.  I think the initial responses 
covered what I was after.

An additional detail for the curious -- Joe User currently has a Roscoe 
account and uses it to submit jobs that do updates.  So, he has a 
reasonable amount of RACF authority already.  But, alas, not enough due to 
recent (long overdue) tightening of RACF rules.So he calls us, and we 
submit this one job.

Zeke has the authority to submit what they want, and the Work Center 
function (within) can be set up so they can only submit that -one- job.

This would also serve as a "proof of concept" for migrating JCL stuff away 
from users (and Roscoe) and toward better (I think) control via the Zeke 
Work Center.

Stg

--
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
#
Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy any copies.
#

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

Re: Allowing Joe User into TSO

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Grimes
> Sent: Friday, October 28, 2005 2:06 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Allowing Joe User into TSO
> 
> 
> Hello again!
> 
> We'll I'm certainly enjoying the exchange.  I think the 
> initial responses 
> covered what I was after.
> 
> An additional detail for the curious -- Joe User currently 
> has a Roscoe 
> account and uses it to submit jobs that do updates.  So, he has a 
> reasonable amount of RACF authority already.  But, alas, not 
> enough due to 
> recent (long overdue) tightening of RACF rules.So he 
> calls us, and we 
> submit this one job.
> 
> Zeke has the authority to submit what they want, and the Work Center 
> function (within) can be set up so they can only submit that 
> -one- job.
> 
> This would also serve as a "proof of concept" for migrating 
> JCL stuff away 
> from users (and Roscoe) and toward better (I think) control 
> via the Zeke 
> Work Center.
> 
> Stg

I know nothing about Zeke. But would it be possible for "Joe" to submit
a job which triggers the actual job to be run? I know that CA-7 can do
this.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

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

Re: Allowing Joe User into TSO

[Ted MacNEIL]

>I think we'd be discussing you stealing
100 gallons of my gas (Gb of memory) vs. you driving on my lawn and running
over my azaleas (anything other than poor ol' Zeke).
...
To quote the Great Monty Python:
“Stop that! It's silly! It was funny once. But, now it's just silly!”

The issue is not how big is my banana.
Rather, do I have enough bananas to do my job!

It is not up to some SYSPROG who 'knows better' to decide that.

Remember, the reason we are employed is to facilitate the business.
NOT, to hinder it.

If I need an 8GB dataspace to do my job (not that far into the future), your 
job is to get it for me.
NOT, to complain that nobody else has one bigger than 20MB.

If the business has justified it, implement it!
Don't P*SS & MOAN about it.

Remember what NIKE said!
“Just do it!”

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

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

Re: Allowing Joe User into TSO

[Ed Gould]

On Oct 28, 2005, at 7:41 AM, Martin Kline wrote:


I apologize in advance for not knowing the best list to send this
question to.  (Perhaps ISPF-L?  But I'm not a subscriber there.)  I'm
proposing to our systems folks that we allow a "user" to use TSO to
get to the Zeke Work Center function.  I'm being told that there is 
no

way for us to limit what the user can do if we let them intoTSO.



Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will
require that _every function_ they need be explicitly authorized,
regardless of any existing UACC settings.


I find this interesting. Just recently, list members were objecting 
that

limiting a user's access to resources (in that case it was memory) was
probably keeping them from doing their job. Where are they now?

The argument was that if a user was requesting a resource, they MUST 
NEED
IT for their job. This seems like a very similar situation. Why not 
allow
the users access to all of ISPF, and depend on their honorable nature 
to

only use those functions that they need to do their job?



Martin,

One of the main objections I have to a "common" logon is that there is 
no accountability.


I would run the concept by the auditors.

Ed

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

Re: Allowing Joe User into TSO

[Ed Gould]

On Oct 28, 2005, at 9:16 AM, Edward E. Jaffe wrote:





--SNIP
I suppose, if we could convince Mr. Peabody to use the Wayback Machine 
to take us to the meeting where RACF's moniker was invented, we could 
insist on a more-appropriate one, like PCF = Permissions Control 
Facility.   :-\

--


Already taken PCF = Program Control Facility.

Ed

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

(fwd) Re: Allowing Joe User into TSO

[Clark Morris]

On 28 Oct 2005 15:27:30 -0700, in bit.listserv.ibm-main
[EMAIL PROTECTED] (Ted MacNEIL) wrote:

>>I think we'd be discussing you stealing
>100 gallons of my gas (Gb of memory) vs. you driving on my lawn and running
>over my azaleas (anything other than poor ol' Zeke).
>..
>To quote the Great Monty Python:
>“Stop that! It's silly! It was funny once. But, now it's just silly!”
>
>The issue is not how big is my banana.
>Rather, do I have enough bananas to do my job!
>
>It is not up to some SYSPROG who 'knows better' to decide that.

Management provides the systems programmer with x amount of machine
resource to run the business including any development work.  The
systems programmer has been told there are the following n loved ones.
The sysprog determines that it will take .9x of that resource for the
loved ones.  Someone else needs .2x of that resource to "do their
job".  How is the sysprog going to allocate that unavailable resource?

>
>Remember, the reason we are employed is to facilitate the business.
>NOT, to hinder it.
>
>If I need an 8GB dataspace to do my job (not that far into the future), your 
>job is to get it for me.
>NOT, to complain that nobody else has one bigger than 20MB.
>
>If the business has justified it, implement it!
>Don't P*SS & MOAN about it.
How?  The sysprog doesn't buy the memory, disc space, cpu cycles, etc.
If the management wants the job done, the management has to provide
sufficient resource for the sysprog to allocate.

>
>Remember what NIKE said!
>“Just do it!”
>
>-teD
>
>In God we Trust!
>All others bring data!
> -- W. Edwards Deming
>

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

Re: (fwd) Re: Allowing Joe User into TSO

[Ted MacNEIL]

>How?  The sysprog doesn't buy the memory, disc space, cpu cycles, etc.
If the management wants the job done, the management has to provide
sufficient resource for the sysprog to allocate.
...

I had said:
“If the business has justified it, implement it!”.

That assumes that a justified resource gets installed.
That's how.

I'm not saying to re-arrange the deck-chairs on the Titanic.


-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

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

Re: (fwd) Re: Allowing Joe User into TSO

[Ed Gould]

---SNIP:---
On Oct 29, 2005, at 7:00 PM, Ted MacNEIL wrote:

I'm not saying to re-arrange the deck-chairs on the Titanic.

Maybe you should add some life boats while you are at it :-)

   Ed


-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

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



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