IBM Mainframe Forum

We recently converted our Mainframe security layer from ACF2 to RACF - with the assistance of IBM. Things have been working without issue until recently, when we discovered a potentially serious security situation. One of our developers, who *should* only have Read access to Production data sets was able, via a job card, to delete a data set. This was done in error, and quickly corrected, but the issue is still present. We have tested this further, with different data sets, as well as different developers, and they have all been able to delete the data sets. Looking at our access lists (which are essentially exact replicas of the access they had in ACF2), it appears that they should only have Read access. We had been focusing on the cards as the potential issue, but the developer in question just let us know that despite what he originally thought, not only can he delete via the card, he can also delete the file manually as well. Obviously a security concern...

Any ideas on why these folks might be able to process these deletes? What should we start looking at to lock this down the way we expect it to be? Any help or guidance is greatly appreciated...we're all new to RACF, and are scrambling...

Any ideas on why these folks might be able to process these deletes?

because You(*) made a mistake in defining the profiles, plain and simple
and You(*) did not carry on enough testing

(*) not You personally but all the people involved in the conversion!
why not involve IBM directly in the issue!

enrico-sorichetti wrote:why not involve IBM directly in the issue!

Contract ran out! IBM ain't cheap

Contract ran out! IBM ain't cheap

Under what term was the original contract done?
what quality controls were agreed on?

anyway whatever the consulting company You will choose
for security related issues expect expensive fees!

The first thing I'd do is verify the test user does not have the OPERATIONS user attribute. Users with OPERATIONS are intended to be the DASD managers and can do pretty much anything they like. I regard OPERATIONS as more of a security problem that even system SPECIAL. Long, long ago when I had SPECIAL, I would not award myself OPERATIONS unless I absolutely needed it, and as soon as I completed the task that required OPERATIONS I removed it.

Next I'd check the access attributes - all of them - for the dataset, and compare them with the groups assigned to the test user. I'd make sure the UACC is not something like ALTER.

As enrico-sorichetti indicated there is a problem here that you will have to run down. Either the test user has some production attributes or the access authorizations for a production dataset is too general.

If IBM is no longer in the picture you will have to learn the business of being a secrity manger, and learn it very quickly!

Hello,

Once upon a time i was invited to a discussion as to how a new environment was to be secured. Some of the people wanted "open" security, others insisted on "closed" - some didn't care one way or the other as long as it worked.

In that gathering, open meant users could do anything that was not specifically prohibited while closed meant users could not do anything that was not specifically permitted.

Vaguely, i recall that the 3 different security products (RACF, ACF2, and TSS (Top Secret)) did not share the same philosophy.

Is it possible that this new implementation was set up as "open" (if this is still an option)?

Apologies if this is way off the mark and i'll delete it if it is. . .

You need to review the RACF profiles for the data sets. RACF specific data set profiles override generic data set profiles, but it sounds like your generic profiles either weren't set up correctly or there's some other implementation issue. This is the kind of situation that a forum cannot really help much with -- you need someone to look at your specific data and figure out what's going on.

did the IBM er involved point You to the redbooks concerning ACF2 to RACF conversion
for example
http://www.redbooks.ibm.com/cgi-bin/sea ... query=racf

and, not strictly IBM
http://home.roadrunner.com/~pinncons/AC ... rience.pdf
it makes a couple of good points to meditate on
( ACF constructs/rules that do not have a RACF equivalent )

Check the dataset profiles protecting the user catalogs where these datasets are cataloged to see if the users have ALTER access to catalogs. ALTER access to a catalog enables the user to uncatalog non-SMS managed datasets and delete VSAM files and SMS managed dataset without having ALTER access to the datasets themselves.

If this isn't the case and the datasets are on non-SMS managed DASD volumes, check the DASDVOL profiles to see if the user has ALTER access to them. This would also enable the user to delete datasets.