linux-kernel - Re: [RFC PATCH v2 1/2] security: add fault injection capability

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: <c55336e4-dd4f-3a72-e22f-aaf9c305d57f@schaufler-ca.com>
Date:   Tue, 27 Oct 2020 10:56:11 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     Aleksandr Nogikh <a.nogikh@...il.com>, jmorris@...ei.org,
        serge@...lyn.com, akinobu.mita@...il.com,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Marco Elver <elver@...gle.com>, glider@...gle.com,
        keescook@...gle.com, LKML <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [RFC PATCH v2 1/2] security: add fault injection capability

On 10/27/2020 10:29 AM, Aleksandr Nogikh wrote:
> (resending the previous message in a plain/text mode)
>
> On Mon, Oct 26, 2020 at 7:20 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
> [...]
>>> -     int RC = IRC;                                           \
>>> -     do {                                                    \
>>> +     int RC = lsm_hooks_inject_fail();                       \
>>> +     if (RC == 0) {                                                          \
>> Injecting the failure here will prevent the loaded LSM hooks from
>> being called.
> In this RFC, fault injection was intentionally placed before the code that
> invokes LSM hooks. The reasoning was that it would simultaneously check
> how the kernel code reacts to LSM denials and the effect of fault injections
> on LSM modules.
>
>>>               struct security_hook_list *P;                   \
>>> +             RC = IRC;                                                               \
>>>                                                               \
>>>               hlist_for_each_entry(P, &security_hook_heads.FUNC, list) { \
>>>                       RC = P->hook.FUNC(__VA_ARGS__);         \
>>>                       if (RC != 0)                            \
>>>                               break;                          \
>>>               }                                               \
>>> -     } while (0);                                            \
>>> +     }                                                       \
>> Injecting the failure here would allow the loaded LSM hooks to
>> be called. It shouldn't make a difference, but hooks with side-effects
>> are always possible. I don't have an issue either way.
>>
>>>       RC;                                                     \
>>>  })
>>>
> Should we expect LSM modules to properly handle the cases when their
> hooks with side effects were not invoked (unlike the selinux crash that
> is described in the cover letter)? From the source code it seems that a
> failure/denial from one module prevents the execution of the subsequent
> hooks, so this looks like a realistic scenario.

Yes. Security modules have to accept the possibility that something
ahead of them in the stack will fail. This may be a DAC check, a
capability check or another security module.

> If that is not true in general and depends on the specific active modules,
> then it probably makes sense to introduce an option to control whether to
> inject faults at the beginning of call_int_hook() or after the hooks have
> been invoked.

If you want to do that you could implement it as an LSM. You could place it
anywhere in the stack that way. Based on what I see with the BPF lsm that might
be more work than it is worth.