linux-kernel - Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs

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: <8c8dd781-d30a-7105-011d-127cf5188426@schaufler-ca.com>
Date:   Wed, 29 Nov 2017 18:28:25 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Sargun Dhillon <sargun@...gun.me>,
        linux-security-module@...r.kernel.org
Cc:     keescook@...omium.org, igor.stoppa@...wei.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs

On 11/26/2017 2:15 PM, Sargun Dhillon wrote:
> This patchset introduces safe dynamic LSM support. It does this via
> SRCU-protected security hooks. It also EXPORT_SYMBOL_GPLs the symbols
> required to perform runtime loading, and unloading. The patchset is
> meant to introduce as little overhead as possible when not used.
> Additionally, the functionality is disabled by default.

Can you explain the value in being able to unload a security module?
I can see having a throttle on an active module, but what do you gain
by being able to unload it? Can it possibly be worth the inevitable
memory leaks and almost certain dangling pointers? The restrictions on
a security module that can work safely in this environment are significant.
I don't see any point in unloading a module that could work with those
restrictions. The overhead of making it unloadable is likely to exceed
the overhead of running it.

>
> The SRCU was made safe to call from an interrupt context in the patch
> "srcu: Allow use of Classic SRCU from both process and interrupt context"
> (1123a6041654e8f889014659593bad4168e542c2) by Paolo Bonzini. Therefore
> this mechanism is safe to use for traversal of the callback list,
> even when a hook is called from the interrupt context.
>
> Currently, this maintains an entirely seperate mechanism to attach hooks
> because the hooks are behind managed static_keys to prevent overhead.
> This is also done so sealable memory support could be added at a later
> point. The callbacks currently include a percpu_counter, but that could
> sit outside of the struct itself. This may also have a benefit that these
> counters, could have __cacheline_aligned_in_smp. Although, in my testing
> I was unable to find much performance delta with percpu_counters that
> were not aligned.
>
> It includes an example LSM that prevents specific time travel.

Time based controls (e.g. you can't execute files in /usr/games between
8:00 and 17:00) would be cool. I suggested them in the 1980's, but
no one has gotten around to implementing them. :)

>
> Sargun Dhillon (3):
>   security: Add safe, dynamic (runtime-loadable) hook support
>   LSM: Add statistics about the invocation of dynamic hooks
>   LSM: Add an example sample dynamic LSM
>
>  include/linux/lsm_hooks.h | 254 +++++++++++++++++++++++++++++++++++++
>  samples/Kconfig           |   6 +
>  samples/Makefile          |   2 +-
>  samples/lsm/Makefile      |   4 +
>  samples/lsm/lsm_example.c |  46 +++++++
>  security/Kconfig          |  16 +++
>  security/Makefile         |   2 +
>  security/dynamic.c        | 316 ++++++++++++++++++++++++++++++++++++++++++++++
>  security/dynamic.h        |  33 +++++
>  security/dynamicfs.c      | 118 +++++++++++++++++
>  security/inode.c          |   2 +
>  security/security.c       |  66 +++++++++-
>  12 files changed, 863 insertions(+), 2 deletions(-)
>  create mode 100644 samples/lsm/Makefile
>  create mode 100644 samples/lsm/lsm_example.c
>  create mode 100644 security/dynamic.c
>  create mode 100644 security/dynamic.h
>  create mode 100644 security/dynamicfs.c
>