From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "Muntz, Daniel" <Dan.Muntz@netapp.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Bernd Schubert <bernd.schubert@fastmail.fm>,
nfsv4@linux-nfs.org, steved@redhat.com,
linux-kernel@vger.kernel.org, dhowells@redhat.com,
linux-next@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
rwheeler@redhat.com
Subject: RE: Pull request for FS-Cache, including NFS patches
Date: Tue, 30 Dec 2008 17:36:08 -0500 [thread overview]
Message-ID: <1230676568.11508.21.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01AAFE66@SACMVEXC1-PRD.hq.netapp.com>
On Tue, 2008-12-30 at 14:15 -0800, Muntz, Daniel wrote:
> >> As for security, look at what MIT had to do to prevent local disk
> >> caching from breaking the security guarantees of AFS.
> >
> >See what David has added to the LSM code to provide the same guarantees
> for cachefs...
> >
> >Trond
>
> Unless it (at least) leverages TPM, the issues I had in mind can't
> really be addressed in code. One requirement is to prevent a local root
> user from accessing fs information without appropriate permissions.
> This leads to unwieldly requirements such as allowing only one user on a
> machine at a time, blowing away the cache on logout, validating (e.g.,
> refreshing) the kernel on each boot, etc. Sure, some applications won't
> care, but you're also potentially opening holes that users may not
> consider.
You can't prevent a local root user from accessing cached data: that's
true with or without cachefs. root can typically access the data
using /dev/kmem, swap, intercepting tty traffic, spoofing user creds,...
If root can't be trusted, then find another machine.
The worry is rather that privileged daemons may be tricked into
revealing said data to unprivileged users, or that unprivileged users
may attempt to read data from files to which they have no rights using
the cachefs itself. That is a problem that is addressable by means of
LSM, and is what David has attempted to solve.
Trond
next prev parent reply other threads:[~2008-12-30 22:36 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 0:30 Pull request for FS-Cache, including NFS patches David Howells
2008-12-18 11:44 ` Stephen Rothwell
2008-12-18 14:24 ` Christoph Hellwig
2008-12-18 20:36 ` Andrew Morton
2008-12-18 23:07 ` Bernd Schubert
2008-12-18 23:26 ` Andrew Morton
2008-12-19 0:05 ` Stephen Rothwell
2008-12-29 3:45 ` Stephen Rothwell
2008-12-29 4:01 ` Andrew Morton
2008-12-29 14:30 ` Trond Myklebust
2008-12-29 14:54 ` Ric Wheeler
2008-12-29 23:05 ` Muntz, Daniel
2008-12-30 18:44 ` Trond Myklebust
2008-12-30 22:15 ` Muntz, Daniel
2008-12-30 22:36 ` Trond Myklebust [this message]
2008-12-30 23:00 ` Muntz, Daniel
2008-12-30 23:17 ` Trond Myklebust
2009-01-01 4:11 ` Muntz, Daniel
2009-01-01 8:09 ` Arjan van de Ven
2009-01-01 18:40 ` Kyle Moffett
2008-12-31 11:15 ` David Howells
2008-12-31 9:49 ` Arjan van de Ven
2008-12-29 4:07 ` Andrew Morton
2008-12-29 5:26 ` Stephen Rothwell
2008-12-29 15:01 ` David Howells
2008-12-29 15:04 ` David Howells
2008-12-29 14:26 ` David Howells
2008-12-19 2:27 ` David Howells
2008-12-19 2:44 ` Andrew Morton
2008-12-19 3:10 ` Ric Wheeler
2008-12-19 12:33 ` Trond Myklebust
2008-12-19 16:48 ` Gabor Gombas
2008-12-19 13:32 ` David Howells
2008-12-19 3:45 ` Muntz, Daniel
2008-12-19 4:09 ` J. Bruce Fields
2008-12-19 13:20 ` David Howells
2008-12-19 18:08 ` Muntz, Daniel
2008-12-19 18:24 ` David Howells
2008-12-19 19:53 ` Bryan Henderson
2008-12-20 1:20 ` David Howells
2008-12-20 6:05 ` Muntz, Daniel
2008-12-19 13:22 ` David Howells
2008-12-19 13:03 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2008-12-20 6:06 Muntz, Daniel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1230676568.11508.21.camel@heimdal.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=Dan.Muntz@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=bernd.schubert@fastmail.fm \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=rwheeler@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=steved@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).