On Wed, 2007-12-12 at 18:29 +0000, David Howells wrote:
Well, that has been Casey's objection in the past to it, but he seems to
have accepted their use now for certain purposes, and they are already
entrenched in the audit and labeled networking interfaces.
security_secctx_to_secid() would just validate and map a context string
to a secid. It wouldn't perform any permission check, as the caller
might a kernel-internal user that is just mapping back and forth like
current users of security_secid_to_secctx, or it might be something that
ultimately originated from userspace but the hook has no way of knowing
why or what set of checks would be appropriate. You'd need a more
specific hook for the authorization, one that would perform a permission
check, e.g. an avc_has_perm() call. Which likely requires defining a
new class and permissions for your cachefiles kernel interface.
I was under the impression that security_task_kernel_act_as() was being
used to switch the current task to an acting context, not to initially
set up a struct for later use. If you go with the latter approach, then
what is the lifecycle on that struct?
BTW, it gets a little confusing with your use of task_security for the
full task security state vs our existing use of task_security_struct
within SELinux for the task's LSM security blob. I suppose ours could
be renamed to task_selinux.
--
Stephen Smalley
National Security Agency
--
