Re: STG(*FREE) on SAV* commands...

Ken,

The issue of the STG(*FREE) command just highlights the pre-existing danger of people running with *SAVSYS special authority. Even before there were save files there was the issue of a person with *SAVSYS special authority being able to save objects that they were *EXCLUDED to onto a tape and then transporting that tape to another system where they had sufficient authority to restore the tape and view data.

STG(*FREE) adds risk because it allows a person to save the data to tape and effectively empty the contents of the object in the process. The saving grace is that the data is on a tape somewhere that you should be able to restore it from that tape.

But *SAVF's changed the game completely. Now a user with *SAVSYS that is *EXCLUDED from a file doesn't need another system to view the data. They can just save it to a save file, restore it to their own library and view the data. And as you've pointed out, if some bozo saves to a SAVF with STG(*FREE) and then deletes the save file, the data is gone before you can say "Uh-oh".

So, I guess the moral is, don't give many people *SAVSYS. Give it to the programs that do your backups (through adopted authority), and give it to selected people, but it should not belong to anyone in the *PGMR class (and hasn't by default since V3R6), and it probably shouldn't be given to System Operators either - better to have them run programs that do a SAVxxx command than to allow them to freehand it.

JMHO,

jte




On Dec 7, 2009, at 10:34 AM, Graap, Kenneth wrote:

I agree... Deleting the *SAVF would defeat the point of using STG(*FREE) ... That is the point. You can do exactly that.

The point I was trying to make in my example though, is that if a user with *SAVSYS authority saved a file to a SAVE FILE using STG(*FREE) and then deleted the SAVE FILE, the object would effectively be removed from the system, because the data portion of the object is gone and it couldn't be restored because the save file containing the data was also removed. Since the user executing this SAV command creates the SAVE FILE they could delete it without having *ALLOBJ authority because they own it.

Kenneth
Kenneth E. Graap
http://www.linkedin.com/in/kennethgraap


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx ] On Behalf Of CRPence
Sent: Monday, December 07, 2009 10:21 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: STG(*FREE) on SAV* commands...

Graap, Kenneth wrote:

Does anyone utilize the STG(*FREE) option that is available on most of
the SAV commands?

The reason I ask is that having access to the SAV* commands and also
having *SAVSYS Special Authority, gives a user the authority to
effectively delete any object on the system, by using the
STG(*FREE) parameter.

If this is the only concern being expressed for a user having the special value *SAVSYS, then there are surely more serious concerns being overlooked. Since only the "data" portion of the object is removed rather than the object [and thus its authorities, etc.], IMO "effectively delete" is a bit

Example -

SAVOBJ OBJ(UFILE1) LIB(PRODLIB) DEV(*SAVF) OBJTYPE(*FILE)
SAVF(MYLIB/MYSAVFILE) UPDHST(*NO) STG(*FREE) DLTF
FILE(MYLIB/MYSAVF)

Deleting the object would defeat the point of saving *FREE; i.e.
the given script, with the delete file request, is then little different than having saved with STG(*KEEP). Also, the *SAVSYS gives no special ability to DLTF, beyond data removal achieved by the STG(*FREE) which was enabled by *SAVSYS; i.e. the DLTF would have failed expect if authorized to the user, perhaps by *ALLOBJ special authority. Thus presumably the inclusion of DLTF in the above example was not intended.?

Being able to save objects that a programmer or operator doesn't have
direct authority to, may be a useful function that Special Authority
*SAVSYS addresses, but the security risk associated with STG(*FREE)
makes giving this authority to anyone extremely risky.

The bigger security problem for the Save System special authority is actually for the ability to *restore* objects. Saving is a concern too, especially for STG(*FREE) [due more to implications in difficulties that can be experienced from misuse of suspended objects than for the security aspects].

I understand that there are ways to mitigate this risk. The easiest is
to severely restrict who gets *SAVSYS Special Authority OR restrict
access to the SAV* commands OR force
STG(*KEEP) via an exit or validity checking program.

Better IMO to just limit that special authority to individuals who can be trusted, just as what must be done with other special authorities. All special authorities require a level of trust beyond just private authorities.

But if there isn't really any reason to free storage in the first
place, we wouldn't have to worry about this security risk at all...

The ability to save "storage freed" enables leaving the object and the private authorities [etc.] intact, while removing the storage required for its data. There are valid reasons to /suspend/ the objects using the feature provided on the save commands.

This is why I'm wondering what the original purpose of having the
STG(*FREE) option might have been...

Offline storage while maintaining ownership & authority for the object. Later the suspend feature implementing STG(*FREE) enabled
the auto-restore feature for nearline storage capabilities. The
automatic restore is most effective using "robot" magnetic media libraries; i.e. media can be chosen, loaded into a device, and restored from without operator intervention.

Is this something IBM should consider removing from the SAV commands?

No. Those depending on the function would be impacted from an incompatible change. Many customers are using BRMS, ROBOT, and other functions for B&R built over SAV* using STG(*FREE), using the feature most probably along with the auto-load\restore feature to bring the data online "on demand".

Discussion ... Comments ????

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l .

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
John Earl
President and CEO
Patrick Townsend Security Solutions
"The Encryption Company"

Olympia, WA | www.patownsend.com
Office: 360-357-8971 Ext 118