encrypted root filesystem
thsutton at tasmaniac.net
Mon Feb 23 15:21:03 PST 2004
On Tue, 2004-02-24 at 09:43, Ian Molton wrote:
> On Mon, 23 Feb 2004 15:54:22 -0600
> Dagmar d'Surreal <dagmar.wants at nospam.com> wrote:
> > > > The Encrypted-Root-Filesystem-HOWTO doesn't encrypted the
> > > > partition table.
> > >
> > > encrypted filesystems are stupid.
> > No, they're not. You should be ashamed of yourself for posting such a
> > comment.
> I remain unconvinced. encrypting an entire filesystem gives you loads of
> known plaintext (and binaries, potentially).
> I havent seen a problem yet that isnt better solved by application level
> The *only* argument I have seen that holds any water is that at app
> level every app will need a certain degree of vetting. This is a much
> smaller risk if proper use of libraries is used.
So you need to have a version of each and every application that you
want to use that encrypts its data. That sounds like a lot of effort.
Why use a single encrypted filesystem that is always on when you can
have Mozilla encrypting its stuff, and vim encrypting edited files and
OO.o encrypting its files, ad infinitum.
The other benefit that an encypted fs/dev has over encrypted files is
the deniability. They can't even tell that the files exist. To drag out
a example that the security lecturer at my uni likes to use:
someone being able to see (defence in depth, don't just rely on physical
security, yadda yadda) that the file data/aids_tests/joe_bloggs exists
is a Very Bad Thing(TM). Admittedly, this example is not as extreme a
case as one would need to justify the fairly immense computational
expense of encrypting an entire fs.
Regarding the "it provides lots of known plain text" argument: if you
can tell me a way to determine which particular blocks in a given
filesystem, for which you have no hard-and-fast data, comprise any given
file (even any single random file), I will do anything within my power
to help the effort to have you cannonised (or whatever is appropriate
for your religion, of belief structure). You can see the meta data (its
encrypted) so you can't tell which blocks belong together. Even if you
could, you would only be able to guess at which particular 3 block file
is /bin/false, which is /bin/true, which is /bin/sync, which is
/bin/getopt, and which is /bin/echo. About all you will be able to KNOW
is that i.e. the superblock is here (or there if they use XFS :-) and it
probably has values like this in it; unless they told mkfs to do
something non-standard. Additionally, I don't think that anyone who
needed to run crypted fs' would be so foolish (if I may be so bold) as
to waste time and space encrypting non-sensitive information.
I'd like to see either the book or a hint include pointers on
stenographic filesystems as well, but that is just for the sake of
completeness (and coolness :-) really. There are very few scenarios when
I such extreme measures would need to be taken.
More information about the hlfs-dev