public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: David Howells <dhowells@redhat.com>,
	aviro@redhat.com, linux-kernel@vger.kernel.org,
	selinux@tycho.nsa.gov, chrisw@sous-sol.org, jmorris@namei.org
Subject: Re: Security issues with local filesystem caching
Date: Fri, 27 Oct 2006 18:34:10 +0100	[thread overview]
Message-ID: <7451.1161970450@redhat.com> (raw)
In-Reply-To: <1161968942.1306.87.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley <sds@tycho.nsa.gov> wrote:

> > You start the cache by mounting it:
> > 
> > 	mount -t cachefs /dev/hdx9 /cachefs
> > 
> > Then it's online.  However, you might want to check that whoever's calling
> > mount has permission to bring a cache online...
> 
> Hmmm...that raises a separate issue - how does SELinux label cachefs
> inodes?  Does cachefs support xattrs?  Other option is to use a mount
> context (mount -o context=...) to apply a single context to all inodes
> within it.

There are only two inodes publically available through cachefs - the root dir
and a file of statistics - and they're both read only.  Everything else, for
the moment, is strictly internal and unavailable to userspace.  In fact, there
may not be any other inodes.

> Where exactly is the cachefs code available?

It'll need a little bit of work to make it compilable again; but I can probably
get you a copy on Monday.  I've been concentrating on CacheFiles.

> I'm also unclear on where you establish the binding between the files
> being cached and the cache.  What specifies that e.g. a given NFS mount
> should be backed to a given cache?  We need to be able to control that
> relationship too, to establish that the cache is being protected
> adequately for the source data.

Yes.  I haven't worked that one out yet.  Currently it's not a problem as only
CacheFiles is available at the moment, and that currently only supports one
cache.

But I have an idea that I need to work on to make it possible to associate
directories and files with caches (or other useful parameters).

> >  (1) Permission to bring a cache online or to take a cache offline.
> 
> At present, this will show up as the usual checking on mount (security
> hooks in do_mount and vfs_kern_mount) and on umount (security hook in
> do_umount) by SELinux.  I'm not sure whether you need anything specific
> to the cache.

That doesn't apply to CacheFiles, but okay; we can always add it later if we
decide we want it.

David

  reply	other threads:[~2006-10-27 17:35 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-25 10:14 Security issues with local filesystem caching David Howells
2006-10-25 16:52 ` Nate Diller
2006-10-25 16:48   ` Jeff V. Merkey
2006-10-25 17:21     ` David Howells
2006-10-25 17:42       ` Jeff V. Merkey
2006-10-25 18:15         ` David Howells
2006-10-25 20:21 ` Josef Sipek
2006-10-25 20:28   ` Josef Sipek
2006-10-26  9:56   ` David Howells
2006-10-27 15:54     ` Josef Sipek
2006-10-25 21:12 ` Stephen Smalley
2006-10-26 10:40   ` David Howells
2006-10-26 12:51     ` Stephen Smalley
2006-10-26 16:04       ` David Howells
2006-10-26 16:34         ` Stephen Smalley
2006-10-26 17:09           ` David Howells
2006-10-26 17:45             ` Stephen Smalley
2006-10-26 22:53               ` David Howells
2006-10-27 14:48                 ` Stephen Smalley
2006-10-27 15:42                   ` David Howells
2006-10-27 16:10                     ` Stephen Smalley
2006-10-27 16:25                       ` David Howells
2006-10-27 17:09                         ` Stephen Smalley
2006-10-27 17:34                           ` David Howells [this message]
2006-10-27 14:41               ` David Howells
2006-10-25 23:37 ` Alan Cox
2006-10-26  0:32   ` Al Viro
2006-10-26 10:45     ` David Howells
2006-10-26 10:54     ` Alan Cox
2006-10-26  9:14 ` Jan Dittmer
2006-10-26 10:55   ` David Howells
2006-10-26 11:52   ` Alan Cox
2006-10-31 21:26 ` David Howells
2006-11-01 13:28   ` Stephen Smalley
2006-11-01 15:34     ` David Howells
2006-11-01 15:58       ` Karl MacMillan
2006-11-01 17:45         ` Stephen Smalley
2006-11-02 16:29           ` Karl MacMillan
2006-11-02 18:04             ` Stephen Smalley
2006-11-01 17:30       ` Stephen Smalley
2006-11-02 17:16         ` David Howells
2006-11-02 19:49           ` Trond Myklebust
2006-11-02 20:38             ` David Howells
2006-11-02 21:24               ` Trond Myklebust
2006-11-03 10:27                 ` David Howells
2006-11-03 13:41                   ` Trond Myklebust
2006-11-03 15:23                     ` David Howells
2006-11-03 17:30                       ` Trond Myklebust
2006-11-14 19:22                         ` David Howells
2006-11-15 14:05                           ` Trond Myklebust
2006-11-15 15:28                             ` David Howells
2006-11-15 16:41                               ` Trond Myklebust
2006-11-15 18:17                                 ` David Howells
2006-11-03 15:33                     ` David Howells
2006-11-02 20:33           ` Stephen Smalley
2006-11-02 21:05             ` David Howells

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=7451.1161970450@redhat.com \
    --to=dhowells@redhat.com \
    --cc=aviro@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /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