Re: Thinking about stacking in LSM: merge registering, add info about field use to security_operations

lachlanat_private

Chris Wright wrote:
> * Lachlan McIlroy (lachlanat_private) wrote:
> 
>>How about a scheme where a multiplexor module's version of
>>mod_reg_security() returns a security descriptor (like a
>>file descriptor) that is unique to each subordinate module
>>loaded and is used to access the subordinate module's
>>security blob with object->security[security_descriptor]?
> 
> 
> Yes, this is almost possible as it stands.  The only issue is the
> expected return from mod_reg_security is 0 for success, non-zero for
> failure.  This is the way we had originially discussed allowing for
> stacking (directly in the framework).  Because arbitrary security model
> composition yields undefined results (oh yeah, and Linus said he didn't
> want to see stacking ;-) we chose to push stacking to the module --
> a bit of policy to be implemented in the module not in the framework.
> 
> I am not opposed to changing the mod_reg interface such that < 0 is
> failure and >= 0 is success.  But the only way this would be useful is
> if the module knew to use ->security[index].  Since the common case is
> unstacked (direct blob access) would we expect a module to chose when to
> use ->security vs. ->security[index] or simply expect that a module is
> either stackable or not, but not both?  Making all blobs void** would
> fix this, but this looks suspiciously like explicit encouragement in
> the framework for stacking.
We could implement an API for accessing security blobs.

In security.c:

void *get_task_blob(struct task_struct *task, int security_id)
{
	return security_ops->task_get_blob(task, id);
}

primary LSM module that does not support blob arrays:

void *boring_lsm_module_task_get_blob(struct task_struct *task, int id)
{
	return task->security;
}

primary LSM module that does support blob arrays:

void *spiffy_multiplexor_module_task_get_blob(struct task_struct *task, 
int id)
{
	/* possibly do blob management stuff */
	return task->security[id];
}

... and the same for all the other objects (ie inodes, binprms, etc..).

... and simliar for setting blobs on objects.

The blobs don't have to be void ** and subordinate modules don't (and 
won't) have to know how the blobs are being accessed.

> 
> Is elaborate, flexible stacking really something people want?  What's the
> justification (other than it's an interesting problem to solve ;-) ?
I like to use the "because we can" argument!

> 
> thanks,
> -chris

Lachlan

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module