[lkml]   [1997]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: signing a filesystem
Date wrote:
> More generally, I have to ask the question why are we trying to do
> cryptography at the filesystem level at all? What is your threat model?

Cryptography (for confidentiality) seems like a service better suited to a
user level process: agreed.

> Who are you trying to protect your data against? What sort of resources
> is your adversary going to have?

The original suggestion was to be able to "sign" the filesystem, the threat
model was one of the following:

user process finds a way to modify the filesystem independently of
the filesystem

attacker shuts down the machine and boots a rogue kernel (OS) that
modifies the filesystem (replaces 'su' etc..)

system crashes and administrator wishes to establish which files'
data was damaged

> It is not at all clear to me that the filesystem is really the right
> place to be doing this sort of protection. Since the integrity
> protection and signing is taking place in the kernel (and the
> cryptographic keys have to present in the kernel at all times while it
> is running), this scheme doesn't protect you against someone who has
> managed to get superuser access. It only protects you against someone

Currently, there is no form of protection against a superuser.. From our
discussions at USELINUX and the comments that Stephen Tweedie made, this is
likely to improve in the future.

> who has physical access to your disk while the kernel isn't running.
> However, is this a threat model which is most people will commonly see?

This is the sort of threat that a "public terminal" (universities/libraries
etc..) are subject to...


Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
[ For those that prefer FTP --- ]

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