Re: Making a time structure associated with the directory structure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux