[109] in The Cryptographic File System users list
Re: cattach permission problem
daemon@ATHENA.MIT.EDU (Rob Stampfli)
Thu Oct 8 22:51:51 1998
From owner-cfs-users@research.att.com Fri Oct 09 02:51:50 1998
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 25097 invoked from network); 9 Oct 1998 02:51:49 -0000
Received: from unknown (HELO rumor.research.att.com) (192.20.225.9)
by bloom-picayune.mit.edu with SMTP; 9 Oct 1998 02:51:49 -0000
Received: from research.att.com ([135.207.30.100]) by rumor; Thu Oct 8 22:45:47 EDT 1998
Received: from amontillado.research.att.com ([135.207.24.32]) by research; Thu Oct 8 22:49:58 EDT 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 WAA13341;
Thu, 8 Oct 1998 22:50:30 -0400 (EDT)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id WAA07473 for cfs-users-list; Thu, 8 Oct 1998 22:42:57 -0400 (EDT)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from research.att.com (research.research.att.com [135.207.30.100]) by nsa.research.att.com (8.7.3/8.7.3) with SMTP id WAA07469 for <cfs-users@nsa.research.att.com>; Thu, 8 Oct 1998 22:42:55 -0400 (EDT)
Received: from elektro.cmhnet.org ([192.188.133.3]) by research; Thu Oct 8 22:47:15 EDT 1998
Received: from colnet by elektro.cmhnet.org with uucp
(Smail3.1.29.1 #1) id m0zRSZD-0001QlC; Thu, 8 Oct 98 22:46 EDT
Received: by colnet.cmhnet.org (Smail3.1.28.1 #4)
id m0zRSIW-0008F9C; Thu, 8 Oct 98 22:28 EDT
Message-Id: <m0zRSIW-0008F9C@colnet.cmhnet.org>
Date: Thu, 8 Oct 98 22:28 EDT
From: res@colnet.cmhnet.org (Rob Stampfli)
To: cfs-users@research.att.com, Walter Haidinger <walter.haidinger@gmx.net>
Subject: Re: cattach permission problem
Sender: owner-cfs-users@research.att.com
Precedence: bulk
In recent email Walter writes:
>On Wed, 7 Oct 1998, Rob Stampfli wrote:
>
>> Not that I'd necessarily recommend this, but one way would be to give your
>> client machine root access permissions in the "export" file on the server.
>> I'm not sure how this is done under Linux, but on SunOS, for instance,
>> if you add
>>
>> /home -access=x,root=x
>>
>> to the /etc/exports file on the system exporting /home, then machine x
>> can mount /home and have full root privileges in it. I do this on a local
>> LAN at home. I would consider it a security risk on a public LAN.
>>
>
>I added the following to /etc/exports and made nfsd and mountd reread it:
>
>/ localhost(rw,no_root_squash,insecure)
>
>which allows any user to mount the root directory read/write from any port
>(insecure) while NOT mapping uid 0 to nobody (no_root_squash). So, this is
>like accessing / regulary but through nfs. If root does
> mount -t nfs localhost:/ /mnt
>every user can access / through /mnt without with no change in rights.
>[Yes, you grant everyone root access, but please read my question below.]
>
>Unfortunatly this doesn't work. There must be still permission to
>'others' to access the directory in order to cattach it.
In both your previous case as well as the current case, I believe the
problem is the fact that cfsd, which is trying to access the encrypted
directory as "walter", cannot do so because it is missing the extra groups
user walter normally belongs to. I don't really have a total grasp of how
you have your system set up, but I think you have pretty much proven that it
is not the unusual "root" oddities wrt nfs mounts that is biting you here.
...
>User walter calls cattach which contacts cfsd. Next, cfsd masquerades as
>'walter' and tries to cd to the directory which should be mounted. It
>fails because the higher directories require group permissions which
>walter is a member of, but not neither group is walter's primary [Assuming
>that setuid only sets the users primary group id too, if any at all. I
>really do not know how group rights are handled when setuid is called].
You are basically right. I don't think a "cd" is involved, but cfsd
definitely needs to access its "special" files in the encrypted directory,
to do stuff like determine which encryption mode is to be used, as well
as to access the actual encrypted files. setuid() really does nothing but
change group ids. It is a very simple system call.
>A solution would be having cfsd locating the directory as root and then
>mounting it as (or for) walter.
>Another possiblity would be if csfd would not do not only a setuid() but
>also became a member of *all* groups the user is a member of too.
The first option would be a security risk. Think about it and I'm sure
you'll understand why. The second possibility is probably doable, but
not simple: I suspect cfsd knows a uid number, but not a user name.
You'd have to hack the user name into the information passed. (There may
be two users with different group permissions, but the same uid.) Trying
to prove which user you are (securely) is not all that simple. Then
you'd have to hack in the code to set groups (something that might not
be easy to administer across OS lines).
>Is this possible or am I totally off track here?
I think you've pretty much figured it out.
--
Robert Stampfli rob@colnet.cmhnet.org stampfli@bell-labs.com
kd8wk@w8cqk.oh (ham) 614-864-9377 (home) 614-860-4268 (work)
