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
