Policy Management
Stephen Smalley
sds at epoch.ncsc.mil
Thu Jul 15 18:12:47 UTC 2004
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 at epoch.ncsc.mil>
National Security Agency
More information about the selinux
mailing list