Chris Wright wrote: > * 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? Use this: set_task_blob(p, get_task_blob(current, id), id); or more generally: blob = get_task_blob(current, id); /* fiddle with blob */ set_task_blob(p, blob, id); This interface is abstract enough that it will support nested multiplexing modules (if anybody wants such a feature - you could even have a B-tree of LSM modules where the module id is the key!). > > >>... 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 -- Lachlan McIlroy Tel: +61 3 8534 5531 Trusted Linux Fax: +61 3 9596 2960 Adacel Technologies Ltd www.adacel.com _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Jul 21 2002 - 20:09:08 PDT