DragonFly BSD
DragonFly kernel List (threaded) for 2005-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Description of the Journaling topology


From: "Rob D." <162144@xxxxxxxxx>
Date: Sat, 01 Jan 2005 02:05:20 -0600

Matthew Dillon wrote:
:What if the journal is for an encrypted disk? It would probably be :desirable for the journal data to be encrypted in that case, especially :if the stream was a socket to an offsite machine. It might be necessary :to store key data in the journal; depending on just how the encryption :is done.
[snip impertinent paragraph]

Well, that's a pretty good attempt but I would counter with: "But wouldn't it be easier just to have an application take the journaling stream and encrypt it?". Remember, the journal is just a descriptor, it can point to anything, including a user program.

I hadn't considered that. The secondary spool would need to be on an encrypted fs, too.


After some thought, it seems like it would be easiest to encrypt the outgoing journal entries/spool. Unless I'm misunderstanding something, the journaling mechanism has to be able to read the journal entries in order to process them. I had been considering cases where the security of the filesystem were extended through the journaling system, which might have advantages from a key management point of view or might be necessary to maintain the security model of the filesystem. In GBDE, for example, destroying the master key for the device destroys all information about the filesystem. Encrypting the stream output means that some log entries would survive the destruction.

Of course, using GBDE as an example isn't especially helpful, because GBDE is an encrypted device, not an encrypted fs. The only example I found of an actual filesystem that employs encryption is Reiser4, which has an encryption plugin. Other methods I know of use an encrypted device.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]