Description of the Journaling topology

[Rob D.]

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.