On Mon, 2007-08-13 at 15:51 +0100, David Howells wrote: > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
