G’day, I would really appreciate some advice.
I realise the kernel has a small stack, and I imagine this will have a greater impact on my LSM design than I originally thought. I would really appreciate some input.
My LSM has a hierarchical policy structure which is made up of a (relatively) complex relationship of structs. A network of structs represents policy and when a task is executed a tree of structs is extracted and duplicated from this structure to create the task’s policy (this separate tree is required for other reasons).
I have written a user-space program which reads in policy and creates the hierarchical policy structure. I was going to feed this policy into the LSM via a securityfs and move the code which creates the policy structure into the LSM; so that the entire system policy is represented within the LSM. Then when a task is executed the LSM just makes the tree which represents the task’s security context and associates it with the task.
My concern is that the whole hierarchical policy structure will be loaded into kernel space and I do not really know if there will be enough memory for it. Does this seem to be a problem?
Would I be better off keeping the system-wide hierarchical policy structure in user space and only somehow creating the task tree in the LSM? This would require the LSM to pull information from user-space (when a binary is executed) which seems to be a no-no.
I also have a related question: my policy includes the option to specify allowed one-way-hashes (such as SHA-1) of a binary. How can I (and am I allowed to) pull this information (the hash of a specified binary) from my user-space daemon? (the simplest way I can think of is to have the user-space program monitor a securityfs file for changes - but this could be a very slow way)
Thanks again, Cliffe. - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
