Section 15.4. Moving Forward: A Plan for Clean Computing


15.4. Moving Forward: A Plan for Clean Computing

Although the need for proper sanitization of magnetic recording media has long been recognized as a serious issue for computer security practitioners, the problem has traditionally been addressed through the use of add-on software or physical destruction of the media itself. Only recently has the question of sanitization been addressed by computer operating system vendors themselves, and in the cases that we have considered, both Microsoft and Apple have addressed it poorly.

Some researchers have told me that operating system developers did not deploy sanitizing file deletion in the 1970s and 1980s so that accidentally deleted files could be recovered using special tools. I have looked and have found no evidence to support this claim. Indeed, had recoverability of accidentally deleted data been a goal, companies like Microsoft and Apple would have distributed such tools themselveseither as part of their operating system offerings or as aftermarket additions. (DOS 5.0 included an UNFORMAT command-line utility that could, in some cases, recover a volume that had been formatted inadvertently. But this looks like an after-the-fact attempt to make use of a DOS 2.0 idiosyncrasy, rather than an intentional design attribute that was put into DOS 2.0 and realized only when DOS 5.0 finally shipped.)

Instead, it seems that the lack of a sanitizing delete-file is a historical accident. The first multiuser computer systems did not need a sanitizing delete because of the ways in which they were operated. The developers of the Compatible Time Sharing System (CTSS) at MIT in the 1960s did not consider the problem of sanitizing disk blocks after deleting files because the computer system frequently ran with disks that were full or nearly full: blocks that were freed were quickly overwritten with new data.[19] The CTSS disk drives were rented from IBM and, thus, were never offered on the secondary market. Indeed, the real data security problem was not that data on a disk returned for service might be sent accidentally to another IBM customerthe real problem was trying to keep data on the disks that were having head crashes every few days! In any event, while there was a general belief that CTSS should prevent one user from crashing a program being run by another user, overall the system did not have strong internal disclosure controls: the developers did not believe that CTSS was secure enough to store sensitive information.

[19] Jerome Saltzer, "Re: sanitizing delete file," personal communication (Dec. 2004).

Internal security between users was a design goal of the Multics operating system. But Multics did not have files as we know them today. Instead, it had named memory segments that could be created, placed in a hierarchical filesystem, and extended as needed. When a process created a new segment, the disk blocks for that segment were cleared (that is, overwritten with NULs) when the segment was allocated. Thus, there was no need to overwrite the blocks when the segment was erased. Clearing on allocation doesn't solve the data remanence problem, but that problem applies to both deleted and undeleted information. If a Multics disk was decommissioned, the system's operators would have understood the importance of erasing all of the information from the device.

Unix was developed in a research environment in which security was not a priority: when Unix first transitioned into the commercial world, it ran on large systems that were run by trained system operators who, presumably, were aware of the sanitization issue. Although Unix provided no tools for sanitizing disks, the dd command did an excellent job, as previously noted.

In the world of PC operating systems, an overwriting delete would have caused significant performance degradation (similar to Mac OS 10.3's Secure File Delete) on any operating system that did not have asynchronous access to the filesystem and disk device. Windows did not have such capabilities until 32-bit clean disk drivers were available under Windows 95 and NT. Apple did not have such capabilities until it migrated to Mac OS X.

Today, matters have changed. Unlike the systems of the 1960s and 1970s, most of today's desktop computers spend most of their time idle. Likewise, manyperhaps mostof today's desktop computers are not managed by professional IT staffs that are aware of the sanitization problem. What is needed, then, is some straightforward way to add a sanitizing delete-file function.

Although a simple approach would be to resurrect Bauer and Priyantha's Linux implementation, I believe that this is only half of the story. Although it's good for overwriting to happen asynchronously with other activities, bringing truth to the phrase "rm is forever" is not a particularly user-friendly way to move forward. Many usability experts have noted that humans make frequent mistakes; simply adding a warning box saying something to the effect that "rm deletes all of your files" not a particularly strong barrier to improper use.

An alternative construct would be to remove the Empty Trash and Secure Empty Trash commands in the Macintosh user interface and replace them with a new command: Shred Trash. Executing this command would perform much the same function as the Secure Empty Trash, except that the overwriting would be performed asynchronously. There are two advantages to this approach:

  • The term Shredder is superior to Secure Empty Trash because most people know what a paper shredder does; most people do not know what it means to securely empty trash. Thus, less initial user education would be required.

  • Because the shredding would be performed asynchronously, there would be no perceived penalty for using the feature.

The second change required is to allow the user to create rules that specify conditions under which the contents of the Trash directory are shredded automatically. Typical rules might include:

  • Shred any file that has been in the Trash more than 30 days.

  • Shred all files in the Trash when the user clicks the "Shred all files now" button.

  • Shred all files in the trash at 7:00 a.m. every day.

  • If a file is selected and the user chooses the Shred command from the File menu:

    If the file is not in the Trash directory, move the file to the Trash directory and schedule for it to be shredded in 5 minutes.
    If the file is in the Trash directory, shred it immediately.

These rules give users a chance to change their minds (as recommended by Cooper[20]), but nevertheless provide for the possibility of immediate shredding, should such an action be necessary. Figure 15-3 shows a hypothetical user interface to implement this rule set.

[20] Alan Cooper, The Inmates are Running The Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (Sams Publishing: 1999).

The third change required is to change the semantics of the POSIX unlink( ) system call, so that calling unlink( ) on a file has the effect of moving that file to the user's Trash, instead of actually releasing the blocks. Such a move, while drastic, would overcome the problems

Figure 15-3. Hypothetical design of a Shredder rules interface (Icon by Danziger, used with permission.)


that arise when a file is deleted by an application other than the Finder. This approach would also handle the problem discussed earlier with the Save As command.

A naïve implementation of this third recommendation would degrade system performance dramatically. This is because many small files are constantly being created and deleted on a typical computer system. But temporary files still need to be sanitized. Moving them to a shredderperhaps with a tag that marks them for "immediate" shreddingassures that this will happen. The files can then be shredded in the background when the computer is not otherwise in use. For servers and computers that are constantly in use, the computer's filesystem can simply use disk blocks in the shredder and marked for shredding as a convenient source of new blocks when they are needed for writing out new files. This would effectively sanitize the blocks in the same manner as blocks were sanitized on CTSS back in the 1960s.



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net