Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRe: Security issues with local filesystem caching
From: David Howells <dhowells_at_redhat.com>
Date: Fri, 27 Oct 2006 17:25:23 +0100
> > I was also wondering if I could generalise it to handle all cache types, No. In the latter case, there is no userspace daemon. As there are no dentries, filenames and paths in CacheFS, keeping track of the cull table consumes a less space than for CacheFiles. You start the cache by mounting it: mount -t cachefs /dev/hdx9 /cachefs Then it's online. However, you might want to check that whoever's calling mount has permission to bring a cache online... Actually, I think the permission to bring a cache online applies in all cases, and is probably separate from checking that CacheFiles(d) is permitted to mangle the filesystem it's using for a cache. With CacheFS, we could do the equivalent and do a MAC check to make sure we're permitted to read and write the blockdev, as you suggest in the next bit:
> I suppose the hook could internally check the type of inode to decide what So, to summarise, is it worth having two checks: (1) Permission to bring a cache online or to take a cache offline. (2) Permission for the process bringing the cache online (cachefilesd or mount) to access the backing store, be it a set of files and directories, or be it a blockdev. David -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.Received on Fri 27 Oct 2006 - 12:26:26 EDT |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |