omvs segment



All about SAF, RACF, encryption, Firewall, Risk assessment and integrity concepts

omvs segment

Postby mehi1353 » Mon Jul 02, 2012 6:13 pm

Hi all,

In z/os V1R8 I have a user with uid=1020. I want to prevent this user(and similar users) to access the ROOT directory, when he enter omvs

segment (by "tso ishell" command). How I can do this?


best regards
mehrdad rastgar,
Behsazan Mellat co.,
Tehran.IRAN
mehi1353
 
Posts: 39
Joined: Sun Jan 11, 2009 4:51 pm
Has thanked: 0 time
Been thanked: 0 time

Re: omvs segment

Postby Robert Sample » Mon Jul 02, 2012 7:17 pm

When you say "prevent ... access", are you talking about prventing reads, writes, or executes, or all of the above? And do these users share a Unix group with ROOT? Change the permissions on the ROOT directory appropriately based on the answers to these questions.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: omvs segment

Postby mehi1353 » Tue Jul 03, 2012 9:37 am

Hi,

I mean "banding Anonymous access to omvs segment from RACF".
Is there anyway?
mehi1353
 
Posts: 39
Joined: Sun Jan 11, 2009 4:51 pm
Has thanked: 0 time
Been thanked: 0 time

Re: omvs segment

Postby Robert Sample » Tue Jul 03, 2012 5:16 pm

Since I have no idea what this means, I have no ideas:
"banding Anonymous access to omvs segment from RACF"
I do think you need to spend several days reading some basic Unix manuals to understand access controls in Unix, since Unix System Services access in z/OS works mostly on the Unix access controls principles.

Further, your first post provided a specific UID, yet your last post mentions "Anonymous access" - perhaps you need to decide what you want, first? Anonymous access and a specific UID are complete opposites. Plus, anonymous access is usually applied to FTP sessions and you've not mentioned anything yet about FTP.

Basically, your questions are so vague and subject to interpretation so much that they cannot be answered as you've posted them.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: omvs segment

Postby Ed Goodman » Tue Jul 03, 2012 6:12 pm

Maybe he meant "banning" instead of "banding"?

banning = preventing entry

banding = wrapping something in a band of material, like a bandage on a wound, or one of those straps you see on stacks of money.
Ed Goodman
 
Posts: 341
Joined: Thu Feb 24, 2011 12:05 am
Has thanked: 3 times
Been thanked: 17 times

Re: omvs segment

Postby jaggz » Wed Jul 04, 2012 12:14 pm

Hi,

In most of the shops Access to Root directory are not allowed for a normal users but some of the Product based path would be provided if only when it is required(Like DB2 or CICS or Java). If you feel the user or the permission levels have changed then you can just restrict the level of access based on the path.

Any particular path you want to restrict ? Reading a Unix security service guides or any manual commands would give you more idea to plan the security enforcement.

Jaggz
User avatar
jaggz
 
Posts: 356
Joined: Fri Jul 23, 2010 8:51 pm
Has thanked: 8 times
Been thanked: 5 times

Re: omvs segment

Postby dick scherrer » Thu Jul 05, 2012 8:42 am

Hello,

And unless you Are the Security Support, you should set up this with the Security Admins.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: omvs segment

Postby angrybeaver » Wed Jul 11, 2012 5:33 am

If you want to explicitly deny a given ID you can use the setfacl command (man setfacl for all the manpage goodness that it has to offer). This is the file level ACL controls. So not only do you have the POSIX ownership control of Read Write eXecute for the User (that owns the file), the Group (that owns the file) and Other (everybody else on the system) you have a more granular level similar to ACL entries on a RACF profile where you can include and exclude other IDs or groups explicitly like you would with a PERMIT. In general I find it a bit absurd that folks build a new RACF group or go around changing OWNERSHIP to protect a specific folder in some cases when ACCESS CONTROL is separate from OWNERSHIP control (ie; this is like changing the owner of a profile to a new group to make the access work instead of adding new permits).

A quick example of the commands use:

First line allows the user ABC123 full read/write/execute access on existing files in the folder.
Second line allows the user ABC123 full read/write/execute access on files that will be created in the future.
setfacl -m user:ABC123:rwx /root/*
setfacl -m fdefault:user:ABC123:rwx /root/

Not sure if you meant root (/) or root (/root) directory by the way... in general the /root directory (and all individual home directories) should be chmod'd 700' and chown'd user:user. If you are going to break with this convention to "make some product work" you may have some other unintended consequences. In general, assuming somebody hasn't gone and chmod 777'd the /root or / directory per some installation guide you should already have adequate access in place since the user likely wouldn't own the directory or be in the group that owns the directory and the "other" access which covers them would be non-existent.
angrybeaver
 
Posts: 11
Joined: Sat Jan 21, 2012 10:09 am
Has thanked: 0 time
Been thanked: 1 time


Return to Mainframe Security

 


  • Related topics
    Replies
    Views
    Last post