Re: Policy Management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux