From: Kees Cook <keescook@chromium.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
paul@paul-moore.com, casey@schaufler-ca.com, song@kernel.org,
daniel@iogearbox.net, ast@kernel.org, renauld@google.com
Subject: Re: [PATCH v4 0/5] Reduce overhead of LSMs with static calls
Date: Mon, 25 Sep 2023 15:02:10 -0700 [thread overview]
Message-ID: <202309251500.B80E2D66@keescook> (raw)
In-Reply-To: <CAGudoHHm-ofzATMdE_HU2e0voKiQnkkcL+1+F73azxNeHCvYSA@mail.gmail.com>
On Mon, Sep 25, 2023 at 10:08:39PM +0200, Mateusz Guzik wrote:
> On 9/24/23, Kees Cook <keescook@chromium.org> wrote:
> > That said, I've long advocated[1] for a way to explicitly disable LSMs
> > without affecting operational ordering. I think it would be very nice to
> > be able to boot with something like:
> >
> > lsm=!yama
> >
> > to disable Yama. Or for your case, "lsm=!tomoyo". Right now, you have to
> > figure out what the lsm list is, and then create a new one with the
> > LSM you want disabled removed from the list. i.e. with v6.2 and later
> > check the boot log, and you'll see:
> >
> > LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor
> >
> > If you wanted to boot with Yama removed, you'd then pass:
> >
> > lsm=lockdown,capability,landlock,integrity,apparmor
> >
> > As a boot param. But I think this is fragile since now any new LSMs will
> > be by-default disabled once a sysadmin overrides the "lsm" list. Note
> > that booting with "lsm.debug=1" will show even more details. See commit
> > 86ef3c735ec8 ("LSM: Better reporting of actual LSMs at boot").
> >
> > So, if a distro has no support for an LSM but they want it _available_
> > in the kernel, they should leave it built in, but remove it from the
> > "lsm=" list. That's a reasonable bug to file against a distro...
> >
>
> Maybe I once more expressed myself poorly, I meant to say stock Debian
> does not ship any tooling for tomoyo, but the kernel has support
> compiled in.
If there is no tooling Debian should either not build the support into
the kernel or should leave it out of the CONFIG_LSM list.
> Ultimately, after stacking got implemented, it was inevitable diestros
> like Debian will enable whatever modules and expect them to not be a
> problem if not configured by userspace.
>
> I don't think any form of messing with CONFIG_LSM is a viable option,
> even if you make it a boot param.
>
> What should happen instead is that modules which are not given any
> config don't get in the way.
Right -- this is an open problem, and I think we can solve it using the
static_call system (much like how the BPF LSM is doing it).
-Kees
--
Kees Cook
prev parent reply other threads:[~2023-09-25 22:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 14:55 [PATCH v4 0/5] Reduce overhead of LSMs with static calls KP Singh
2023-09-22 14:55 ` [PATCH v4 1/5] kernel: Add helper macros for loop unrolling KP Singh
2023-09-22 14:55 ` [PATCH v4 2/5] security: Count the LSMs enabled at compile time KP Singh
2023-09-22 15:50 ` Kees Cook
2023-09-22 16:07 ` KP Singh
2023-09-27 22:37 ` KP Singh
2023-09-22 14:55 ` [PATCH v4 3/5] security: Replace indirect LSM hook calls with static calls KP Singh
2023-09-23 14:52 ` kernel test robot
2023-09-27 5:26 ` kernel test robot
2023-09-22 14:55 ` [PATCH v4 4/5] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2023-09-22 14:55 ` [PATCH v4 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY KP Singh
2023-09-22 15:50 ` Kees Cook
2023-09-22 15:51 ` [PATCH v4 0/5] Reduce overhead of LSMs with static calls Kees Cook
2023-09-22 18:42 ` Mateusz Guzik
2023-09-23 16:16 ` KP Singh
2023-09-23 17:13 ` Mateusz Guzik
2023-09-23 17:15 ` Mateusz Guzik
2023-09-24 2:46 ` Kees Cook
2023-09-25 20:08 ` Mateusz Guzik
2023-09-25 22:02 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202309251500.B80E2D66@keescook \
--to=keescook@chromium.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=paul@paul-moore.com \
--cc=renauld@google.com \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.