RFC: New LSM to control usage of x509 certificates
Paul Moore
paul at paul-moore.com
Thu Oct 5 14:05:25 UTC 2023
On Thu, Oct 5, 2023 at 6:32 AM Mickaël Salaün <mic at digikod.net> wrote:
>
> The initial subject was "Re: [PATCH] certs: Restrict blacklist updates
> to the secondary trusted keyring":
> https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@oracle.com/
>
> On Thu, Sep 14, 2023 at 10:34:44AM +0200, Mickaël Salaün wrote:
> > CCing the LSM mailing list for this potential new LSM proposal:
> > On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> > > > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic at digikod.net> wrote:
> > > > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> > > >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar at linux.ibm.com> wrote:
[Just a reminder that trimming massive emails to the relevant portions
is a nice thing to do]
> > > > A complementary approach would be to create an
> > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > kernel usages, while still letting users configure these constraints.
> > >
> > > That is an interesting idea. Would the other security maintainers be in
> > > support of such an approach? Would a LSM be the correct interface?
> > > Some of the recent work I have done with introducing key usage and CA
> > > enforcement is difficult for a distro to pick up, since these changes can be
> > > viewed as a regression. Each end-user has different signing procedures
> > > and policies, so making something work for everyone is difficult. Letting the
> > > user configure these constraints would solve this problem.
I can't say that I have been following this thread very closely, but I
see no reason why we wouldn't support a LSM that enforces access
controls on certificates/keys based on their attributes/properties.
We do have some LSM control points for the kernel keyring, which are
used by at least one LSM, but I'm sure you would probably need some
additional control points.
If you are interested in pursuing the creation of a new LSM, and
likely new LSM hooks, we do have some documented guidelines you should
keep in mind:
* https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list