Re: Description of the Journaling topology
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.
討論串 (同標題文章)
完整討論串 (本文為第 39 之 42 篇)：