Re: sleep in selinux_audit_rule_init

[Casey Schaufler <casey@schaufler-ca.com>]

On 5/22/2019 6: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.

Smack has a case where the subject label might never have been
seen by the system before, and hence can't be in any rules. This
can occur when a labeled packet comes from another host. Because
a subject with the star ("*") label is never allowed access to
anything, that is a convenient value to use. It is never used as
the subject label otherwise.

You could do something similar if there is a SELinux domain/type
that you can rely on being present. I fear that there may not be
any such element, but it wouldn't hurt (too much) too look.

>
> Mimi ??
>
>