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?
Thanx for and insight...
----- Kirk M. Vogelsang kvogelsa@ccs.neu.edu Northeastern University College of Computer Science
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.
selinux@lists.fedoraproject.org