linux-kernel - Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key

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: <ZxKS57wBfgBZ21_g@farprobe>
Date: Fri, 18 Oct 2024 12:55:03 -0400
From: Ben Boeckel <me@...boeckel.net>
To: Eric Snowberg <eric.snowberg@...cle.com>
Cc: "open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Ard Biesheuvel <ardb@...nel.org>,	Jarkko Sakkinen <jarkko@...nel.org>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,	Mimi Zohar <zohar@...ux.ibm.com>,
	Roberto Sassu <roberto.sassu@...wei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Mickaël Salaün <mic@...ikod.net>,
	"casey@...aufler-ca.com" <casey@...aufler-ca.com>,
	Stefan Berger <stefanb@...ux.ibm.com>,
	"ebiggers@...nel.org" <ebiggers@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	open list <linux-kernel@...r.kernel.org>,
	"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called
 clavis_key_acl

On Fri, Oct 18, 2024 at 15:42:15 +0000, Eric Snowberg wrote:
> > On Oct 17, 2024, at 11:21 PM, Ben Boeckel <me@...boeckel.net> wrote:
> > Can this be committed to `Documentation/` and not just the Git history
> > please?
> 
> This is documented, but it doesn't come in until the 8th patch in the series. 
> Hopefully that is not an issue.

Ah, I'll look there, thanks.

> >> + if (isspace(desc[i]))
> >> + desc[i] = 0;
> > 
> > How is setting a space to `0` *removing* it? Surely the `isxdigit` check
> > internally is going to reject this. Perhaps you meant to have two
> > indices into `desc`, one read and one write and to stall the write index
> > as long as we're reading whitespace?
> > 
> > Also, that whitespace is stripped is a userspace-relevant detail that
> > should be documented.
> 
> This was done incase the end-user has a trailing carriage return at the
> end of their ACL. I have updated the comment as follows:
> 
> +       /*
> +        * Copy the user supplied contents, if uppercase is used, convert it to
> +        * lowercase.  Also if the end of the ACL contains any whitespace, strip
> +        * it out.
> +        */

Well, this doesn't check the end for whitespace; any internal whitespace
will terminate the key:

    DEAD BEEF
        ^ becomes NUL

and results in the same thing as `DEAD` being passed.

> > 
> >> +static void key_acl_destroy(struct key *key)
> >> +{
> >> + /* It should not be possible to get here */
> >> + pr_info("destroy clavis_key_acl denied\n");
> >> +}
> >> +
> >> +static void key_acl_revoke(struct key *key)
> >> +{
> >> + /* It should not be possible to get here */
> >> + pr_info("revoke clavis_key_acl denied\n");
> >> +}
> > 
> > These keys cannot be destroyed or revoked? This seems…novel to me. What
> > if there's a timeout on the key? If such keys are immortal, timeouts
> > should also be refused?
> 
> All the system kernel keyrings work this way. But now that you bring this up, neither of
> these functions are really necessary, so I will remove them in the next round.
> 
> >> +static int key_acl_vet_description(const char *desc)
> >> +{
> >> + int i, desc_len;
> >> + s16 ktype;
> >> +
> >> + if (!desc)
> >> + goto invalid;
> >> +
> >> + desc_len = sizeof(desc);
> > 
> > This should be `strlen`, no?
> 
> I will change this to strlen

Actually, this could probably be `strnlen` using `CLAVIS_ASCII_KID_MAX +
1` just to avoid running off into la-la land when we're going to error
anyways. Or even `8` because we only actually care about "is at least 7
bytes". Worth a comment either way.

Looking forward to the next cycle.

Thanks,

--Ben