Unix Security

[Klavon John R]

Does anyone have a good suggestion for setting up (Superuser id or UID(0) for 
individuals that require the access. They would like to set up as few users as 
possible to satisfy the auditors..
 
The information contained in this e-mail may be confidential and is intended 
solely for the use of the named addressee.
Access, copying or re-use of the e-mail or any information contained therein by 
any other person is not authorized.
If you are not the intended recipient please notify us immediately by returning 
the e-mail to the originator.(16b)

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

Unix Security

[ANGEL LUIS DOMINGUEZ MARTIN]

  For a batch jobs, we use a SUBRROGATED user to gain UID(0) access. For online 
acces you can use FACILITY class from RACF o similar..
   
  The intention is that the user msut do something specifically to obtain 
access, but not have it in his normal operation.  
   
  angel luis domínguez  
  bbva - spain 
   
  
--
  Klavon John R [EMAIL PROTECTED] said:
   
  Does anyone have a good suggestion for setting up (Superuser id or UID(0) for 
individuals that require the access. They would like to set up as few users as 
possible to satisfy the auditors..


-

LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.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: Unix Security

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Klavon John R
> Sent: Monday, November 13, 2006 8:56 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Unix Security
> 
> 
> Does anyone have a good suggestion for setting up (Superuser 
> id or UID(0) for individuals that require the access. They 
> would like to set up as few users as possible to satisfy the 
> auditors..
>  

Don't. Do. That.

There is no need for a "live person" to have UID(0) as their normal UID.
There are a whole set of RACF facilities to allow a person many of the
functions normally granted by UID(0). Start reading at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB270/4.6

If nothing else, grant RACF read authority to BPX.SUPERUSER in the
FACILITY class to the people who need it. This will allow them to "su"
for root (UID 0) access as needed. There are a lot of profiles starting
with BPX. in the FACILITY class to allow people to do superuser-like
functions. There are many more profiles in the UNIXPRIV class to also
let non-root people do things.

If a "live person" must run a batch job which demands root, then set up
a SURROGAT profile to allow them to submit a job with the USER=
specifying the id in the SUPERUSER() parameter of BPXPRMxx in PARMLIB.

We __never__ allow an "interactive" user to have UID(0) in their OMVS
segment. Only a very few PROTECTED RACF userids have UID(0). In fact,
there are only two in my shop. There is the SUPERUSER in the BPXPRMxx
member and there is a separate one for the HTTPD server. The only reason
I have two is so that the RACF accesses to non-UNIX datasets is more
controlled for the HTTPD server id. These ids are only used for specific
started tasks such as TCPIP and other UNIX daemons.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Unix Security

[R.S.]

McKown, John wrote:
[...]

If nothing else, grant RACF read authority to BPX.SUPERUSER in the
FACILITY class to the people who need it. This will allow them to "su"
for root (UID 0) access as needed. There are a lot of profiles starting
with BPX. in the FACILITY class to allow people to do superuser-like
functions. There are many more profiles in the UNIXPRIV class to also
let non-root people do things.

If a "live person" must run a batch job which demands root, then set up
a SURROGAT profile to allow them to submit a job with the USER=
specifying the id in the SUPERUSER() parameter of BPXPRMxx in PARMLIB.

We __never__ allow an "interactive" user to have UID(0) in their OMVS
segment. Only a very few PROTECTED RACF userids have UID(0). In fact,
there are only two in my shop. There is the SUPERUSER in the BPXPRMxx
member and there is a separate one for the HTTPD server. The only reason
I have two is so that the RACF accesses to non-UNIX datasets is more
controlled for the HTTPD server id. These ids are only used for specific
started tasks such as TCPIP and other UNIX daemons.


IMHO the better idea is to have dadicated user fo BPXPRMxx SUPERUSER. It 
should be very limited userid. Not used anywhere.

Daemons should use other userid(s).

BTW: whye the "live person" shouldn't have UID(0) ?
I mean person who really needs it, not everyone.

--
Radoslaw Skorupka
Lodz, Poland

--
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: Unix Security

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of R.S.
> Sent: Monday, November 13, 2006 9:58 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Unix Security
> 



> 
> IMHO the better idea is to have dadicated user fo BPXPRMxx 
> SUPERUSER. It 
> should be very limited userid. Not used anywhere.
> Daemons should use other userid(s).
> 
> BTW: whye the "live person" shouldn't have UID(0) ?
> I mean person who really needs it, not everyone.
> 
> -- 
> Radoslaw Skorupka

Personal opinion time on that last question.

1) I've never seen anybody who "really needs it" when the other RACF
facilities are properly set up.

2) Auditors tend to not like it. So avoid an unnecessary fight with
them. Especially in view of the above.

Those two are sufficient for me. As to started tasks which need UID(0)
running with different RACF ids, that is OK by me. At one time, I wanted
a unique RACF id for every STC. However, given that the majority of STCs
(ignoring CICS mainly) are "single purpose" and said purpose is limited,
it just got to be a pain to maintain. Not to mention that other sysprogs
kept wanting "test" STCs and wouldn't usually bother to ask me to set up
a unique RACF id for it, because "it is only for a short test". Granted,
I could set RACF up so that such STCs would likely die from RACF errors,
but this is a small shop and, again, I considered it to be "over kill".

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Unix Security

[R.S.]

McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of R.S.

Sent: Monday, November 13, 2006 9:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Unix Security





IMHO the better idea is to have dadicated user fo BPXPRMxx 
SUPERUSER. It 
should be very limited userid. Not used anywhere.

Daemons should use other userid(s).

BTW: whye the "live person" shouldn't have UID(0) ?
I mean person who really needs it, not everyone.

--
Radoslaw Skorupka


Personal opinion time on that last question.

1) I've never seen anybody who "really needs it" when the other RACF
facilities are properly set up.

2) Auditors tend to not like it. So avoid an unnecessary fight with
them. Especially in view of the above.


IMHO it's sometimes easier to have UID(0) than issuing su everytime. 
Less effort, less errors.
As you wrote it's because auditors want it. I understand your point, 
however I'm curious whether there's any real reason.



Those two are sufficient for me. As to started tasks which need UID(0)
running with different RACF ids, that is OK by me. 
So, you're using "generic UID(0) for STC" and dedicatd user for WAS. 
That's OK.
My suggestion is to avoid using BPXPRM SUPERUSER as "generic UID(0) for 
STC". Assuming some hacker will get UID(0) the system will assign him 
the "SUPERUSER" userid. That's why it is good to define it as much as 
restricted.


Regards
--
Radoslaw Skorupka
Lodz, Poland

--
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: Unix Security

[Patrick O'Keefe]

On Mon, 13 Nov 2006 17:28:47 +0100, R.S. <[EMAIL PROTECTED]> 
wrote:

>...
>As you wrote it's because auditors want it. I understand your point,
>however I'm curious whether there's any real reason.
>

I strongly agree with John on this.  Even if no auditors were involved,
giving a person UID(0)is giving far too much authority than is needed.
To do that is to give the person a gun and paint a target on his or her 
foot (or on the whole shop's collective foot).  Requiring setting SU in 
TSO or doing a setuid(0) or seteuid(0) in batch hopefully puts the user
in "be careful" mode.
   
>...
>My suggestion is to avoid using BPXPRM SUPERUSER as "generic UID(0) for
>STC". Assuming some hacker will get UID(0) the system will assign him
>the "SUPERUSER" userid. That's why it is good to define it as much as
>restricted.
>...

Good heavens.  I don't think there was any suggestion to have the default 
userid have BPXPRM.SUPERUSER access. The default id should have as little
autoroty as possible.  The "generic UID(0)for STC" would hopefully not
be useable by a person - would not have a password.  I'm way out of my
area of expertese here, but I think all the major security products have
that capability.

I think we need to repeat John's "no person with UID(0)" plea often and
loudly because we have to counteract those Program Directories (and 
non-IBM equivalents) that still say UID(0) is required.  Many product
still have installation instructions claiming this because the packagers
are to lazy to determine their true needs.  And don't care that they are
are advocating a security and integrity exposure.

Pat O'Keefe
   

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

VS: Unix Security

[Lindy Mayfield]

For what reasons would a program need UID(0)?

The only reason I can think of is when a daemon is starting processes and 
switching the userid.  And here IBM made things really easy, I think.  A daemon 
running with a standard userid and with RACF setup for program control, can 
switch the userid after a successful call to BPX1PWD (__passwd()), then if it 
needs to do a spawn() (BPX1SPN).

Is this correct?  

Lindy

-Alkuperäinen viesti-
Lähettäjä: IBM Mainframe Discussion List puolesta: Patrick O'Keefe
Lähetetty: ma 13.11.2006 21:49
Vastaanottaja: IBM-MAIN@BAMA.UA.EDU
Aihe: Re: Unix Security
 
On Mon, 13 Nov 2006 17:28:47 +0100, R.S. <[EMAIL PROTECTED]> 
wrote:

I think we need to repeat John's "no person with UID(0)" plea often and
loudly because we have to counteract those Program Directories (and 
non-IBM equivalents) that still say UID(0) is required.  Many product
still have installation instructions claiming this because the packagers
are to lazy to determine their true needs.  And don't care that they are
are advocating a security and integrity exposure.

Pat O'Keefe
   


--
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: Unix Security

[R.S.]

Patrick O'Keefe wrote:

On Mon, 13 Nov 2006 17:28:47 +0100, R.S.
<[EMAIL PROTECTED]> 
wrote:




...
As you wrote it's because auditors want it. I understand your point,
however I'm curious whether there's any real reason.




I strongly agree with John on this.  Even if no auditors were involved,
giving a person UID(0)is giving far too much authority than is needed.
To do that is to give the person a gun and paint a target on his or her 
foot (or on the whole shop's collective foot).  Requiring setting SU in 
TSO or doing a setuid(0) or seteuid(0) in batch hopefully puts the user

in "be careful" mode.


I dare to disagree. No, I STRONGLY DISAGREE!
What are your procedures for RACF SPECIAL user ? Are they so restrictive?
What about storage administration ?
I remember a shop with few newbies working as storage administrators. I 
protected "ICKDSF" by DASDVOL activation. They didn't get ALTER to 
DASDVOL profiles. Instead, they got CL(SURROGAT) STGUSER.SUBMIT 
ACC(READ) and STGUSER has ALTER. So they were able to use ICKDSF, but 
not screw something up using ISPF "oops! typo navigation".


SU everytime is similar (IMHO worse!) method for USS "newbie 
administrator", but it is unneeded for experienced person who need 
UID(0) everyday.
Last but not least: UID(0) on z/OS Unix is less than on any other Unix 
implementation. However AIX/HP-UX/Solaris/whatever administrators use 
UID(0) for everyday work.


My $0.02
Regards
--
Radoslaw Skorupka
Lodz, Poland

--
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: Unix Security

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of R.S.
> Sent: Tuesday, November 14, 2006 1:51 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Unix Security



> 
> SU everytime is similar (IMHO worse!) method for USS "newbie 
> administrator", but it is unneeded for experienced person who need 
> UID(0) everyday.

Out of curiousity, what function requires uid(0) for an interactive
user? I am the 99.999% UNIX administrator here. Most of the others are
"blistfully" unaware of z/OS UNIX. I do not have uid(0). I've never
missed it. I can ISHELL edit any file on the system (RACF profile). I
can delete any file on the system. I can rmdir or mkdir anything,
anywhere on any filesystem.

The only thing that I have run into where my access fails is when pax
does an fchattr (I think that's it). So I do an "su", then a "pax", then
"exit" to go back to my normal id.

Of course, you can argue that I have the power of uid(0) without the
actual uid(0), so how is that "safer"? I can agree with that assesment.
The only way is that my unique uid is logged so I know "who done it". If
multiple people have uid(0), then I cannot always figure out "who done
it". This is an audit point for us.

> Last but not least: UID(0) on z/OS Unix is less than on any 
> other Unix 
> implementation. However AIX/HP-UX/Solaris/whatever administrators use 
> UID(0) for everyday work.

So? Many recent Linux distros are no longer set up this way (Ubuntu
comes to mind). In fact, some even go so far as to remove the ability to
logon to root entirely. They do this by proper use of "sudo".
Unfortunately, z/OS UNIX does not have sudo. I worked for a short time
with some AIX people. None of the AIX administrators routinely ran with
uid(0). They used sudo for the "dangerous" stuff. The plus of sudo is
that it leaves an audit trail of who really did what. Again, an audit
point. Auditors like knowing who did what to which and when .


> 
> My $0.02
> Regards
> -- 
> Radoslaw Skorupka



--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Unix Security

[Shane]

Must admit I'm a little ambivalent on all this.
Back in the day, you couldn't even do installs invoking pax without
UID(0). Thanks IBM.
Eventually they got round to giving us some profiles that covered bits
and pieces. Then we got some more, and eventually most of what we
needed. Way too late, and badly managed.
Those that were diligent and those late to the game are probably set up
"correctly".  Me, I have a batch user that I have surrogacy to, and
interactively I SU in need.

Ho hum ...

Shane ...

--
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: Unix Security

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 11/13/2006
   at 09:55 AM, Klavon John R <[EMAIL PROTECTED]> said:

>Does anyone have a good suggestion for setting up (Superuser id or
>UID(0) for individuals that require the access.

Yes - check whether they really need it. The last time I had RACF
SPECIAL I wouldn't even give myself UID(0), and that was *my*
decision, not handed down from on high. Find out what they're doing
and determine:

 1. Can the privileged work be done in batch under a surrogate userid?

 2. Can the privileged work be done with a lesser privilege level?
 
-- 
 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

Z/OS UNIX Security

[Carlson, Steven]

 We are just starting to get heavenly involved in the OMVS environment. We are 
using CA-ACF2 for our security package.
We are also starting to get involved in the CICS WEB access environment. My 
questions are:

1) Is there another way to protect the OMVS environment instead of using 
HFS Security under ACF2?
2) We would like to provide certain access to certain OMVS directories for 
the outside client, is there a product that will interface with CICS/TSO/IDMS 
that will provide the security protection?
3) I have created the ACF2 HFS security rules, and a Default OMVS group ID 
and a Default OMVS user ID. I am trying to find a way to have this security 
protection without creating an ACF2 OMVS profile record, and an OMVS user 
directory entry for every user accessing the mainframe. Is there another way to 
provide this?


--
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: Z/OS UNIX Security

[Big Iron]

1. Besides CA ACF2 SAF HFS Security, you can use the standard native
Unix security based on the Unix ownership fields & permission bits. You
can supplement that security system with ACLs (access control lists) if you 
want to.
2. not sure what you mean by that
3. I am not sure how it works with the SAF HFS Security provided by
ACF2, but normally the default OMVS user profile applies to every MVS
user who does not have an OMVS user profile. These users would share
the same home directory as the default user. ACF2 also provides a bit
setting that allows you to exclude specific users from OMVS access (if you
need to do that).

Bill

On Thu, 5 Jun 2008 09:54:19 -0700, Carlson, Steven <[EMAIL PROTECTED]>
wrote:

> We are just starting to get heavenly involved in the OMVS environment. We
are using CA-ACF2 for our security package.
>We are also starting to get involved in the CICS WEB access environment. My
questions are:
>
>1) Is there another way to protect the OMVS environment instead of
using HFS Security under ACF2?
>2) We would like to provide certain access to certain OMVS directories
for the outside client, is there a product that will interface with
CICS/TSO/IDMS that will provide the security protection?
>3) I have created the ACF2 HFS security rules, and a Default OMVS group
ID and a Default OMVS user ID. I am trying to find a way to have this
security protection without creating an ACF2 OMVS profile record, and an
OMVS user directory entry for every user accessing the mainframe. Is there
another way to provide this?
>
>

--
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: Z/OS UNIX Security

[Steve Comstock]

Carlson, Steven wrote:
 We are just starting to get heavenly involved in the OMVS environment. 

Ahh. Divine intervention ..




We are using CA-ACF2 for our security package.

We are also starting to get involved in the CICS WEB access environment. My 
questions are:

1) Is there another way to protect the OMVS environment instead of using 
HFS Security under ACF2?
2) We would like to provide certain access to certain OMVS directories for 
the outside client, is there a product that will interface with CICS/TSO/IDMS 
that will provide the security protection?
3) I have created the ACF2 HFS security rules, and a Default OMVS group ID 
and a Default OMVS user ID. I am trying to find a way to have this security 
protection without creating an ACF2 OMVS profile record, and an OMVS user 
directory entry for every user accessing the mainframe. Is there another way to 
provide this?


Steve,

I see you're getting some good suggestions. For my focus,
when you feel comfortable with the OMVS environment, you
should plan to educate your developers in how to use this.

Ahem.



Depending on what your needs are, you might find one or
more of these courses useful...

For the price of a few days of training we can turn your
traditional z/OS applications developers into web-on-z/OS
applications developers.

Using the free (well, included-in-the-price) z/OS UNIX
System Services, HTTP server, and the language of your
choice. For example:

"Introduction to z/OS UNIX" - 3 days

   in just 3 days, the students can get around in
   the z/OS UNIX world comfortably, including each
   student creating their own [small] website hosted
   on the z/OS system; optional section on telnet



"Shell Script Programming in z/OS UNIX" - 3 days

   this course extends the above course with more
   UNIX commands, how to create and run scripts,
   and other useful UNIX skills such as the sed
   editor; optional sections on vi



"You and z/OS and the World Wide Web" - 5 days

   this course is an intensive, standards-based
   (open source) coverage of skills to create
   and maintain sophisticated websites hosted on
   you mainframe, without the need to license
   WebSphere; lightweight (does not drag down the
   system performance) and inexpensive (the HTTP
   server comes included with z/OS for no extra
   charge)



"Devloping Applications on z/OS UNIX" - 3 days **

   this course integrates coding programs in the
   classic languages, compiling under z/OS UNIX,
   and running under a UNIX shell; multi-lingual
   (Assembler, COBOL, PL/I, C)


Related: a series of courses on how to code and use
CGI (Common Gateway Interface) programs to complement
your z/OS-hosted website; multi-lingual; considering
new courses in Apache, Tomcat, php, ruby, SOA, Web
Services, Ajax, Wikis, and more, as demand / interest
dictate.

Start here and follow the links:
http://www.trainersfriend.com/UNIX_and_Web_courses/unixcurric.htm




Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four<==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==>   http://www.trainersfriend.com/TTFStore/index.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: Z/OS UNIX Security

[Hunkeler Peter (KIUK 3)]

>1) Is there another way to protect the OMVS environment 
>   instead of using HFS Security under ACF2?

I admit, I don't have practical experience with "HFS security under 
ACF2", but I can't get rid of my bad feeling about this. If you're 
going to be using z/OS UNIX, you should understand UNIX security 
and what UNIX applications can do with it, and what they expect. 
I would not use anything else than permission bits and ACLs provided 
by z/OS UNIX file systems. Just my $0.02

>2) We would like to provide certain access to certain OMVS 
>   directories for the outside client, is there a product 
>   that will interface with CICS/TSO/IDMS that will provide 
>   the security protection?

I would always want to be able to exactly know who was doing what 
when people get "direct" access to data. This implies that users 
accessing data have to identify themselves with a unique userid. 
Now, if this access encompasses the UNIX file system, then users 
also need to identify themselves with a unique UNIX id, i.e. uid.

I'd try to avoid implementing the default uid/gid whenever possible. 
Sooner or later you might start using NFS to access other UNIX 
server's data. All your users yould be seen as a single user by 
those servers. Probably not what you want.

Just another $0.02 of mine, which makes it $0.04 so far. Budget is 
used up, so I'll have to stop here :-)

-- 
Peter Hunkeler
Credit Suisse

--
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: Z/OS UNIX Security

[Veilleux, Jon L]

Snip
I admit, I don't have practical experience with "HFS security under
ACF2", but I can't get rid of my bad feeling about this. If you're going
to be using z/OS UNIX, you should understand UNIX security and what UNIX
applications can do with 
it, and what they expect. 
I would not use anything else than permission bits and ACLs provided by
z/OS UNIX file systems. Just my $0.02 
End snip

I have at least a passing familiarity with UNIX 'security' and I feel
just the opposite. We use TOP SECRET HFSSEC and it is MUCH more robust
than UNIX security bits and allows for control by our centralized
security department. UNIX security bits can be changed by the user to
allow anyone access to their files whether that complies with corporate
policy or not. Centralizing security gives us the ability to enforce
policy and keep a better handle on file access.


Jon L. Veilleux 
[EMAIL PROTECTED] 
(860) 636-2683 

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
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: Z/OS UNIX Security

[Rob Schramm]

I would tend to agree with most of the posters in regards to using the 
normal unix permission bits.  If you are thinking about doing some sort of 
file sharing with non-z/OS system, then getting used to the unix 
permission bits is helpful.  While at one time the default UID and default 
GID seemed like a good thing, I think it generates as many if not more 
problems than it solves.

I am also in agreement with the poster indicating that the SAF HFS 
Security supplied by ACF2 could supply additional controls.  It all 
depends on what your goal is.  Personally, I stayed away from the SAF HFS 
Security to allow for the ease of converting to RACF (prior life) and 
because I didn't need the additional controls.

As far as creating a record for everyone, tracking for the HFS useage is 
much better if you just go thru it.  I am sure you probably already have a 
fairly stock setup for user creation.  Just add the UID/GID assignment to 
it.  You'll be better off in the long run. 

There is also the idea of auto-UID assignment in user ID creation as well 
as a auto-UID assignment that is more generic.

Just my 2 cents,

Rob Schramm
Sirius Computer Solution


--
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: Z/OS UNIX Security

[Natarajan Mohan]

Steve,

I will try this approach.

- Create userid's and assign their home. T PROF(USER) DIV(OMVS) and cha user1 
home(/u/user1)
- Setup automount on omvs
- Create a file auto.master in /etc with "/u /etc/u/map"
- Create a file u.map in /etc with






#  
# Automount Map File for /u #  
#  
name * 
type HFS   
filesystem .&SYSNAME..HOME.HFS
mode rdwr  
duration nolimit   
delay 360  
allocany space(10,5) tracks  maxvol(3) 
This should create HFS file for each user under their TSO ALIAS. Which is 
protected by ACF2 on default. As long as the user's have only read access to 
other needed system directories they should not be able to access each others 
files.
- Add automount in BPXPRM00


  FILESYSTYPE  TYPE(AUTOMNT)   
  ENTRYPOINT(BPXTAMD)
You might have to IPL to enable automount. Once its enabled, its easy to add 
more mount points as needed by using the command from a USS SHELL
 /usr/sbin/automount -a 
 
To verify the current settings you could do the same via a command 
 /usr/sbin/automount -q
 
Hope this helps
Natarajan
 
 

NOTICE OF CONFIDENTIALITY 

The information contained in this communication, including but not limited to 
any accompanying document(s) and/or attachment(s), is privileged and 
confidential and is intended solely for the above-named individual(s). If you 
are not the intended recipient, please be advised that any distribution, 
copying, disclosure, and/or use of the information contained herein is strictly 
prohibited. If you received this communication in error, please destroy all 
copies of the communication, whether in electronic or hard copy format, and 
immediately contact the Security Office at EDFUND at (916) 526-7539 or [EMAIL 
PROTECTED] Thank you.

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