[111] in The Cryptographic File System users list
Re: Link between NFS and CFS
daemon@ATHENA.MIT.EDU (Matt Blaze)
Mon Nov 30 15:58:28 1998
From owner-cfs-users@research.att.com Mon Nov 30 20:58:27 1998
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 13226 invoked from network); 30 Nov 1998 20:58:27 -0000
Received: from unknown (HELO rumor.research.att.com) (192.20.225.9)
by bloom-picayune.mit.edu with SMTP; 30 Nov 1998 20:58:27 -0000
Received: from research.att.com ([135.207.30.100]) by rumor; Mon Nov 30 15:51:27 EST 1998
Received: from amontillado.research.att.com ([135.207.24.32]) by research; Mon Nov 30 15:56:25 EST 1998
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id PAA16147;
Mon, 30 Nov 1998 15:56:20 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id PAA13000 for cfs-users-list; Mon, 30 Nov 1998 15:50:11 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id PAA12995 for <cfs-users@nsa.research.att.com>; Mon, 30 Nov 1998 15:50:10 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id PAA16057;
Mon, 30 Nov 1998 15:49:53 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id PAA12988; Mon, 30 Nov 1998 15:50:08 -0500 (EST)
Message-Id: <199811302050.PAA12988@nsa.research.att.com>
To: Munish Mehta <mumehta@mtu.edu>
cc: cfs-users@research.att.com
Subject: Re: Link between NFS and CFS
In-reply-to: Your message of "Mon, 30 Nov 1998 14:42:56 EST."
<Pine.SO4.4.05.9811301432170.24062-100000@cs.mtu.edu>
Date: Mon, 30 Nov 1998 15:50:07 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
>
>Hi,
>
>I have a Linux server with CFS and NFS daemons running on it.
>I create a directory using cmkdir and works on it a bit.
>
>Now, I want to export this directory(or partition) to other client linux
>machines using NFS mount. Client machines are also running CFS and NFS
>daemons. So client machines can access this directory and "cattach" the
>directory to read/write the contents.
>
>The problem is that "root" or "superuser" on client machines cannot be
>trusted. Ofcourse with encryption, they cannot read any thing in the
>secure directory (the directory in mention), but they can delete it as
>NFS mount has to be read/write. Is there anyway to deny permission
>through CFS or NFS, so that even root is not able to delete the directory
>encrypted using CFS until and unless it is able to do a "cattach" on it..
>(that is after knowing the key).
>
>Please let me know if you have any suggestions or ideas or if you have
>experienced similar problem. Any idea/suggestions about CFS/NFS settings
>related to this would be very helpful.
>
>Thanks in advance,
>Munish Mehta
>
Short answer: No.
There is no effective security against a malicious root on a client machine
that has the key. While the default behavior of the cfsd client software
does deny access to the cleartext to users other than the uid that did the
cattach, including root, a malicious superuser could replace the cfsd
with one that doesn't do that. Or look at the memory image of the cfsd
and extract the key from that. Or replace cattach with a trojan horse
version that records a copy of the key. Or "su" as root to the user
who did the cattach and then look around in /crypt. Or any number of
attacks along the same lines.
CFS's security depnds on the security of the client machine. This is
a fundamental property of encryption generally: the encryption is
only secure to the extent that the key is kept secure, and keys held in
computer memory under unix cannot be made secure from root. Any
encryption doene in software will have this property.
That said, because the default behavior of cfs does deny access to root,
that may provide some protection against certain classes of attacks
(mostly accidental). For example, a badly-configured automatic backup
script that tries to back up /crypt will fail, as will a few "automatic"
attacks from various system cracking toolkits. But you simply cannot
depend on cfs or any software encryption to protect against a
determined and malicious root on the client machine.
Sorry.
-matt
