sleep in selinux_audit_rule_init

Stephen Smalley sds at tycho.nsa.gov
Wed May 22 13:16:00 UTC 2019


On 5/22/19 9:00 AM, Mimi Zohar wrote:
> On Wed, 2019-05-22 at 08:41 -0400, Stephen Smalley wrote:
>> Another potentially worrisome aspect of the current
>> ima_lsm_update_rules() logic is that it does a BUG_ON() if the attempt
>> to update the rule fails, which could occur if e.g. one had an IMA
>> policy rule based on a given domain/type and that domain/type were
>> removed from policy (e.g. via policy module removal).  Contrast with the
>> handling in audit_dupe_lsm_field().  The existing ima_lsm_update_rules()
>> logic could also yield a BUG_ON upon transient memory allocation failure.
> 
> The original design was based on the assumption that SELinux labels
> could not be removed, only new ones could be added.  Sounds like that
> isn't the case any longer.

That's never really been the case for SELinux; it has always been 
possible to reload with a policy that renders previously valid security 
contexts invalid.  What has changed over time is the ability of SELinux 
to gracefully handle the situation where a security context is rendered 
invalid upon a policy reload and then later restored to validity via a 
subsequent policy reload (e.g. removing a policy module and then 
re-adding it), but even that deferred mapping of contexts support has 
been around since 2008.

What you are likely thinking of is the conventional practice of 
distributions, which is generally to not remove domains/types from their 
policy or to at least retain a type alias for compatibility reasons. 
But that's just a convention, not guaranteed by any mechanism, and users 
are free to remove policy modules.



More information about the Linux-security-module-archive mailing list