[247] in The Cryptographic File System users list
Re: multi user question
daemon@ATHENA.MIT.EDU (aaron)
Fri Oct 26 15:30:35 2001
From owner-cfs-users@crypto.com Fri Oct 26 19:30:35 2001
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.mit.edu
Received: (qmail 17322 invoked from network); 26 Oct 2001 19:30:34 -0000
Received: from mx.crypto.com (207.140.168.138)
by charon.mit.edu with SMTP; 26 Oct 2001 19:30:34 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id PAA01226
for cfs-users-list; Fri, 26 Oct 2001 15:16:41 -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 PAA31612
for <cfs-users@crypto.com>; Fri, 26 Oct 2001 15:16:39 -0400 (EDT)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id PAA16734 for <cfs-users@nsa.research.att.com>; Fri, 26 Oct 2001 15:16:37 -0400 (EDT)
Received: by mail-green.research.att.com (Postfix)
id C25AC1E046; Fri, 26 Oct 2001 15:16:38 -0400 (EDT)
Delivered-To: cfs-users@research.att.com
Received: from meta.lo-res.org (meta.lo-res.org [195.58.189.92])
by mail-green.research.att.com (Postfix) with ESMTP id D973F1E011
for <cfs-users@research.att.com>; Fri, 26 Oct 2001 15:16:37 -0400 (EDT)
Received: from there ([194.24.158.17])
by meta.lo-res.org (8.11.6/8.11.6) with SMTP id f9QJHDI97232;
Fri, 26 Oct 2001 21:17:14 +0200 (CEST)
(envelope-from aaron@lo-res.org)
Message-Id: <200110261917.f9QJHDI97232@meta.lo-res.org>
Content-Type: text/plain;
charset="iso-8859-1"
From: aaron <aaron@lo-res.org>
To: Valdis.Kletnieks@vt.edu
Subject: Re: multi user question
Date: Fri, 26 Oct 2001 17:48:16 +0200
X-Mailer: KMail [version 1.3]
Cc: cfs-users@research.att.com
References: <200110261307.f9QD7dI95783@meta.lo-res.org> <200110261357.f9QDvoUg025016@foo-bar-baz.cc.vt.edu>
In-Reply-To: <200110261357.f9QDvoUg025016@foo-bar-baz.cc.vt.edu>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: owner-cfs-users@crypto.com
Precedence: bulk
On Friday 26 October 2001 15:57, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 26 Oct 2001 15:06:39 +0200, aaron <aaron@lo-res.org> said:
> > I.e: for me CFS should work like that: offer write access for root
> > (sendmail) to store mails in the /crypt directory. For all users it
> > should allow read access to /crypt/<usersmailbox>
> >
> > However when I create the usual /crypt and encrypted directory (lets call
> > it /usr/cryptedmail) and then cattach /usr/cryptedmail to /crypt as root
> > - then only root will be able to read and write to /crypt/cryptedmail.
> > (permission 700)
> >
> > Sooo, is there a way to get around that permission problem?
>
> This is an NFS issue. You should think *long* and *hard* about the
> implications first, and then try something like this in /etc/exports:
>
> /usr/cryptedmail -root=localhost
>
ok, hm, tried it. but did not help.
Let me try to explain the problem again:
(maybe then it turns out that we were talking about slightly differnet
things?)
1) the users perspective:
The user wants to be sure that his mail is encrypted on disk. Since we
all trust each other on the system, he does not
care so much if other users on the _running_ system can read his mails.
But he wants to be damn sure that the mails can't be read once the
machine is turned off. Only an authorized person should be able to mount/
cattach the encrypted mail directory as soon as the machine comes up again.
Of course this scheme implies that very strict network security mechanisms
are in place so that the machine can't be hacked. It also implies that a
the users on the system will have to trust each other. Fine with me :)
So to sum it up: I would like to build a dead man trigger: once the power
is off only once, nobody will be able to read the mail/receive mail, etc.
2) the sysadmins perspective: CFS is the only crypto filesystem supported
under FreeBSD. :))
But hey, it looks really cool so far!
ok, here is what I did to get it running so far:
# mkdir /null # bootstrapping as in README.install
# chmod 0 /null
# echo "/null -maproot=0 localhost " >> /etc/exports
# mkdir /usr/crypt # mount point (usually called "/crypt")
# cmkdir /usr/cryptedmail # will hold the actual crypted data blocks
# echo "/usr/cryptedmail -maproot=0 localhost" >> /etc/exports
# <... started up nfs, portmapper, nfsiod, nfsd, mountd, cfsd>
# mount -o port=3049,intr /null /usr/crypt
# cattach /usr/cryptedmail mail
<password promtp, then it attaches>
and here is the problem:
# ls -alFg /usr/crypt
total 1
drwx------ 2 root wheel - 512 Oct 26 17:14 mail/
i obviously cattached it as root. If I cattach it as another user, it will
belong to that user but still have permissions 700.
did I misunderstand something? Ah yes: version is cfs 1.4.0 beta2
thanks again for your time, I really appreciate your help.
aaron.
> What is happening is that NFS is doing the usual 'root->nobody' mapping.
>
> *HOWEVER* - I have to recommend against this. Consider that usually,
> the reason for using CFS is because you *dont* trust 'root'. If you do
> this, you have basically *no* added security (consider that in a multi-user
> system, that directory has to be attached 24x7 so mail can be delivered).
>
> Also - you *really* need to allow the users write access to their mailbox,
> as otherwise they can't remove already-read items (unless the *idea* here
> is to *keep* them from deleting already-read mail?)
>
> And of course, the usual caveats apply here - encrypting the mailbox does
> no real good unless you've *also* done a threat analysis on the *entire*
> end-to-end mail process - is TLS or similar used to secure the SMTP
> transaction? Are the MUAs fixed (or at least users educated) to prevent
> them saving a sensitive mail as a world-readable file? And so on....
