daemon@ATHENA.MIT.EDU (Matt Blaze)
Mon Oct 16 21:59:07 2000
From owner-cfs-users@crypto.com Tue Oct 17 01:59:07 2000
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.MIT.EDU
Received: (qmail 3326 invoked from network); 17 Oct 2000 01:59:05 -0000
Received: from mx.crypto.com (207.140.168.138)
by charon.mit.edu with SMTP; 17 Oct 2000 01:59:05 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id VAA02066
for cfs-users-list; Mon, 16 Oct 2000 21:55:07 -0400 (EDT)
Received: from fbi.crypto.com (localhost [127.0.0.1])
by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id VAA21064
for <cfs-users@crypto.com>; Mon, 16 Oct 2000 21:55:06 -0400 (EDT)
Received: from fbi.crypto.com (mab@localhost)
by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id VAA21290
for <cfs-users@crypto.com>; Mon, 16 Oct 2000 21:57:15 -0400
Message-Id: <200010170157.VAA21290@fbi.crypto.com>
X-Authentication-Warning: fbi.crypto.com: mab owned process doing -bs
X-Mailer: exmh version 2.1.1 10/15/1999
To: cfs-users@crypto.com
Subject: BOUNCE cfs-users@crypto.com: Non-member submission from [Robert Stampfli <res@c (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 16 Oct 2000 21:57:15 -0400
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@crypto.com
Precedence: bulk
------- Forwarded Message
Date: Mon, 16 Oct 2000 21:53:25 -0400 (EDT)
From: Robert Stampfli <res@colnet.cmhnet.org>
Message-Id: <200010170153.VAA00668@colnet.cmhnet.org>
To: cfs-users@research.att.com, ravi@symonds.net
Subject: Re: using cfs with /home
Content-Type: text
Sender: owner-cfs-users@research.att.com
> I was wondering if anyone had custom scripts built to work along
>with CFS so that the /home directory is maintained encrypted and the
>encryption/decryption process is done transparently so that normal users
>logging into the machine do not really know that crypt is working in the
>background, while system level security is maintained? I'd appreciate any
>pointers/links/suggestions/comments on this idea.
For what it's worth, here is the .profile I am currently using to protect
several accounts. It's not exactly what you want: Each user has to
enter his/her cfs password when logging on in addition to the normal
account password, so it does not have the transparency you desire.
However, encrypted home directory and subdirectories (each user's acct)
is truly isolated and secured by cfs. I've noticed a few anomalies along
the way but, really, it works suprisingly well.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
# Generic .profile for an account protected by cfs.
# (compatible with /bin/sh and /bin/ksh)
# Written by R. E. Stampfli, February 1998
#
umask 077
while [ ! -d .cd ]
do
echo "You do not have an encrypted directory. Creating one..."
echo "Select a Directory \c"
cmkdir .cd
done
# Note: hidden directories tend to break trn and xv.
# D=.$RANDOM.$RANDOM
# export RANDOM=0
D=$LOGNAME
# Allow two tries at cfs password:
cattach .cd $D || cattach .cd $D || exit 1
# Note: the 'exec' below is needed to prevent an NFS write err 70
# on cdetach, due to the severing of open fd to ksh history file.
trap "exec cdetach $D" 0
HOME=/crypt/$D
cd $HOME || exit 1
[ -d tmp ] && TMPDIR=$HOME/tmp && export TMPDIR
[ -f .profile ] && . ./.profile
------- End of Forwarded Message
