Kaustubh Ghosh wrote: > Thanks for all the responses.But it wasn't exactly what I wanted.My fault at > expressing myself, I admit.What I wanted is to enhance the ext2 file system > with some modules which uses encryption to store time stamps of the access > and modifications of files.The encrypted data is to be accessed by > specialized passwords and the data can certainly not be deleted.A user who > will be using the file system will be bound by the system to store time > stamps,be he root or not.The data will be accessible only from root account > through the specialized password given at install time or by many of the > specialized secure password protocols(challenge handshake,etc etc).The main > problem in other cases is that the users with laptops must have root access > to make important changes on his own, but will be bound to format whatever > things(laptops ,desktops) they like to use to this file system.The O/S is > most likely to be some version of RedHat Linux.Can anyone please give me some > suggestions?Any help is appreciated.Thanks in advance for any consideration. > - Kaustubh Ghosh This is basically WAY more trouble than its worth. Ultimately, you can't trust client computers. This is a basic principle of security. They're under the complete control of the users: they've got physical access, and they've got the root password. They can change the local time on the computer: they can try booting DOS, they can try getting into the BIOS, they can try doing something with ntpdate and a crooked timeserver. So you're going to need some way to make sure that the data you store this way is valid. All the fancy security in the world can't make dud data valid. I don't believe this is practical. Oh sure, you can insist that you lock down BIOSes. You can password protect them: you can prevent them booting from any other drive than the first hard drive. So the BIOS will reliably get you into GRUB. But if the clients have root access to the boot partition, they can put another kernel in there, and set grub.conf to boot that with a USB stick as the root partition. They can also put another boot-loader there: you're going to need to patch the kernel to prevent it writing to the boot sector. And you'd have to hard-code a version of GRUB (or lilo) that would only boot certain kernels. Ideally, you'd have a version that would only boot kernels cryptographically signed by a particular private key: this is quite possible, but would require significant custom programming, as far as I am aware. Then you'd have to modify your kernel to stop anyone from setting the time in Linux. That means keeping another custom patch up-to-date. (And you are going to need some way to reset a client with the wrong time. Again, you could rely on adding cryptography to the kernel, so it would only set the time based on a message signed with a private key. Or you could rely on the clients coming to you with the PC, and letting you use your password to get into the BIOS). So we've got a custom boot-loader, and a custom kernel, and a PC that can only be used with these. We've got valid data. Now, how do we store it? Well, you think you want to hook ext2. That means custom kernels anyway. Practically (and I'm not a kernel programmer), I'm not sure you want to do it there. You want to do two things: you want to intercept a file being written, which might as well be done at the VFS (virtual file system) layer, and you want to store that data somewhere that root cannot change or delete. And I see no reason that can't be done at the VFS layer, either. I suspect that it would be easiest simply to store this data as a file: it's data, after all, and you don't know how big the data is going to grow (assuming that you want to store all changes). You'd "just" have to change the VFS to stop certain accesses to this file. You're already changing the kernel, so why not? Depending on what you want, you might let everyone *read* this file, or merely those with (again) a (different) secure key. Theoretically, you're going to need to make sure that a determined attacker with root access can't change kernel memory to bypass your restrictions. I doubt that's likely to happen, but you should remember the possibility. You'd at least have to restrict the kernel to modules you sign (or disable modules in your kernels), and disable write access to /dev/kmem. I'm sure there are other ways in. You will undoubtedly have to hire a kernel programmer to do this: he or she should be able to make all these objections and more, and should be able to implement a scheme like the one we've thrashed out (or a better one): if he or she can't, then they aren't worth your money. Note that open-source licenses makes this *more* practical, not less: you would be in no better state with a proprietary OS, but you'd also have to acquire rights to see the kernel's source code, modify it, and commercially use the modified kernel. You should also see http://www.catb.org/~esr/writings/quake-cheats.html for Eric Raymond's take on a fairly similar security situation: can a central Quake server trust open-source Quake clients. Effectively, what you want is a Trusted PC: one with a BIOS that will only load signed boot loaders, a bootloader that will only load signed kernels, and you to do the signing. For this reason, many people will not want to help you. Theoretically? Yes, it's *possible*. Practically? No way. James. -- E-mail address: james | "Luck is my middle name," said Rincewind, @westexe.demon.co.uk | indistinctly. "Mind you, my first name is Bad." | -- Terry Pratchett, Interesting Times
