Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Eric Snowberg <eric.snowberg@oracle.com>
To:     jarkko Sakkinen <jarkko@kernel.org>,
        Mimi Zohar <zohar@linux.ibm.com>,
        Elaine Palmer <erpalmerny@gmail.com>
CC:     Coiby Xu <coxu@redhat.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        David Howells <dhowells@redhat.com>,
        "dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "jmorris@namei.org" <jmorris@namei.org>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>,
        Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
        "pvorel@suse.cz" <pvorel@suse.cz>,
        Roberto Sassu <roberto.sassu@huawei.com>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "tiwai@suse.de" <tiwai@suse.de>, Mimi Zohar <zohar@linux.ibm.com>,
        "erpalmer@linux.ibm.com" <erpalmer@linux.ibm.com>
Subject: Re: [PATCH 0/7] Add CA enforcement keyring restrictions
Thread-Topic: [PATCH 0/7] Add CA enforcement keyring restrictions
Thread-Index: AQHYSVko0FaTAwO/wkyht4hUdft6wK4wDb+AgAcTfACAANo0gA==
Date:   Wed, 9 Nov 2022 14:25:08 +0000
Message-ID: <82E1339C-629A-48F5-99B0-179251BBC708@oracle.com>
References: <20221104132035.rmavewmeo6ceyjou@Rk>
 <faa10c58-268f-ddc8-b86c-02c903e29f8a@gmail.com>
In-Reply-To: <faa10c58-268f-ddc8-b86c-02c903e29f8a@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?sUAZw6HDK3Sc2aThlKQ1qcF/uVI9fhvjf3hsUCI5w1FvsKRTNRozdH6m4Spr?=
 =?us-ascii?Q?HsZugfHks9qsAlBqdFVLnCCNbPuhYW+3E12VlkLcDNJnVTfvxyFK0BRB5S3u?=
 =?us-ascii?Q?NG+ZkXrctpPu1S8MxdoEd4/gw1MCFbrF8xLLOPb7eGJ/nAJSX2Of8sGme40Q?=
 =?us-ascii?Q?l2E3iXuXDiEomc2hfs5eqUssebRV8qkfl4dg3gGyUug0LztlorW4DXu/ppR7?=
 =?us-ascii?Q?RIb/3RzrMTqYrMnioAP+tipjeWlbgMoI5s8ojmfHE2bM5UpRrWDONfgPPupy?=
 =?us-ascii?Q?2zT4nu21+xvBggDGxQEfHpEcHpNw56NMDV5UeNLxouftR2I6Vc+1vDKwVeRk?=
 =?us-ascii?Q?eciq3d+ONKPPui6jgCxrMtXlNkLlcZmrtQ/dLK4YaO6nutT0a3RuhZYw4OVk?=
 =?us-ascii?Q?e1FkScyUBXLP1Kjp5StOpXioTF9dUtrOqPRDIq+lfD8DRt58RNidjZgSe5Jb?=
 =?us-ascii?Q?joGLkdKPEt0WMWoW7QFYxBeDYWihmlAKMbaHzVmlzxT8Op7KCSoHWBFLsZeo?=
 =?us-ascii?Q?r7ZwRCcJHRSNGJQ5JwX77CGanzf2qQZ/0QT8FCir2AWEzGeY2p3SKlsLuNQY?=
 =?us-ascii?Q?AnoqUF0SzTWCZAJHjNXlqg1vHRX5RHVXCo+1Sz68Fs70eSA0R46RgZJMbyrm?=
 =?us-ascii?Q?QIYYfTBg5+k5PQfyIVNgGJPG1A3MLA2vxnIh0c2UadYtSntlI0WiIENT39vA?=
 =?us-ascii?Q?nepn0PQodwmpzNVPe8h5PJ4Dbj6fxH439GQ7rngdag4S0mg65qmV/7fp7HTe?=
 =?us-ascii?Q?gnb4qMxCqtRfwiMqOzF81AUtrvFDfR2JUsDXC2hqeRepIqcqyDCLDKeUEdUd?=
 =?us-ascii?Q?AGuMJN2WsVszghd7Bpfx9XDrM9CZLiZel+JpK8iKkvWtOouwiVolbPO6NaIK?=
 =?us-ascii?Q?wnB1dxtK4km0wuFbxI/SZe7NjjtE+LbxPAFlINtW3RLr0Crd4OrQtGVzZcbM?=
 =?us-ascii?Q?CsR9jgdr03xD7XEE4zsYpB0RuJddJyS3Z23T3M877wt5RGMDpgdRAhxHPWSU?=
 =?us-ascii?Q?ZVDLwhuIMpuk9KUkNYDBCgVB0y52q5npOvpOk12VZaSJIyUNT6nelJWnm5WM?=
 =?us-ascii?Q?FO3DVrCGTFu56UArVTlJTLjec2nRxTGAIJqCk4N84QIHzIsY3+kINbml2i8T?=
 =?us-ascii?Q?l1bNLEUWKiVX13j6XjUbn4W5qs2aWe/mWuBsyb175My7TxJu/4pIHjASBZmI?=
 =?us-ascii?Q?EUvCU2Ax9nzbPP+vvNOEYWage0Uj5fmP4FWWPRBILaAYyDThRW4WKsPW22n6?=
 =?us-ascii?Q?yMGl5E5PUKui8Vo1mK6FZpnXaSRZseEM0KrzlM7Qrwff8V2/e8nJYGxmGZfW?=
 =?us-ascii?Q?3UvL8BQtNjy8VmrWwSW00cSuQA3s2gbK8Clvs/Lt0xmjuKJZi88fni9xzQGp?=
 =?us-ascii?Q?CYxBvGCXcCQFTWSY5tHFRTiGNyaa79wC44aCW7L7XSWNKJyJ48YeUXvxa73i?=
 =?us-ascii?Q?lzZqEmhpCKebzvvtUQg4ReMbgyV+MYJrrfWfRPpFqPSxoqzSGVSITSnHe7wU?=
 =?us-ascii?Q?5ieflFLw3YOlE8m/zqM8A2ePYgmmnuuUdjdzJCGvOQZSqZ9j7bpBC7caOtQX?=
 =?us-ascii?Q?vat3QT/v6A34Dwz1BPcgY3ov6ZbOn4XVy8IFs7wue4a6Ibe0VZk3VFJY//CJ?=
 =?us-ascii?Q?xA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <673C1B12C9174D41B38B284AEC400DFC@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4150.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4964cbc-5d92-417a-ba3b-08dac25e3412
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2022 14:25:08.1922
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: w0c1XlqLYj3vnWprxBIkFuKH1lpXzOHTgXSeq6UyYvml3KxtqaEsdsOIEc7dEu1/S7FZtPFMoqmP2btRWenOiulMeneUqehpQc7mCrqMVys=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR10MB6891
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-09_06,2022-11-09_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 mlxscore=0
 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211090109
X-Proofpoint-GUID: 9NcdyLlx8fyxS9OG2QM5Zie64_0qqpk7
X-Proofpoint-ORIG-GUID: 9NcdyLlx8fyxS9OG2QM5Zie64_0qqpk7
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Nov 8, 2022, at 6:24 PM, Elaine Palmer <erpalmerny@gmail.com> wrote:
>=20
>=20
>=20
> On 2022/11/04 9:20 AM, Coiby Xu wrote:
>> Hi Eric,
>>=20
>> I wonder if there is any update on this work? I would be glad to do
>> anything that may be helpful including testing a new version of code.
>>=20
> Hi Coiby,
>=20
> Yes, this discussion got stuck when we couldn't agree on one of the
> following options:
>=20
> (A) Filter which keys from MOK (or a management system) are loaded
>     onto the .machine keyring. Specifically, load only keys with
>     CA+keyCertSign attributes.
>=20
> (B) Load all keys from MOK (or a management system) onto the
>     .machine keyring. Then, subsequently filter those to restrict
>     which ones can be loaded onto the .ima keyring specifically.
>=20
> The objection to (A) was that distros would have to go through
> two steps instead of one to load keys. The one-step method of
> loading keys was supported by an out-of-tree patch and then by
> the addition of the .machine keyring.
>=20
> The objection to (B) was that, because the .machine keyring is now
> linked to the .secondary keyring, it expands the scope of what the
> kernel has trusted in the past. The effect is that keys in MOK
> have the same broad scope as keys previously restricted to
> .builtin and .secondary. It doesn't affect just IMA, but the rest
> of the kernel as well.
>=20
> I would suggest that we can get unstuck by considering:
>=20
> (C) Defining a systemd (or dracut module) to load keys onto the
>     .secondary keyring
>=20
> (D) Using a configuration option to specify what types of
>     .machine keys should be allowed to pass through to the
>     .secondary keyring.
>   =20
>     The distro could choose (A) by allowing only
>     CA+keyCertSign keys.
>=20
>     The distro could choose (B) by allowing any kind
>     of key.
>=20
> We all seemed to agree that enforcing key usage should be
> implemented and that a useful future effort is to add policies
> to keys and keyrings, like, "This key can only be used for
> verifying kernel modules."
>=20
> I hope we can come to an agreement so work can proceed and IMA
> can be re-enabled.

I would be open to making the changes necessary to support both (A and B)=20
options.  What type of configuration option would be considered?  Would thi=
s=20
be a compile time Kconfig, a Linux boot command line parameter, or another=
=20
MOK variable?