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. -- Stephen Smalley National Security Agency -- 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.
