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