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]

Date:	Fri, 03 Nov 2006 15:23:33 +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:

> It is not as if we care about an extra context switch here,

Avoiding context switches aren't the main problem; avoiding serialisation is.

> and we really don't want to do that file i/o in the context of the rpciod
> process if we can avoid it.

We aren't doing file I/O in the context of the rpciod process, at least not to
the cache.  It's either done in the context of the process that issued the
read, write or pagefault.  keventd handles the copying of data from the backing
file pages to the netfs pages when we satisfy a read from the cache.

> It might be nice to be able to do those calls that only involve lookup+read
> in the context of the user's process in order to avoid the context switch
> when paging in data from the cache,

We do most of both in the user's process's context already.

The security problems come from the lookups, creates, xattr ops that we have to
do when acquiring a cookie.  All of these are done in the context of the
process that called iget5 for NFS.  We could farm them out to another process
to avoid the security, but that would then cause serialisation and context
switches.

> but writing to it both can and should be done as a write-behind process.
> 
> IOW: we should rather set up a separate workqueue to write data to disk,
> and just concentrate on working out a way to lookup and read data with
> no fsuid/fsgid changes and preferably a minimum of selinux magic.

Writing data to the cache is done by the pagecache at the moment.  I'd really
like to use direct I/O instead as that'd mean I wouldn't need shadow pages in
the page cache and I'd also be able to avoid the page-to-page copy I'm
currently doing.

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/