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. 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. >>> In any event, if we were to export such info via selinuxfs, then yes, >>> we'd want to also export other information about the symbols, such as >>> the user role and level authorizations, so that that information could >>> be used by libselinux and we could ultimately deprecate /selinux/user >>> aka security_compute_user(). >>> >> So, something like >> /selinux/symbols/types/httpd_cgi_t >> bounds: httpd_t >> >> /selinux/symbols/users/user_u >> bounds: staff_u >> roles: user_r >> levels: s0-s0:c0.c128 >> >> ? >> >> or maybe >> >> /selinux/symbols/users/user_u/roles >> user_r >> >> /selinux/symbols/users/user_u/bounds >> staff_u > > 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. -- 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.
