Messages in this thread | | | From | bofh@snoopy ... | Date | Sat, 28 Dec 96 15:28:28 +1000 | Subject | Re: 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
| |