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

chrisat_private

* Lachlan McIlroy (lachlanat_private) wrote:
> 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];
> }
> 

This does not help with Matt's subordinate module that perhaps allocates
the new process's security blob by copying it from parent.  It did:

p->security = current->security;

where struct task_struct *p is all that was passed to the subordinate
module.  In fact, because current is implicit, many modules may look at
the foo_object->security blob (which perhaps was clearly swapped by the
multiplexor) and compare it aginst current->security which might not
have been swapped out.  It's not reasonable for the multiplexor to swap
every single blob in the kernel, and unless you really know how the two
modules interract, you don't necessarily know what are the right blobs
to swap.

So, this still leaves the subordinate module with the need to chose
which method it is accessing the blob by.  Or am I missing something?

> ... 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.

I think they do, see above.

> > 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!

Nah, we need the, "because we need it to enable foo type of security
models" kind of argument ;-)

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module