Research
Skip Research Menus
Research MenuSecurity 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: Thu, 02 Nov 2006 21:05:02 +0000
> It doesn't look simpler, but if you take this approach, then: Okay.
> 2) Use "secid" in the core code and LSM interfaces rather than just Okay.
> 3) Define and use a SECID_NULL or similar in the LSM interface Defining a reset function would be better.
> 4) Be careful about overuse of this id (see below for some examples). Yeah.
> > The flag approach is a bit more work to implement and will slow most ops So you were thinking of doing it in security.h?
> > There are a couple of things I'm not sure about with the ->fssid approach: Yes.
> I'm not entirely sure what you mean by (1); the existing syscall audit Which is irrelevant since the CacheFiles module doesn't make syscalls.
> SELinux avc audit messages from permission checks would include the fssid's That'd probably be sufficient since at least you could tell them apart.
> For (2), you have to make up a SID. I've done this and got it working with Karl's help. In cachefilesd.te, I have: ... type cachefilesd_t; type cachefilesd_exec_t; domain_type(cachefilesd_t) init_daemon_domain(cachefilesd_t, cachefilesd_exec_t) require { type kernel_t; } type cachefiles_kernel_t; domain_type(cachefiles_kernel_t) type_transition cachefilesd_t kernel_t : process cachefiles_kernel_t; ... Then I added a CacheFiles hook to do: static int selinux_cachefiles_getsid(u32 secid, u32 *modsecid) { return security_transition_sid(secid, SECINITSID_KERNEL, SECCLASS_PROCESS, modsecid); } It takes the daemon's security ID and translates it to the module's security ID. The way I was thinking about it is that a CacheFiles cache has a presence in the kernel that lasts as long as the cache is in active service. This could be considered the equivalent of a process, although it doesn't have a task_struct of its own; but rather makes use of the task_struct of processes that want to use the service.
> This differs from how NFS would use such a facility, since it could just use Indeed; but once NFS had a SID, the two would then be the same.
> But this requires policy configuration to make it work properly, and the If the rule isn't there then the cache would refuse to start if SELinux is in enforcing mode, assuming security_transition_sid() returns an error in that case. Otherwise it'll run in cachefilesd's context, I think, which it will cause it to give an error and refuse to cache in enforcing mode because that context doesn't permit it to do certain things it checks for (like creating files and directories).
> > + rc = avc_has_perm(secid, tsec->fssid, SECCLASS_PROCESS, perm, NULL); Yep... I got that one wrong.
> > - isec->sid = tsec->sid; And again. Anyway, I'll expand what I've done and give it a go. I may find compelling reasons[*] not to do it this way. I can always ditch the patches after all... [*] Overzealous auditing most probably.
Thanks,
-- 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 Thu 2 Nov 2006 - 16:06:27 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |