On 9/17/2018 4:28 PM, Kees Cook wrote: > On Mon, Sep 17, 2018 at 4:26 PM, John Johansen > <john.johan...@canonical.com> wrote: >> On 09/17/2018 04:20 PM, Kees Cook wrote: >>> On Mon, Sep 17, 2018 at 4:10 PM, Mickaël Salaün <m...@digikod.net> wrote: >>>> Landlock, because it target unprivileged users, should only be called >>>> after all other major (access-control) LSMs. The admin or distro must >>>> not be able to change that order in any way. This constraint doesn't >>>> apply to current LSMs, though. >>> Good point! It will be easy to add LSM_ORDER_LAST, though, given the >>> machinery introduced in this series. >>> >> And when we have two LSMs that want to use that? > We'll cross that bridge when we come to it, but perhaps "last > exclusive"? (lsm.enable/disable to choose)
If we define restrictions on use of LSM_ORDER_LAST like we have for LSM_ORDER_FIRST (only for capabilities) before anyone starts abusing it we may be OK. Since an LSM_ORDER_LAST has to know that it can't count on getting called (a non-last module may return -EACCES) I don't see any way that having multiple LSM_ORDER_LAST modules in any given order would be a real problem. Of course, a module could be doing state management that *really* requires it be last, but that would be a badly designed module and someone sensible would NAK it.
