sleep in selinux_audit_rule_init

[Mimi Zohar]

On Wed, 2019-05-22 at 09:16 -0400, Stephen Smalley wrote:
> 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.

Ok.  The question is then how should IMA handle missing domains/types.
 Just dropping IMA policy rules doesn't sound safe, nor does skipping
rules in case the domains/types are restored.

Mimi