Re: sleep in selinux_audit_rule_init

[Stephen Smalley <sds@tycho.nsa.gov>]

On 5/22/19 9:57 AM, Mimi Zohar wrote:
> 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.

You can just do what audit_dupe_lsm_field() does.  It effectively 
disables the rule upon the invalidation (which makes sense, since it can 
no longer match anything since nothing can have that domain/type) but 
retains the string value so it can later re-activate the rule if the 
domain/type becomes valid again later.