Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Stephen Smalley <sds@xxxxxxxxxxxxx>
- Date: Thu, 13 Dec 2007 12:27:57 -0500
On Thu, 2007-12-13 at 17:01 +0000, David Howells wrote:
Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
They would correspond with the operations provided by the /dev/cachefiles
interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact that /dev/cachefiles has its own unique
label (cachefiles_dev_t).
That lets you control who can use the interface at all, but not what
operations they can invoke on it.
Could just be a single 'setcontext' permission if that is all you want to
control distinctly, or could be a permission per operation.
There is only one operation that makes sense to have a permission: "set
context and begin caching".
All the other operations on a file descriptor attached to /dev/cachfiles are
necessary for there to be a managed cache at all, and given that you've
managed to open /dev/cachefiles that's sufficient access for those, I think.
Do any of the interfaces allow a task to act on a cache other than one
it has created? How does the task identify the desired cache? What if
there is a conflict between multiple tasks asking for the same cache?
If the latter, you don't really need a label for the object, and can
just use the supplied context/secid as the object of the permission
check, ala:
rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES,
CACHEFILES__SETCONTEXT);
Ummm. I was under the impression that the target SID had to be a member of
target class.
Not necessarily.
secid is being applied as the acting context for the cachefiles kernel
module, so the above makes sense, even though there isn't really any
"object" in view here. Abstractly, the question we are asking above is:
Can this task set the context of the cachefiles kernel module to this
value?
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Stephen Smalley
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Stephen Smalley
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Stephen Smalley
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Stephen Smalley
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: Casey Schaufler
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: David Howells
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: David Howells
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: David Howells
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- From: David Howells
- Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- Prev by Date: Re: [PATCH] arch_ptrace_stop
- Next by Date: [GIT PULL] please pull infiniband.git
- Previous by thread: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- Next by thread: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
- Index(es):
Relevant Pages
|
