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: <7864.1161856568@redhat.com>
Date:	Thu, 26 Oct 2006 10:56:08 +0100
From:	David Howells <dhowells@...hat.com>
To:	Josef Sipek <jsipek@....cs.sunysb.edu>
Cc:	sds@...ho.nsa.gov, 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 

Josef Sipek <jsipek@....cs.sunysb.edu> wrote:

> Hrm. How do you do DAC checks if you don't copy over the permissions without
> alteration?

You have to remember there are two filesystem layers involved.  NFS or other
netfs does the DAC, MAC, whatever checks to see whether the user can access a
file.  NFS then asks the cache to back the netfs file and the cache creates a
file in the local filesystem to do that.

The cache file doesn't need the DAC/MAC/whatever attributes applied to the
netfs file, and, in fact, may not be able to support what the netfs deals
with.

> I'm wondering, why don't just you duplicate all the attributes of the files
> (including xattrs)? That would take care of most if not all the DAC/MAC
> issues, no?

You're forgetting that the userspace cache manager daemon still has to access
the cache.

> >  (1) Do all the cache operations in their own thread (sort of like knfsd).
>  
> In our case it works well, however we have only very specific times when we
> need to use the work queue, so the performance hit doesn't hurt us as much
> as it would hurt you - I'm assuming you'd be using the thread for a sizable
> portion of calls you get.

I'm not sure exactly.  Actually, I could probably deal with read/write ops
inline - though I don't have a file struct to carry a security context - but
getting and releasing inodes would certainly wind up being farmed off.
Consider the automounter releasing an NFS share that's been heavily used...

> I'm thinking that it would be nice to combine the caching related security
> code with those for stackable filesystems.

That's fine by me, though I want the security on a cache file to be different
to that on the netfs file it's backing.

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/