On Thu, 2004-07-15 at 11:26, Kirk Vogelsang wrote: > I'm contemplating rolling my own policy.conf, using the latest strict > as a base and trimming it down and wondering if others have gone > this route as well. > > I'm well aware of the implications in doing this and moving away from > the standard m4-based config. But what seem to be trivial tasks in > modifying the policy file directly appear to become somewhat non-trivial > in trying to make the same modification in the macro files. > > For example, I wish to disallow user_r any access to selinux_config_t. > It appears as though access is granted to selinux_config_t via > via full_user_role() via base_file_read_access(). full_user_role(user) > adds quite a bit of functionality I want to keep as does > base_file_read_access(user). So I'm not quite sure where to go from > here. Removing this access from the policy.conf directly appears to > be a matter of removing one or two lines. > > Maybe I'm going about things incorrectly? Do other's write and maintain > their own policies independent of the policy*.rpm's? You could make an argument for removing that rule from base_file_read_access(), optionally replacing it with a dontaudit rule. Since libselinux attempts to set up the policy paths via a constructor, every program that links with it ends up triggering an attempt to read /etc/selinux/config, even if that program never truly accesses a policy file. Hence, many audit messages related to /etc/selinux/config are harmless, and any program that does need to access a policy file will ultimately need access to one of the other types (default_context_t, policy_config_t, or policy_src_t) as well as selinux_config_t. Even if you were to maintain this as your own custom policy, I think you likely need to do more than just remove rules between user_t and selinux_config_t, as there may be program domains reachable by user_t that could be used to indirectly read it, particularly if you don't remove the rule from the base_file_read_access() macro itself. Of course, the information in /etc/selinux/config is straightforward to infer anyway; it isn't difficult to determine that you are on a SELinux enforcing system and what kind of policy you are running. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
