linux-kernel - Re: [PATCH 00/16] Permit filesystem local caching [try #3]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7504.1186821682@redhat.com>
Date:	Sat, 11 Aug 2007 09:41:22 +0100
From:	David Howells <dhowells@...hat.com>
To:	casey@...aufler-ca.com
Cc:	dhowells@...hat.com, torvalds@...l.org, akpm@...l.org,
	steved@...hat.com, trond.myklebust@....uio.no,
	linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3]

Casey Schaufler <casey@...aufler-ca.com> wrote:

> How would you expect an LSM that is not SELinux to interface with
> CacheFiles?

You have to understand that I didn't know that much about the LSM interface,
so I asked advice of the Red Hat security people, who, naturally, pointed me
at the SELinux mailing list.  I knew my stuff would have to work with SELinux
to be used with RH stuff.

Furthermore, as you pointed out, there aren't any other LSM modules upstream
yet for me to work against.  I would like CacheFiles to work with all LSM
modules in general, but I don't know how to do that yet.

I'm open to suggestion as to how to modify things to support any LSM.

Btw, do you understand the problems that CacheFiles has to deal with?  If I
set this down clearly, this may help you or someone else suggest a better way
to do things.

  (1) Some random process tries to access a file on a network filesystem
      (NFS example).

  (2) NFS goes to the cache to attempt to read the data from there prior to
      going to the network.

  (3) The cache driver wants to access the files in the cache, but it's
      running in the security context of either the aforementioned random
      process, or one of FS-Cache's thread pool.

      This security context, however, doesn't necessarily give it the rights
      to access what's in the cache, so the driver has to be permitted to act
      as a context appropriate to accessing the cache, without changing the
      overall security context of the random process (which would impact
      things trying to act on that process - kill() for example).

  (4) Assuming the data is found in the cache, all well and good, but if it
      isn't, the cache driver will have to create some files in the cache.

      Now, if the cache driver just went ahead and created the files, they
      could end up with their own security contexts being derived from the
      random process's security context, thus potentially making it impossible
      for other processes to access the cache.

      So the file-creation part of the security context must also be
      overridden temporarily, assuming that whatever LSM is in force has such
      a concept.

Part of the problem is that the VFS does not pass around the security context
as which the VFS routines act, but rather gets them from the task_struct.  For
the most part, this is entirely sufficient, but in the cache driver case, it's
a problem.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/