linux-kernel - Re: Security issues with local filesystem caching

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: <12984.1162549621@redhat.com>
Date:	Fri, 03 Nov 2006 10:27:01 +0000
From:	David Howells <dhowells@...hat.com>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	David Howells <dhowells@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Karl MacMillan <kmacmill@...hat.com>, jmorris@...ei.org,
	chrisw@...s-sol.org, selinux@...ho.nsa.gov,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: Security issues with local filesystem caching 

Trond Myklebust <trond.myklebust@....uio.no> wrote:

> > Well, both Christoph and Al are of the opinion that I should be using
> > vfs_mkdir() and co rather than bypassing the security and calling inode ops
> > directly.
> 
> ...but why are you needing to call vfs_mkdir? I thought the standard
> cachefs backend just uses a pool of files, rather like the original AFS
> cache did. Are you trying to mirror the layout and the permissions of
> the NFS filesystem? That is a lot more work than it is worth...

No.

I have to have a way of mapping a netfs file onto a cache storage object.  I do
this by translating the keys the netfs gives me into a path of directory and
file names in the cache.

In NFS's case there are three keys describing a file:

 (1) "NFS"

 (2) { Server IP, Server port, NFS version }

 (3) NFS File Handle

These wind up in the filesystem looking something like:

	INDEX     INDEX      INDEX                             DATA FILES
	========= ========== ================================= ================
	cache/@...I03nfs/@...Ji000000000000000--fHg8hi8400
	cache/@...I03nfs/@...Ji000000000000000--fHg8hi8400/@...Es0g000w...DB1ry
	cache/@...I03nfs/@...Ji000000000000000--fHg8hi8400/@...Es0g000w...N22ry
	cache/@...I03nfs/@...Ji000000000000000--fHg8hi8400/@...Es0g000w...FP1ry

See Documentation/filesystems/caching/cachefiles.txt for more information, in
particular the section "Cache Structure".

Anyway, it's not just vfs_mkdir(), there's also vfs_create(), vfs_rename(),
vfs_unlink(), vfs_setxattr(), vfs_getxattr(), and I'm going to need a
vfs_lookup() or something (a pathwalk to next dentry).

Yes, I'd prefer not to have to use these, but that doesn't seem to be an
option.

> > Also I should be setting security labels on the files I create.
> 
> To what end? These files shouldn't need to be made visible to userland
> at all.

But they are visible to userland and they have to be visible to userland.  They
exist in the filesystem in which the cache resides, and they need to be visible
so that cachefilesd can do the culling work.  If you were thinking of using
"deleted" files, remember that I want it to be persistent across reboots, or
even when an NFS inode is flushed from memory to make space and then reloaded
later.

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/