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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Nov 2006 20:06:21 +0000 From: David Howells <dhowells@...hat.com> To: torvalds@...l.org, akpm@...l.org, sds@...ho.nsa.gov, trond.myklebust@....uio.no Cc: dhowells@...hat.com, selinux@...ho.nsa.gov, linux-kernel@...r.kernel.org, aviro@...hat.com, steved@...hat.com Subject: [PATCH 00/19] Permit filesystem local caching and NFS superblock sharing These patches add local caching for network filesystems such as NFS and AFS. I've addressed all but one of Christoph's objections. The one objection I haven't yet dealt with is the addition of a new operation for writing a page of the file, but that's controversial, and I'd like feedback on what I've done so far. The main thing that I've dealt with is the security issue in CacheFiles: CacheFiles now calls the VFS wrappers for invoking filesystem operations, such as vfs_mkdir(). It does not call any of the inode operations directly anymore. This means, however, that it has to deal with SELinux, especially when in enforcing mode. The cachefilesd RPM installs a policy for labelling and accessing the files in the cache, and for providing a security ID for the cachefilesd daemon to run as. It _also_ provides a security ID for the cachefiles module to act as when it is accessing the filesystem on behalf of the process. The way this is done is that one of the patches: CacheFiles: Add an act-as SID override in task_security_struct permits the module to temporarily change the security ID as which a process _acts_. It does _not_ change the process's actual security ID, and so does not interfere with signals, ptraces, /proc/pid/ accesses aimed at that process. Furthermore, following consultations with Stephen Smalley and others of the SELinux project, it was deemed correct to override fsuid and fsgid of the host process whilst accessing the cache, so these are also modified temporarily by the module during such accesses. Finally, the file creation SID is also temporarily overridden whilst the module accesses the cache. All this permits the ownership and accessibility of files in the cache to preclude ordinary access by all processes running on the system, with the exception of cachefilesd. When SELinux is in enforcing mode, the daemon may not read or write the files in the cache according to the policy. Thanks to Dan Walsh and Karl MacMillan for helping me get the SELinux policy working. There is documentation on this in the patches and in the cachefilesd SRPM/tarball. Additionally, sysctls are no longer used. Some parameters are modifiable via sysfs. CacheFiles parameters pertaining to the cache are still only modifiable by sending commands to the module over its control interface, though the control interface is now a character device (following GregKH's suggestion). --- The kernel patches are committed to a GIT tree based on Linus's: git://git.infradead.org/users/dhowells/fscache-2.6.git Which can be viewed through: http://git.infradead.org/?p=users/dhowells/fscache-2.6.git;a=summary A tarball of patches is available at: http://people.redhat.com/~dhowells/fscache/patches/nfs+fscache-19.tar.bz2 To use this version of CacheFiles, the cachefilesd-0.8 is also required. It is available as an SRPM: http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8-15.fc7.src.rpm Or as individual bits: http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 http://people.redhat.com/~dhowells/fscache/cachefilesd.fc http://people.redhat.com/~dhowells/fscache/cachefilesd.if http://people.redhat.com/~dhowells/fscache/cachefilesd.te http://people.redhat.com/~dhowells/fscache/cachefilesd.spec 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/
Powered by blists - more mailing lists