[203] in The Cryptographic File System users list
Re: using cfs with /home
daemon@ATHENA.MIT.EDU (Ravikant K.Rao)
Tue Oct 17 00:21:04 2000
From owner-cfs-users@crypto.com Tue Oct 17 04:21:03 2000
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.MIT.EDU
Received: (qmail 4694 invoked from network); 17 Oct 2000 04:21:01 -0000
Received: from mx.crypto.com (207.140.168.138)
by charon.mit.edu with SMTP; 17 Oct 2000 04:21:01 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id AAA01313
for cfs-users-list; Tue, 17 Oct 2000 00:14:10 -0400 (EDT)
X-Authentication-Warning: mx.crypto.com: majordomo set sender to owner-cfs-users@crypto.com using -f
Received: from nsa.research.att.com (H-135-207-24-155.research.att.com [135.207.24.155])
by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id AAA24851
for <cfs-users@crypto.com>; Tue, 17 Oct 2000 00:14:09 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id AAA07800 for <cfs-users@nsa.research.att.com>; Tue, 17 Oct 2000 00:14:07 -0400 (EDT)
Received: by mail-blue.research.att.com (Postfix)
id 934AB4CE31; Tue, 17 Oct 2000 00:14:08 -0400 (EDT)
Delivered-To: cfs-users@research.att.com
Received: from symonds.net (adsl-63-194-20-32.dsl.lsan03.pacbell.net [63.194.20.32])
by mail-blue.research.att.com (Postfix) with ESMTP id 884294CE46
for <cfs-users@research.att.com>; Tue, 17 Oct 2000 00:14:07 -0400 (EDT)
Received: from ravi by symonds.net with local (Exim 3.12 #1 (Debian))
id 13lO8c-0008Pj-00; Mon, 16 Oct 2000 21:14:06 -0700
Date: Mon, 16 Oct 2000 21:14:06 -0700
From: "Ravikant K.Rao" <ravi@symonds.net>
To: cfs-users@research.att.com
Cc: "Ravikant K.Rao" <ravi@symonds.net>
Subject: Re: using cfs with /home
Message-ID: <20001016211406.A32299@symonds.net>
References: <20001016061907.B23833@symonds.net> <200010161359.e9GDxkV25592@black-ice.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <200010161359.e9GDxkV25592@black-ice.cc.vt.edu>; from Valdis.Kletnieks@vt.edu on Mon, Oct 16, 2000 at 09:59:46AM -0400
Sender: owner-cfs-users@crypto.com
Precedence: bulk
Greetings,
Thanks for your replies, and here is what I have to say.
On Mon, Oct 16, 2000 at 09:59:46AM -0400, Valdis.Kletnieks@vt.edu wrote:
> > with CFS so that the /home directory is maintained encrypted and the
Whoops - I must have been sleeping when I typed that out - my
apologies - I had actually meant /home/$USER - But now that this question
got addressed - even this sounds like an interesting idea - putting /home
in a separate partition and leaving it encrypted at the system level if no
users are logged on, and decrypt only when one or more users logon at a
given time.
> 1) You have to get 'cattach' run to get the home directory in place. This can
> be interesting, as many shells will check for the existence of $HOME very
> early on, and give the infamous "No home directory - logging in with HOME=/"
> message.
True, like say bash. But if we were to have a /.profile, which
would do the cattaching and cd'ing into $HOME, it might solve the problem.
> 2) For a multi-user machine, you probably want to look at the interaction
Oh - My whole original idea of encrypting /home and /home/$USER
was for a multiuser setup, so that no one user can peek into another
user's setup - I guess I would want all my logs customiesed so it goes
into /home/log or somesuch and I would like CFS to be running on that
login - Better of course would be if it is available for *all* logins.
> between automounter, cfs, nfs, and the various file system caches (inodes,
> data blocks, directories, etc). You might want to think about the impact
> of somebody doing a 'make emacs' into a cfs filesystem (ouch ;)
Yikes ;)
> 3) You may want to consider whether your security issues require that
> everything in $HOME be encrypted. You're taking a pretty heavy hit for
> both performance and sysadmin issues, when quite likely only SOME of
> the data needs encrypting. If your security needs are THAT high, you
> need to be doing a complete system audit for a lot of really tough-to-fix
> issues. For instance, it is well known that CFS is not very secure at all
> against sniffer attacks on the loopback device....
Oh - like I said, I *would* infact want *everything* under $HOME
to be encrypted. Thanks for that - I didn't quite know that...
> 4) Passphrase management becomes an issue - since their entire $HOME is
> being protected with *one* passphrase, they need to pick a *really good*
Agreed.
> This last point is especially important when you consider that you're
> doing this to the users, not giving them an option to do it...
Yes.
Thanks for your time.
-ravi
