On 13-Sep-2016 12:20 -0600, Mike Cunningham wrote:
I know that in a windows environment when you delete a file you
really just delete the directory entry that tells you the name of the
file and where it is on disk, and that the data in the file still
exists at that point and can be retrieved. Does the IFS on IBM i work
the same way, and if so, is there a way to actually overwrite the
data space associated with a file so it is unreadable?
I have a recollection of seeing a "What's New" describing a "secure
delete" that was perhaps for the database; but if I had seen, I could
not find anything in searches. Perhaps an issue with one of my
imagination, a faulty memory, or a diminished google-fu ;-)
What I did find:
Integrated File System Secure Delete
TechNote: Reference #: N1011726 Historical Number 589273732
[
http://www.ibm.com/support/docview.wss?uid=nas8N1011726]
"…
This document provides information on how to zero out the storage used
by an Integrated File System (IFS) file and how to destroy an IFS file.
RMVLNK will remove a link to a file; however, there can be multiple
links to a file. An IFS file object is destroyed after the last
reference to it is released. Once an object is destroyed, there is no
further way for any user to ever look at that storage again, even in
SST. However, that does not mean the storage is ever overwritten on the
actual disk. Therefore, if someone removed the hard drive with the
"destroyed" object on it and had some way of reading the raw data off
the disk that did not involve SLIC storage management, they might be
able to retrieve the contents of the destroyed file.
There are two APIs that will write a specified number of zeroes to an
open file: fclear() and fclear64(). To ensure those zeroes actually get
written to disk, you must use fsync().
Then how do you make sure all links are removed? …
…"
Same question for DB2.
An analogous question would seem necessarily to be about Delete File
(DLTF) or DROP TABLE and\or Remove Member (RMVM) or DROP PARTITION.
Similar to deleting a Stream File (STMF), deleting a database file
likely leaves the data [segments] forensically available, though over
time and normal operations, the less likely there will be any visibility
to the majority of that data.
I know when a record is deleted it is not really deleted
Of course, a question about DELETE of a row is still just as valid,
for how one might effect a secure-delete of that data. The same concept
of initializing\zeroing the data that might be used for a STMF, could be
performed for an RRN; although in anything other than a *BEFORE *DELETE
trigger, would probably not be very straightforward to accomplish.
FWiW, the row is "deleted" by marking the Deleted Entry Byte [DEnt
byte]; that effect is of course, not a so-called /secure delete/,
because the fixed-length and variable-length record data [i.e. the field
data] is not zeroed or initialized, and all of the original fixed-length
data remains in the DataSpace. The navigation to the variable data
portion is lost to that row [despite the ability to position to that RRN
remains], and if\when a variable data portion of the record [in the
varlen SID] will ever get overwritten, approaches unknowable.
To be clear, after a [committed] deletion of a row, there is no I\O
_method_ provided by the OS&LIC DB, by which that row data can ever be
obtained. However, a _copy_ of the row image as obtained from a journal
could be put in place of that row, using either of the Remove Journaled
Changes (RMVJRNCHG) or Apply Journaled Changes (APYJRNCHG). And a row
image [with the DEnt byte active] can be found in a _copy_ of the data,
as obtained from a backup [e.g. Save Object (SAVOBJ) or Save Library
(SAVLIB)].
because there are utilities that can undelete a record.
Technically, and as a distinction that IMO matters, and thus worth
restating, there is no un-delete method, so there exists no utility that
can actually undelete a specific record in a database file.
Such utilities make\obtain and then use an _alternate copy_ of the
data; and with that copy, there is the ability to rewrite\reinsert the
specific Relative Record Number (RRN) to have the same values as had
existed there before, such that all of that field data would need to be
*rewritten* for the record, but as obtained elsewhere. Thus the same
effect of "undelete" could be achieved with the same write method, but
only by having obtained the data from anywhere else; e.g. as obtained
from an online or offline journal image [or even from the original
entity the row represents], instead of merely the copy of the row-data
having been obtained from an online save file.
And that a RGZPFM gets rid of deleted records, but even doing
that, does it make all the deleted records unreadable on disk?
The Reorganize Physical File Member (RGZPFM) run with or without the
ability to Allow Cancel (ALWCANCEL), could leave data forensically
available, but is similarly unlikely to be obtained\visible over time,
as with the use of DLTF or RMVM.
Less conspicuously, of a possible related concern, are the similarly
complex topics involving the internal implementations of other features
like Edit File (EDTF), Start Source Edit Utility (STRSEU), and ALTER
TABLE [or the similar Change Physical File (CHGPF) with Source File
(SRCFILE) specified]. These also offer chances at leaving intact,
various /pages/ [note: single level storage] or Data Spaces with
so-called sensitive data that could be forensically retrieved; though
again, with normal operations on most systems, the chances of that data
remaining should approach zero as time\work progresses. Whether
remnants remain visible is highly dependent upon the implementation of
whatever acts on the file(s) and data.
This question is in relation to a PCI-DSS Requirement 3 that states
"Processes for secure deletion of data when no longer needed" and
applies to even data that is encrypted. Instead of just deleting
records from any database that has card holder data in it (encrypted)
should the first step being updating the card data in the record to
blanks first so the blanks are written to disk and then deleting the
record? That way even if someone was able to access a deleted record
the card data would not be there
The secure-delete of encrypted row-data seems to me to be a bit
extreme. Notably, if a row is "no longer needed" [and thus can be and
is being deleted], and the encrypted row image still exists in backups
and journals [and possibly in latent pages in memory or on other disk
subsystems], surely all of those copies of the encrypted row image are
not also going to get purged somehow? For that requirement to be
accomplished as alluded, when viewed from the perspective of row-level
data, would seem to suggest that a new backup would need to be taken
after each secure-delete of a row, and then the prior backup(s) be
destroyed -- the entity data is no longer needed, so that must be
cleared from everywhere else too.?
Perhaps my difficulty with the requirement is not the definition of
"no longer needed", but the definition of "data". Again I wonder if
perhaps the topic needs to be viewed with regard to the effects of
deleting a stream file, and thus restricted to the analogous effect for
deleting a database file; i.e. how to effect the secure-delete at the
effective object-level, thus perhaps ignoring, or at least redefining
"needed" or "data", with regard to the actual row-level data.
Just consider where other /copies/ of that encrypted row data might
reside:
Already noted are backups and active journal receivers; thus also
backups of the journal receivers in which [possibly both before and]
after images are stored. There are the active pages for for the
journaling feature and buffers in programs that might have done an I\O
into which the image was copied. That row data could even be in system
logs\dumps as part of LIC\OS error logging. Data in STMF have similar
potential concerns.
One might expect that the Clear Physical File Member (CLRPFM) which
purports to "removes all the data (including deleted records)" would be
sufficient; that perhaps as a precursor to DLTF FILE(The_File), the
CLRPFM FILE(The_File) MBR(*ALL) might be sufficient to render all the
data wiped\zeroed, so effectively achieving a secure delete. Yet,
despite a specific record being zeroed or accessibility is otherwise
/removed/ for reading that row, from prior comments we know the
historical images may persist in the journals and backups. And due to
implementation, the effect of the clear being merely a DataSpace reset,
which need not [and likely does not] even rewrite the data segment
before reuse.
midrange.com
