| Message ID | 20201026125227.54520-3-a.nogikh@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | security: add fault injection to LSM hooks | expand |
2020年10月26日(月) 21:52 Aleksandr Nogikh <a.nogikh@gmail.com>: > > From: Aleksandr Nogikh <nogikh@google.com> > > Describe fail_lsm_hooks fault injection capability. > > Signed-off-by: Aleksandr Nogikh <nogikh@google.com> > --- > v2: > - Added this commit. > --- > Documentation/fault-injection/fault-injection.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst > index 31ecfe44e5b4..48705adfbc18 100644 > --- a/Documentation/fault-injection/fault-injection.rst > +++ b/Documentation/fault-injection/fault-injection.rst > @@ -48,6 +48,12 @@ Available fault injection capabilities > status code is NVME_SC_INVALID_OPCODE with no retry. The status code and > retry flag can be set via the debugfs. > > +- fail_lsm_hooks > + > + injects failures into LSM hooks. When a fault is injected, actual hooks > + are not executed and a code from /sys/kernel/debug/fail_lsm_hooks/retval > + is returned (the default value is -EACCES). In addition to this global one, what do you think about per-hook fault injection, i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ? In this case, we need a fault_attr for each hook. (Maybe, we can use the same technique that is used to define security_hook_heads).
On Tue, Oct 27, 2020 at 6:31 PM Akinobu Mita <akinobu.mita@gmail.com> wrote: > [...] > In addition to this global one, what do you think about per-hook fault > injection, > i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ? I was thinking about this, but decided to begin with a simple version that could definitely be useful in practice (for syzbot/syzkaller it is just necessary to have a fault injection capability that will be triggered via fail-nth). If per-hook fault injection can also be useful to someone, I can try to add it as well. > In this case, we need a fault_attr for each hook. (Maybe, we can use the same > technique that is used to define security_hook_heads). Yes, that technique should help to implement the feature in a very concise way. Thanks for the suggestion.
On Tue, Oct 27, 2020 at 6:34 PM Aleksandr Nogikh <nogikh@google.com> wrote: > [...] > > In addition to this global one, what do you think about per-hook fault > > injection, > > i.e. /sys/kernel/debug/fail_lsm_hooks/<FUNC>/retval ? > > I was thinking about this, but decided to begin with a simple version > that could definitely be useful in practice (for syzbot/syzkaller it is just > necessary to have a fault injection capability that will be triggered via > fail-nth). If per-hook fault injection can also be useful to someone, I > can try to add it as well. Yes, before we add it, it would be useful to have a clear use case (otherwise we can add an unused thing, or implement it in a way that slightly misses the use case). Note that fail-nth allows to fail a single concrete site for testing, though it's not super convenient for this as one would need to figure out the right N first. But as a one-off test it should do. > > In this case, we need a fault_attr for each hook. (Maybe, we can use the same > > technique that is used to define security_hook_heads). > > Yes, that technique should help to implement the feature in a very concise > way. Thanks for the suggestion.
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index 31ecfe44e5b4..48705adfbc18 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -48,6 +48,12 @@ Available fault injection capabilities status code is NVME_SC_INVALID_OPCODE with no retry. The status code and retry flag can be set via the debugfs. +- fail_lsm_hooks + + injects failures into LSM hooks. When a fault is injected, actual hooks + are not executed and a code from /sys/kernel/debug/fail_lsm_hooks/retval + is returned (the default value is -EACCES). + Configure fault-injection capabilities behavior -----------------------------------------------