On Tue, 2007-08-07 at 16:11 +0800, Cliffe wrote: > 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?
Don't confuse kernel stack limitation with the ability to dynamically allocate memory in the kernel. How large is your policy? I'm guessing that SELinux reference policy is larger, e.g. from /proc/slabinfo: # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <nodeallocs> <remotefrees> <alienoverflow> : cpustat <allochit> <allocmiss> <freehit> <freemiss> avtab_node 261133 261188 40 92 1 : tunables 32 16 8 : slabdata 2839 2839 0 : globalstat 261144 261144 2839 0 0 0 0 0 0 : cpustat 244102 17031 0 0 > 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 -- Stephen Smalley National Security Agency - 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