Stephen Smalley wrote: > On Fri, 2008-09-19 at 11:47 -0400, Joshua Brindle wrote: >> Stephen Smalley wrote: >>> On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote: >>>> Stephen Smalley wrote: >>>>> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote: >>>>>> For symbol labeling purposes for policy access control we need to be >>>>>> able to look up symbol hierarchy relationships. I expect we'll do this >>>>>> by exporting the symbol hierarchy via selinuxfs. Does anyone have >>>>>> suggestions on what that should look like? Do we want to export >>>>>> additional information on the symbols at the same time? >>>>> I would have thought that the policy server would have its own internal >>>>> policydb that it could consult to check hierarchy relationships? >>>>> >>>> We want to avoid loading more policydb's since RAM usage and >>>> performance were issues with the expand-based access control. >>> libsemanage already has to load the policydb into memory for its >>> transactions. Will this change in the future? If not, then it seems >>> that you could simply leverage that. >>> >> True, though that is currently only done when not building a policy. > > What? It constructs a policydb in memory when building a policy and > then writes it out. There is always an in-memory policydb, whether it > is just loaded from the existing policy file (via Dan's enhancement) or > generated via expand/link + merge local components. > >> For access control we will be building a policy but hope to do access >> control far before that happens (thus saving time if it is going to >> fail anyway). The rebuild code path doesn't currently open the old >> policy so adding that would double the ram usage. > > Ok. > >>> I know that at one point the trend was toward one value per file, but >>> that carries a cost of course, and I'm not sure the /selinux/class >>> interface turned out to be ideal. Maybe others have opinions. >>> >> was there anything specific about the class interface you didn't like? >> I like it in the sense that once the tree is built the policydb never >> has to be consulted. I don't think that is an option for this case >> though. >> >> I like one value per file but we are talking about a large namespace for types. > > Yes, I'm a little concerned about eating up kernel memory for all of > those pseudo inodes, most of which will never be used by userspace. > So I guess an alternative is a query interface like the others. open /selinux/bounds, write a type and get back the bounds? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
