linux-kernel - Re: [PATCH v1 0/2] Add destructor hook to LSM modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRFQtqTZku==BkW0uz1oZgG63j15GoQD1iexW4aPoAPcA@mail.gmail.com>
Date:   Sat, 11 Mar 2023 09:59:17 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Mirsad Goran Todorovac <mirsad.todorovac@....unizg.hr>
Cc:     Mirsad Goran Todorovac <mirsad.goran.todorovac@....hr>,
        linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Christian Göttsche <cgzones@...glemail.com>,
        Mickaël Salaün <mic@...ikod.net>,
        Frederick Lawler <fred@...udflare.com>
Subject: Re: [PATCH v1 0/2] Add destructor hook to LSM modules

On Fri, Mar 10, 2023 at 5:53 PM Mirsad Goran Todorovac
<mirsad.todorovac@....unizg.hr> wrote:
> On 10. 03. 2023. 23:33, Paul Moore wrote:
> > On Fri, Mar 10, 2023 at 2:26 PM Mirsad Goran Todorovac
> > <mirsad.goran.todorovac@....hr> wrote:
> >>
> >> LSM security/integrity/iint.c had the case of kmem_cache_create() w/o a proper
> >> kmem_cache_destroy() destructor.
> >>
> >> Introducing the release() hook would enable LSMs to release allocated resources
> >> on exit, and in proper order, rather than dying all together with kernel shutdown
> >> in an undefined order.
> >>
> >> Thanks,
> >>         Mirsad
> >>
> >> ---
> >>  include/linux/lsm_hooks.h | 1 +
> >>  security/integrity/iint.c | 7 +++++++
> >>  2 files changed, 8 insertions(+)
> >
> > I only see the 1/2 patch, did you send the 2/2 patch to the LSM list?
> > If not, you need to do that
>
> I will resend everything, because this first attempt was buggy and
> incorrect regarding the credits. Will try this, Andy said that I wait
> for the comments, but I did not expect them before the weekend.
>
> Thank you guys for patience, I am just finishing the test of devres
> patch and then I will proceed with integrity LSM patch submission.

Thank you for resending the patchset, although a couple of
administrative things to consider for your next posting:

* Each time you post a patchset it is generally considered a best
practice to increment the version number, e.g. "[PATCH vX 0/2]" with
'X' being the version number.  This makes it easier to identify
specific revisions and ensure that everyone is reviewing the latest
patchset.

* It is a good idea to use the "./scripts/get_maintainer.pl" script to
ensure you have included the right people and mailing lists on your
submissions as your latest resend did not include the LSM list when it
should have.

With that out of the way, I wanted to make a quick comment on the
patch itself.  Currently LSMs do not support unloading, or dynamic
loading for that matter.  There are several reasons for this, but
perhaps the most important is that in order to help meet the security
goals for several of the LSMs they need to be present in the kernel
from the very beginning and remain until the very end.  Adding a
proper "release" method to a LSM is going to be far more complicated
than what you've done with this patchset, involving a lot of
discussion both for the LSM layer itself and all of the currently
supported LSMs, and ultimately I don't believe it is something we will
want to support.

I appreciate your desire to help, and I want to thank you for your
patch and the effort behind it, but I don't believe the kobject memory
leak you saw at kernel shutdown was a real issue (it was only "leaked"
because the system was shutting down) and I'm not sure the current
behavior is something we want to change in the near future.

--
paul-moore.com