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(a)epoch.ncsc.mil>
National Security Agency