On Wed, Apr 23, 2008 at 12:30:42PM +0200, Václav Ovsík wrote: ... > Thanks for the exhaustive explanation Christopher. It seemed to me, that > your idea can be done at least for types (a roleattribute keyword not > exist yet), but I was wrong about attributes :(. Attribute can't have > attribute (recursively). With an attached nonfunctional patch I ended > with: > > /usr/bin/checkmodule -M -m tmp/apt.tmp -o tmp/apt.mod > /usr/bin/checkmodule: loading policy configuration from tmp/apt.tmp > policy/modules/admin/apt.te":135:ERROR 'unknown type dpkg_inherited_fd' at token ';' on line 7686: > typeattribute dpkg_inherited_fd apt_inherited_fd; > #line 135 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/apt.mod] Error 1 > > Of course dpkg_inherited_fd is the attribute and not the type, shame. > You are right, with current policy language this can't be done easily. > > Maybe wee can do this job using m4. This would require an additional > pass to process sources or modification of processing a bit. My rough > idea for modular policy: > * To include the third new parameter of interface/template macro > used by run interfaces. This parameter will accept what and how > should be inherited in some notation parse able fine by m4. The > information "what" should describe the class (fd, pipe...), the > type. The information "how" should describe passing down (to pass > inheritance down or to stop inheritance there). > * To split module preprocessing (m4) and compilation (checkmodule) > (Rules.modular). > * All modules must by m4 processed at first to create the > meta-information about all inheritances. The compilation > (checkmodule) of any module (with some run interface) should > depend on meta-information from all other packages. > * Updating of inheritance meta-information must be updated only when > the content is really different, so Make will not restart > rebuilding things unnecessarily. > * To build allow rules from inheritance meta-information and append > this rules to already preprocessed .te product and compile it by > checkmodule. ... I see at least one flaw - the policy build in such a way will be somewhat "static" concerning adding modules into pre-build policy. That is when someone will take policy headers and compile an own local module, then all other pre-build modules affected by inheritance will be obsolete. So, there is no improvement in this area against current state. The only benefit from the proposal is, that policy sources will be a bit more clean (I hope) and ready for introducing inheritance in the policy language (I hope only macros and processing will need change). Best Regards -- Zito -- 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.
