Scott Lovenberg wrote:
Jörn Engel wrote:Thanks for the idea. Based on this idea, I will start looking at the implementation of isofs, and how is it made to be readonly.......my ultimate aim is to make the filesystem readonly upon after being written, and the file closed. Not sure if it can be done, but I envisaged a lot of audit journalling are of these nature. Of course, it is always possible to "dd" the filesystem to modify the content, but then if given design into its protection mechanism (like incremental checksum - current checksum based on previous checksum, generated and stored together with the file, upon after every writing of data) we can always protect its integrity. Aim is to set it to readonly......anyone can read....but not modifiable. As a start I will try out patching ext2, hoping that it is much simpler than ext3/ext4.
Upon changes to its content (via dd) it will invalidate the immediate future incremental checksum. Similarly, if u patch the current checksum (which depends on a hash function of previous data, and previous checksum), it will not be valid, as the current checksum is also dependent on the history of previous checksum. So everytime u change the content via dd, u will need to modify the next checksum, which is calculated based on this data, and the current checksum, which again provide the seed for the next checksum etc. U will have to modify a lot of data, unless u are near the tip of the latest modification. The smaller the chunk of data per checksum, the more difficult to keep up with the rate of modification. Tradeoff is more work for CPU.
The userspace tool part will then always validate the checksum with the data being read, if modified, checksum will not be valid. Since it is a hash function, given the modified data, and the previous checksum, it is not possible calculate the current checksum.
Of course, if the intruder is root, then it is as good as not having all these complex calculations, so our assumption is that the machine is not compromised yet.
Then of course the "chattr" can be used as well - if it is not compromised. True, but the possibility that it can be modified infinitely via chattr also exists - which is what write-once-read-many is against - to provide the assurance that it has not been overwritten the second time (possible technically, but very very difficult).
An equivalent requirements of such a filesystem will be: a filesystem such that upon every changes made, a log of dates of changes are made. Overhead for these feature is high, so a lightweighted version will be the date/history only it is first written.
On an existing ext2 filesystem, once the '"worm" kernel module is loaded, the feature immediately take effect - content becomes read-only but not modifiable, but modifiable for new contents. And old contents may or may not have a checksum to protect it, but if the checksum exists, it will come from the last time "worm" was running and generating checksum.
So u have the best of both world - ext2/3/4 with/without worm. If worm-enabled, it may also be configured at the directory level - some directory can be solely dedicated for worm-journalling.
What do u guys think - any conceptual errors?