All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: ebiggers@kernel.org,
	James Morris James Morris <jmorris@namei.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Peter Huewe <peterhuewe@gmx.de>,
	David Howells <dhowells@redhat.com>,
	keyrings@vger.kernel.org,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH RESEND] KEYS: fix parsing invalid pkey info string
Date: Tue, 18 Dec 2018 00:44:22 +0000	[thread overview]
Message-ID: <1545093862.2878.34.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAHk-=wjPhKNKRq24wXL3wvqUgfyriDjYNXUPCumbH=64ZMXrSw@mail.gmail.com>

On Mon, 2018-12-17 at 12:02 -0800, Linus Torvalds wrote:
> On Mon, Dec 17, 2018 at 11:51 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > If this is to replace Eric's patch, didn't you want to set
> > token_mask to (1<<Opt_err)?
> 
> No, let's not add any extra code that is trying to be subtle. Subtle
> interactions was where the bug came from.

Sure; I suppose liking the TPM gives me a taste for subtlety.

> The code already checks the actual Opt_xyz for errors in a switch
> statement. The token_mask should be _purely_ about duplicate options
> (or conflicting ones).
> 
> Talking about the conflicting ones: Opt_hash checks that
> Opt_policydigest isn't set. But Opt_policydigest doesn't check that
> Opt_hash isn't set, so you can mix the two if you just do it in the
> right order.
>
> But that's a separate bug, and doesn't seem to be a huge deal.

Actually, I'm afraid it's not a bug, it's a command line ordering
thing.  To check the policy digest length, we need to know which hash
algorithm you're using, so if you're specifying a hash algorithm, it
has to appear *before* a policydigest as a command input.

I take it this is another subtlety you'd like documenting ...?

> But it *is* an example of how bogus all of this stuff is. Clearly
> people weren't really paying attention when writing any of this code.

Hey, not going to argue here.  The whole policy session passed in is
questionable because some of the actions the kernel takes on the key
have to depend on what was in the policy (which you don't know and
can't deduce from the hash).  The only way to get it to work
universally is to pass the actual policy in and have the kernel
construct the policy session itself.  Fortunately fixing it can be low
priority because we don't seem to have any users.

James

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: ebiggers@kernel.org,
	James Morris James Morris <jmorris@namei.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Peter Huewe <peterhuewe@gmx.de>,
	David Howells <dhowells@redhat.com>,
	keyrings@vger.kernel.org,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH RESEND] KEYS: fix parsing invalid pkey info string
Date: Mon, 17 Dec 2018 16:44:22 -0800	[thread overview]
Message-ID: <1545093862.2878.34.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAHk-=wjPhKNKRq24wXL3wvqUgfyriDjYNXUPCumbH=64ZMXrSw@mail.gmail.com>

On Mon, 2018-12-17 at 12:02 -0800, Linus Torvalds wrote:
> On Mon, Dec 17, 2018 at 11:51 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > If this is to replace Eric's patch, didn't you want to set
> > token_mask to (1<<Opt_err)?
> 
> No, let's not add any extra code that is trying to be subtle. Subtle
> interactions was where the bug came from.

Sure; I suppose liking the TPM gives me a taste for subtlety.

> The code already checks the actual Opt_xyz for errors in a switch
> statement. The token_mask should be _purely_ about duplicate options
> (or conflicting ones).
> 
> Talking about the conflicting ones: Opt_hash checks that
> Opt_policydigest isn't set. But Opt_policydigest doesn't check that
> Opt_hash isn't set, so you can mix the two if you just do it in the
> right order.
>
> But that's a separate bug, and doesn't seem to be a huge deal.

Actually, I'm afraid it's not a bug, it's a command line ordering
thing.  To check the policy digest length, we need to know which hash
algorithm you're using, so if you're specifying a hash algorithm, it
has to appear *before* a policydigest as a command input.

I take it this is another subtlety you'd like documenting ...?

> But it *is* an example of how bogus all of this stuff is. Clearly
> people weren't really paying attention when writing any of this code.

Hey, not going to argue here.  The whole policy session passed in is
questionable because some of the actions the kernel takes on the key
have to depend on what was in the policy (which you don't know and
can't deduce from the hash).  The only way to get it to work
universally is to pass the actual policy in and have the kernel
construct the policy session itself.  Fortunately fixing it can be low
priority because we don't seem to have any users.

James


  parent reply	other threads:[~2018-12-18  0:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-03 15:48 general protection fault in keyctl_pkey_params_get syzbot
2018-11-03 15:48 ` syzbot
2018-11-03 17:30 ` [PATCH] KEYS: fix parsing invalid pkey info string Eric Biggers
2018-11-03 17:30   ` Eric Biggers
2018-11-28 23:20   ` Eric Biggers
2018-11-28 23:20     ` Eric Biggers
2018-12-06 18:26     ` Eric Biggers
2018-12-06 18:26       ` Eric Biggers
2018-12-17 18:12     ` [PATCH RESEND] " Eric Biggers
2018-12-17 18:12       ` Eric Biggers
2018-12-17 18:43       ` Linus Torvalds
2018-12-17 18:43         ` Linus Torvalds
2018-12-17 18:49         ` Linus Torvalds
2018-12-17 18:49           ` Linus Torvalds
2018-12-17 19:06           ` Linus Torvalds
2018-12-17 19:06             ` Linus Torvalds
2018-12-17 19:39             ` Linus Torvalds
2018-12-17 19:39               ` Linus Torvalds
2018-12-17 19:51               ` James Bottomley
2018-12-17 19:51                 ` James Bottomley
2018-12-17 20:02                 ` Linus Torvalds
2018-12-17 20:02                   ` Linus Torvalds
2018-12-17 20:29                   ` Mimi Zohar
2018-12-17 20:29                     ` Mimi Zohar
2018-12-18  0:44                   ` James Bottomley [this message]
2018-12-18  0:44                     ` James Bottomley
2018-12-31 22:45                   ` Eric Biggers
2018-12-31 22:45                     ` Eric Biggers
2019-01-01 21:08                     ` Linus Torvalds
2019-01-01 21:08                       ` Linus Torvalds
2018-12-17 20:21             ` Mimi Zohar
2018-12-17 20:21               ` Mimi Zohar
2018-12-17 20:31               ` Linus Torvalds
2018-12-17 20:31                 ` Linus Torvalds
2018-12-18 12:34         ` Dmitry Vyukov
2018-12-18 12:34           ` Dmitry Vyukov

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=1545093862.2878.34.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zohar@linux.vnet.ibm.com \
    /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.