My New Favorite Toy
Okay, I have a new favorite toy. It's called Engarde Secure Linux. This secured Linux distribution goes beyond the normal SELinux capabilities with a restricted root and true Mandatory Access Controls (remember your CISSP training?) Why do I care?
A few years ago I was tasked with building a secure file transfer system that was built on existing tools which a "partner" company could acquire and tie into, and it had to be easily automated. Based on the requirements (and taking a guess at what regulatory requirements were going to pass legislation) I built a system running on a Solaris box that SCPed data to- and from- partner companies. This data was PGP encrypted (if we were sending it) to the customer's PGP key, or it was received from the partner and automatically decrypted via PGP command line.
This posed a few problems. The enterprise version of PGP command line (from Network Associates at that time) required that the passphrase be read from a text file, stored in an environment variable, or be "" (blank, in other words). None of these are particularly desirable for my new system, but I didn't have much to work with for the old one.
This is a problem with automated systems like this. Even though we can do some good public/private key work here, it still comes down to a passphrase to unlock the data, and that passphrase must be available to the system. There are tools to "obfuscate" passwords in text files, but they suck, and are easily reverse-engineered.
The best answer we had at the time was to try our best to secure the device. We put it in a DMZ, gave it local protection (IPFW, Tripwire, and logging).
I'm thinking that with something like Engarde I can provide better controls. While I will still have either a passphraseless key or a passphrase stored in a text file, I can better limit access to these because of how Engarde works. I am no longer so concerned about a root exploit allowing a malicious user to gain access, because root itself will not have access to these files. Only the specific system account which executes the decryption command will have access to it. This isn't perfect, but it's a huge step forward.
In fact, it may be worth the risk of adding a second layer of protection. In case someone physically accesses the system, we can go ahead and encrypt the filesystem. Encrypting swap would be a good idea, as well.
On top of that, we can choose to NOT store the passphrase in a file, but rather require the passphrase to be entered one time only at system startup. Hopefully, this means that the passphrase will only be accessible via the context of the decryption account (and it will be lost at shutdown, since it's in non-swappable RAM, I hope). Depending on the availability requirements of the system, this may be practical. For my application, this will probably be just fine, so I'll probably require someone to manually enter the passphrase at system startup, and just make sure I have a good "uptime" monitor.
You'll notice that I have few good links in this post. There's still a bit of research to do (I'm checking out the source code for PGP command-line right now, or I may go with GnuPG) and when I've done it, I'll publish the whole thing here. I'll probably make it available on the Engarde site, as well.
Anyway, I've got another idea I'm working on, as well. This one is an anti-spam idea. I worked up an idea a few years ago, and my boss told me "it's a bad idea". Six months later, IBM announced a project leveraging the exact same idea I had had. Just a few days ago, I posited a new idea to a new boss, with a similarly cool reception.
THIS time, I'm gonna build it before IBM does. You'll read about it here, as well.
TTFN. -Brian
A few years ago I was tasked with building a secure file transfer system that was built on existing tools which a "partner" company could acquire and tie into, and it had to be easily automated. Based on the requirements (and taking a guess at what regulatory requirements were going to pass legislation) I built a system running on a Solaris box that SCPed data to- and from- partner companies. This data was PGP encrypted (if we were sending it) to the customer's PGP key, or it was received from the partner and automatically decrypted via PGP command line.
This posed a few problems. The enterprise version of PGP command line (from Network Associates at that time) required that the passphrase be read from a text file, stored in an environment variable, or be "" (blank, in other words). None of these are particularly desirable for my new system, but I didn't have much to work with for the old one.
This is a problem with automated systems like this. Even though we can do some good public/private key work here, it still comes down to a passphrase to unlock the data, and that passphrase must be available to the system. There are tools to "obfuscate" passwords in text files, but they suck, and are easily reverse-engineered.
The best answer we had at the time was to try our best to secure the device. We put it in a DMZ, gave it local protection (IPFW, Tripwire, and logging).
I'm thinking that with something like Engarde I can provide better controls. While I will still have either a passphraseless key or a passphrase stored in a text file, I can better limit access to these because of how Engarde works. I am no longer so concerned about a root exploit allowing a malicious user to gain access, because root itself will not have access to these files. Only the specific system account which executes the decryption command will have access to it. This isn't perfect, but it's a huge step forward.
In fact, it may be worth the risk of adding a second layer of protection. In case someone physically accesses the system, we can go ahead and encrypt the filesystem. Encrypting swap would be a good idea, as well.
On top of that, we can choose to NOT store the passphrase in a file, but rather require the passphrase to be entered one time only at system startup. Hopefully, this means that the passphrase will only be accessible via the context of the decryption account (and it will be lost at shutdown, since it's in non-swappable RAM, I hope). Depending on the availability requirements of the system, this may be practical. For my application, this will probably be just fine, so I'll probably require someone to manually enter the passphrase at system startup, and just make sure I have a good "uptime" monitor.
You'll notice that I have few good links in this post. There's still a bit of research to do (I'm checking out the source code for PGP command-line right now, or I may go with GnuPG) and when I've done it, I'll publish the whole thing here. I'll probably make it available on the Engarde site, as well.
Anyway, I've got another idea I'm working on, as well. This one is an anti-spam idea. I worked up an idea a few years ago, and my boss told me "it's a bad idea". Six months later, IBM announced a project leveraging the exact same idea I had had. Just a few days ago, I posited a new idea to a new boss, with a similarly cool reception.
THIS time, I'm gonna build it before IBM does. You'll read about it here, as well.
TTFN. -Brian
Comments