On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote:
> Casey Schaufler <[email protected]> wrote:
>
> > I haven't looked into the issues at all and I bet there are plenty,
> > maybe in audit and places outside of the security realm, but this
> > looks like a clean approach from the LSM interface standpoint. Do
> > you want the entire task or just task->security?
>
> It would probably have to be the task struct, lest the security information
> (for which I've no refcount held) went away whilst I was trying to access it.
>
> > I could see it either way, but I suspect the task is your best bet. If you
> > call security_act_as() twice, then security_act_as_self() do you pop a
> > stack, or return to the initial state?
>
> Good point. I've pondered that. What I have at the moment partly acts like a
> stack in that I store some of the shifted-out context on the machine stack (in
> struct cachefiles_secctx). The act-as context should probably be shifted too,
> in addition to the old file-creation SID and the fsuid/fsgid.
>
> > How about security_act_as(NULL) returning you to the initial state, and
> > dropping security_act_as_self()?
>
> That would be fine.
>
> Actually, to address Stephen Smalley's requirements also, how about making
> things a bit more complex. Have the following suite of functions:
>
> (1) int security_get_context(struct sec **_context);
>
> This allocates and gives the caller a blob that describes the current
> context of all the LSM module states attached to the current task and
> stores a pointer to it in *_context.
>
> (2) int security_push(struct sec *context, struct sec **_old_context)
>
> This causes all the LSM modules on the current task to switch to a new
> acting state, passing back the old state. It does not change how
> other tasks do things to this one.
>
> (3) int security_pop(struct sec *context)
>
> This causes all the LSM modules on the current task to switch to a new
> acting state, deleting the old state. It does not change how
> other tasks do things to this one.
>
> (4) int security_delete_context(struct sec *context)
>
> This deletes a context blob.
>
> The context blob could then be structured very simply. Give each loaded LSM
> module an integer index as it is registered. Having a limit to the number of
> LSM modules would make things simpler. The blob would then be an array of
> void pointers, one per LSM module, indexed by the integer index for each one.
> It you don't have a limit on the number of LSM modules, you'd also need a
> count of slots in the blob.
>
> Any LSM module that wanted to implement the above three functions would fill
> in or otherwise use the slot that belongs to it. Otherwise the slot would
> just be left NULL.
>
> For example:
>
> context --->+--------+ +---------+
> | SLOT 0 |----------------------------------->| SELINUX |
> +--------+ +--------+ +---------+
> | SLOT 1 |--------------------->| THINGY |
> +--------+ +--------+
> | ... |
> +--------+ +-------+
> | SLOT N |-------->| AUDIT |
> +--------+ +-------+
>
> For Stephen and NFS, he could then generate a context from NFS which nfsd
> could then put in place. Perhaps any unfilled slot would be ignored by the
> LSM module to which it belonged.
Seems like over-design - we don't need to support LSM stacking, and we
don't need to support pushing/popping more than one level of context.
What was the objection again to the original interface, aside from
replacing "u32 secids" with "void* security blobs"?
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
