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
