lkml.org 
[lkml]   [1996]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: signing a filesystem

I have been thinking about this issue for some time. I am in the process of
designing a new file system, but have left out features such as you describe
because I can't determine a way of doing them properly (and no-one else has
volunteered to design and write such features). My opinion is that poor
security is worse than no security... However if you could design a workable
security mechanism for file systems and supply some code then I'd be very happy
to include it in my file system (NB I'm not in the US, so anything that can't
be legally exported from the US is of no interest to me)!

>I've been wondering about the following scheme for making a filesystem
>tamper-resistant. Would it be possible to digitally sign each inode?

>My thoughts on this are currently at an early stage, but here they are for
>your comments:

>Files on a filesystem contain some integer number of blocks. I can, for
>example, compute the md5 checksum of each block. For all the blocks in a file
>(as referenced by its inode), I can compute the individual md5 checksums and
>then combine the result with XOR to obtain a unique footprint for the file.

>Such a footprint would be stored in the file's inode. Any change to the file
>without ammending the recorded footprint could be verified by some filesystem
>admin-tool. [This could be done at boot time on extra sensitive filesystems,
>or periodically when the system is off-line if this is not practical.]

>Because the recorded footprint is the result of XORing the individual block
>checksums that combine to make the whole file, it is relatively simple to
>update the footprint when a single block is modified.

> new-footprint = old-footprint ^ md5(old-block) ^ md5(new-block)

This part is all good.

>At this point, it is simple to "forge" a modified footprint since md5 is a
>publically available algorithm, so the above scheme would be good only against
>accidental filesystem corruption.

>To guard against a vandal booting from a rogue-kernel, and modifying a
>filesystem before rebooting linux again, an extra element of security would be
>to compute the md5 checksum of each block appended with some "secret" key
>given to the kernel at boot time:

> lilo: linux fs-key=BigSecret

The problem is keeping the lilo config secret. The only way to do this is
to somehow give a secret key to the kernel. The problem is determining an
appropriate way of doing it. The only method I've come up with is for the
sys-admin to type in a password at boot time. This will work, but will require
that the administrator be present when the machine is booting. I know that
this will work well for many systems (single user workstations), but I doubt
that it'll work for the systems that actually require this level of security.
However if you think that the above is worth doing then I encourage you to
write the code and contribute it. You can either contribute it to the Ext2
project (I don't know whether it fits in with the plans of the people who
maintain that FS) now, contribute it to my project later (currently we haven't
started coding so it's too early for such things), or do both.


Russell Coker

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.086 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site