Disk Wipe Free Space for VMS?

I was wondering if anyone knew of a utility that could wipe (erase, i.e. write all zeros) the free space on a online in-use VMS disk drive??

This "wipe free space" function seems to be a popular option on Microsoft Windows-based freeware (such as CCleaner) and, therefore, has the attention of a certain class of IT security folks.

I know about $ SET VOLUME /HIGHWATER_MARKING and /ERASE_ON_DELETE but, for performance reasons, we have decided to not to implement them.

I was hoping for something that could be run on, say, a nightly basis that would erase the free space on a active disk, while still having most of the free space available to running programs. If it had to allocate a chunk and zero it out, that'd be fine. I understand there would still be a window of opportunity during the same day the file was deleted where it is not zeroed.

I'd think the ideal utility would read each block and see if it is all zeros first before doing the over-write. I wonder if it could be smart enough to know what blocks were used and deleted by the system since last time it ran and have a mode to only work on those.

The best I've been able to come up with in DCL is to get the number of free blocks on a disk and do:

$ copy/alloc={free blocks} nl: {disk}:[000000]x.x

$ set file/end_of_file {disk}:[000000]x.x

$ delete/erase {disk}:[000000]x.x;

This works except it has the drawback of running the disk out of space for the duration of the delete /erase causing failures for anything else trying to write to the disk at the same time.

This would prevent someone from using the DFU UNDELETE command from getting back a file or a non-prived user from doing the same as above to allocate a chunk of free space and look inside it (perhaps with DUMP) to see if there is anything of interest in it.

In addition to the security implications, I've heard that VMS engineering is considering supporting the "reclaim" feature of a storage arrays function of thin provisioning. I believe the free space would need to be zeroed out for this to work and there would need to be a way to do this afterwards if erase on delete wasn't originally used.

Re: Disk Wipe Free Space for VMS?

Enable both file erase on delete and volume highwater marking, and this will close the security hole that the free-space overwrite approach can leave you with.

With these settings enabled, VMS won't let you at unallocated space, and will erase space before releasing it, rather than requiring clean-up after the release.

To overwrite the free space, just create a file that's the same size as your free space. Pragmatically, any old run-away DCL file write program will do, too. (There are various other approaches. Not the least of which is transfering the data to a disk that was INITIALIZE /ERASE'd and that also has these settings enabled.)

And there are previous discussions of overwriting free space on an OpenVMS disk. Google can be your friend here.

There are a other considerations here, too. Such as what happens with disk errors; "normal" overwrite and freespace tools won't help there.

Re: Disk Wipe Free Space for VMS?

> I know about $ SET VOLUME /HIGHWATER_MARKING and /ERASE_ON_DELETE but, for performance reasons,

> we have decided to not to implement them.

But instead you want to write zeros to all free blocks every night? This is flawed logic.

State 1: disk with /NOHIGH/NOERASE and a nightly wipe of free disk space

State 2: disk with /HIGH/ERASE

Consider an individual block on the disk.

In State 1, if the block is in free space it will be overwritten every night. That's a lot of I/Os! If it's part of a deleted file, it will be potentially exposed to scavenging for the time between deletion and the nightly erase.

In State 2, the block is never vulnerable to scavenging, and it will only be zeroed when/if the file containing it is deleted.

In the long term, unless your disks are close to capacity, State 1 will incur orders of magnitude more I/Os than State 2, and it leaves large vulnerability windows open to exploitation. Granted, the work may be when the system is lightly loaded, but think about the issues of using up write cycles (SSDs) and giving all the caches in the I/O path very wrong information about access patterns.

The downside of DELETE/ERASE is, for large files, the DELETE operation itself may take longer than /NOERASE, because it doesn't return until the erasure has completed. A fairly simple workaround:

$ BIGDELETE == "SPAWN/NOWAIT/NOLOG DELETE/ERASE/LOG"

(I'm not sure how DELETE/ERASE responds to ^Y - there may be vulnerabilities, left as an exercise to fix).

On the other hand, /ERASE is probably overkill. Just SET VOLUME/HIGHWATER/NOERASE should be sufficient security, with minimal overhead, especially for anyone who would accept State 1 as a solution!

For the immediate issue of how to erase the free space "now", I'd use your existing code.

Re: Disk Wipe Free Space for VMS?

Ok. Thanks for the replies. I forgot to mention that I did Google fairly extensively looking for a tool like this to no avail.

Perhaps I misspoke when I said we don't implement /ERASE or /HIGHWATER "for performance reasons" - I meant for faster access by users. If their program needs to create or delete a huge file, the time difference with these turned on versus turned off is substantial. However, we would have the time after hours to try and scrub the deleted blocks.

As I mentioned, I was hoping for a utility that would be smart enough to tell what the majority of the blocks that were freed up that past day and just zero out those. Similar to the way various UNDELETE utilities (like in DFU) are able to "restore" the deleted blocks of files but instead zero out those blocks. I understand that the I/O to wipe all free space on all disks on a nightly basis could be excessive and shorten the life of the hardware. However, similar loads are placed on disks for things like tools that do disk defragmentation. Speaking of which, perhaps this would be best done as an option of the defragmentation /CONSOLIDATE_FREESPACE pass.

Re: Disk Wipe Free Space for VMS?

Dave,

There is no log of "blocks deleted today". The Windows tools that I can think of off-hand erase all unallocated clusters.

UNDELETE-type programs are not a good example. UNDELETE-type programs use the fact that file headers are not scrubbed to "recover" the file header. If one is concerned about the actual bits on the disk, there are only a few approaches that work to any level of assurance:

- Highwater mark/erase on delete

- erase ALL unallocated blocks (and there are issues without highwater marking)

I can think of some other more sophisticated ideas, but that would be a discussion for offline.

Re: Disk Wipe Free Space for VMS?

David,

>has the attention of a certain class of IT security folks.

That would be the class of IT security folks who care more about appearance than actual substance?

Performance is a side issue. If your objective is to protect your data from scavenging, then the post hoc approach is just plain WRONG. Leaving a time window where data is vulnerable to scavenging is pretty much pointless from a security perspective. Making a utility to wipe free space just legitimises a flawed idea that it somehow improves security. Indeed, I'd argue it does the opposite by generating a false sense of security. A real world analogy would be having a building policy that all doors are left unlocked, but a robot does a sweep of the building locking all the doors at 9pm every night. That should keep the building secure, shouldn't it?

>If their program needs to create or delete a huge file, the time difference with these turned on versus turned off is substantial

Granted, DELETE/ERASE will take longer than /NOERASE (but have you considered using SPAWN/NOWAIT to do it in the background?) Highwater marking should NOT affect allocation or deallocation times, UNLESS your programs are allocating space, then moving the EOF - which would be rather unusual. I'd be interested to see experimental evidence that shows highwater marking has a significant performance impact for real world workloads.

For normal environments /HIGHWATER should be sufficient to prevent block scavenging, without measurable performance impact.

Re: Disk Wipe Free Space for VMS?

No, I would never argue that wiping free space after the fact is secure. However, sometimes we have to live within constraints imposed by others at our company even after we've fought the good fight.

In the example above would it be better to at least lock the doors at 9pm or just give up and leave them unlocked all the time? As I mentioned, I am interested in simply shortening the time window of opportunity where someone could scavenge the disk.

Re: Disk Wipe Free Space for VMS?

There are alternative methods that can be used that will further shrink the "window of opportunity" for accessing released file areas that involve some programming. I'd rather not outline the procedures in a public forum such as this. Shoot me an Email for more details.