Encrypted File Systems
In one episode of “Miami Vice” Crockett and Tubbs have managed to gain access to a drug runner's computer, only to be stymied by its insistence on a password before presenting incriminating evidence. Not to worry—after only three unsuccessful guesses, the helpful computer offered to reveal the secret password to our heroes. It's easy to laugh at this plot development, but many otherwise intelligent people continue to do equally dumb things.
Consider the law office where legal papers are always kept in locked cabinets behind locked doors. Every computer on the LAN also has access to the “password-protected” word processing documents, but the encryption can be broken in seconds with readily available software. The name of this program, and the files it can crack, are in the sci.crypt FAQ. These files could be retrieved by a hostile agent “working” for a cleaning contractor.
Or consider the company with sales offices spread nationwide. Highly sensitive pricing and contact information is distributed on CD-ROM discs, which are discarded as soon as each new disc arrives. Alternately, a salesman may have his laptop stolen while on the road. (See Practical UNIX and Internet Security, Garfinkel and Spafford, O'Reilly and Associates, 1996.)
Or consider the individual computer owner who leaves his system in a shop for free installation of an upgrade. One of the employees quietly copies a few files, and by the time the victim learns of the extent of the identity theft it's too late—he's already recommended the same shop to several of his friends for the unusually good service.
For every complex problem there is an answer that is clear, simple and wrong. --H. L. Mencken
The simple solution to these problems is file encryption. But this solution is flawed for several reasons:
Encryption within programs is generally weak to the point of uselessness due to U.S. export regulations.
Encryption outside programs requires explicit actions to decrypt and to re-encrypt. This problem may be manageable if a file needs to be accessed only by a single user, but it's a much more difficult problem if several people need to share access.
Explicit encryption requires sharing the password, and the more people who have the password, the more likely it becomes that someone will jot it down in an obvious location.
Explicit encryption may enable a disgruntled employee to encrypt the files with a different password.
Decrypting a file increases the risk that unencrypted versions will remain on the disk or on backup media.
Our solution is to encrypt the entire file system. User programs see a regular file system—perhaps even a file system that natively supports encryption. An attacker who can only see the physical disk sees garble.
This approach is not perfect. Most notably, some implementations could leave decrypted data visible in the disk cache. That is a minor problem with the cache in core (if an attacker has compromised root, you have more serious problems), but a major problem if these pages get written to swap.
On the other hand, the kernel ensures that disk sectors are decrypted during reads and re-encrypted during writes. The impact on users is minimal. In one practical scenario, a “responsible individual” will mount the encrypted file system in the morning. (This requires the encryption key.) In the evening, the last person to leave could unmount the file system, or it could be automatically unmounted by a cron job.
Better the devil we know... --Anonymous
We've agreed on the desirability of encrypting file system. But which encryption algorithm should we use? The wrong choice will leave us with a false sense of security.
Writing our own encryption routines is one possibility. The downside is encryption algorithms are notoriously difficult to properly design and implement. The problem is that the designer does not know what others will find difficult. He only knows what he finds difficult. Mathematics is littered with the bodies of “difficult” problems which became trivial after one person had a flash of insight.
As a practical matter, we should limit our search to well-known encryption algorithms. This has the additional benefit of allowing us to share encrypted file systems with others with a minimum amount of hassle.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Keeping track of IP address
59 min 46 sec ago
- Roll your own dynamic dns
6 hours 13 min ago
- Please correct the URL for Salt Stack's web site
9 hours 24 min ago
- Android is Linux -- why no better inter-operation
11 hours 39 min ago
- Connecting Android device to desktop Linux via USB
12 hours 8 min ago
- Find new cell phone and tablet pc
13 hours 6 min ago
14 hours 35 min ago
- Automatically updating Guest Additions
15 hours 44 min ago
- I like your topic on android
16 hours 30 min ago
- This is the easiest tutorial
23 hours 6 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?