Until now, I was using pathnames listed in /etc/ld.so.cache without using wildcards. This approach requires updating pathnames listed in /proc/ccs/exception_policy whenever pathnames listed in /etc/ld.so.cache changes. ccs-ld-watch and ccs-queryd are provided for monitoring changes in /etc/ld.so.cache .
But this approach generates many entries. For example, http://sourceforge.jp/projects/tomoyo/svn/view/tags/htdocs/1.8/editpolicy-exception-full.png?view=markup&revision=3975&root=tomoyo has 467 entries. Also, by introducing "acl_group" directive, the entries will be multiplied by number of groups defined. That is, 467x256=119552 entries if 256 groups are defined. This is not manageable. Therefore, I decided to use pathname listed in /etc/ld.so.cache with wildcards. This approach generates much less entries. For example, http://sourceforge.jp/projects/tomoyo/svn/view/tags/htdocs/1.8/editpolicy-exception-full.png?view=markup&revision=3981&root=tomoyo has only 25 entries. This approach does not require updating pathnames listed in /proc/ccs/exception_policy as long as updated pathnames listed in /etc/ld.so.cache are covered by wildcards. Therefore, I removed functionality for monitoring changes in /etc/ld.so.cache from ccs-queryd . Well, 216 "file_pattern" entries in the pictures above may be too many. "file_pattern" is used for saving administrator's time for manually converting "requested pathnames" to "patterned pathnames" when the domain policy for file related operations is generated using "learning mode". But "file_pattern" are always incomplete because it depend on distributions and applications and configuration. If converting "requested pathname" to "patterned pathname" is done outside the kernel, we can remove "file_pattern" entries from /proc/ccs/exception_policy . I think I can make "learning mode" to send access logs to the userspace daemon if the userspace daemon is available (and the userspace daemon converts to "patterned pathnames" and appends to domain policy), to append to domain policy without converting to "patterned pathnames" if the userspace daemon is not available. Advantage of this approach is that we can do more complicated things (e.g. adding conditional part like "task.uid=0") in addition to converting to "patterned pathnames" before adding to domain policy. Disadvantage of this approach is that "learning mode" will become slower as the kernel will send it to the userspace daemon and waits response from the daemon. But "learning mode" becomes slow only when domain policy did not match the requested access. "learning mode" does not become slow if domain policy matched the requested access. It is similar to what /usr/sbin/ccs-queryd is doing. Another disadvantage of this approach is that pathnames in the domain policy will not be converted to "patterned pathnames" if the userspace daemon is not available (e.g. after "killall5" is executed during the shutdown sequence, userspace daemon cannot be executed by some reason). But "file_pattern" is nothing for saving administrator's time for manually converting "requested pathnames" to "patterned pathnames". The administrator can manually do it later. I think it is worth bringing "file_pattern" conversion to outside the kernel. What do you think? _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
