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:     Mimi Zohar <zohar@linux.ibm.com>
CC:     Jarkko Sakkinen <jarkko@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "jmorris@namei.org" <jmorris@namei.org>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "pvorel@suse.cz" <pvorel@suse.cz>,
        "noodles@fb.com" <noodles@fb.com>, "tiwai@suse.de" <tiwai@suse.de>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        Elaine Palmer <erpalmer@linux.vnet.ibm.com>,
        Coiby Xu <coxu@redhat.com>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v3 00/10] Add CA enforcement keyring restrictions
Thread-Topic: [PATCH v3 00/10] Add CA enforcement keyring restrictions
Thread-Index: AQHZD1PCFegbrli1zUCp/3TmJTzIr65uvzMAgABmOoA=
Date:   Thu, 15 Dec 2022 16:26:53 +0000
Message-ID: <4CE6F17D-9D87-4024-9E1A-FDFE7C29D5FC@oracle.com>
References: <20221214003401.4086781-1-eric.snowberg@oracle.com>
 <b8e54d077da633132eb6da03ea536face095a425.camel@linux.ibm.com>
In-Reply-To: <b8e54d077da633132eb6da03ea536face095a425.camel@linux.ibm.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?NFH2v3NpvLqRMIPpH3+Tlw+UKY757rFzRB1TnzZNbxpHAQY9i1VlD6y7xL5j?=
 =?us-ascii?Q?P5Z9yAI5U1VKYCkJSZ62SQIc+CO4RW5vrbQ69tua6rC9a+MyhY2wAxH8LpSh?=
 =?us-ascii?Q?Pg3VNUN8aianW1eogNtYXH9kApjSITePMcMjC3Hcm3o6ZOFE5aQgVB/+6YRH?=
 =?us-ascii?Q?qfFed/xwdSeaioMjaZ7PA5V2rg32XDwOcLRh/Fla+4ZqoqZTziVEvzIb3U4d?=
 =?us-ascii?Q?yG7h0HqRLzrhIpggWwN1KuAcw+Fm2nqvIZSXyrONaUSNQ7Uu7qWL3G35+FmQ?=
 =?us-ascii?Q?IstRcxde5nj1xnz0d92GnyfGovhh6pd2eqkURLRxBQzby6xPN/BZ5fHi6FnU?=
 =?us-ascii?Q?lfz7hgZ6p4zYLqha08ce1LTfM+EMSP/GyGzHKn9b5oT4+L7k9u2V3o7NbgMv?=
 =?us-ascii?Q?AM+7xmUKtJXlSBCto1KjZ0Ut2b9OJDyCvZz30njC+bh6d5tH9bw2Omg6NSgA?=
 =?us-ascii?Q?cauiqLbeo/nlVlvNfOwsqxUhO+FTn1Z8y9m8r9UgBupTc5uAJYNGEqLWA73v?=
 =?us-ascii?Q?T/A8qMap31SJI2/ENpY4Qn4oNXCtiXzUJDGzLTO3FX/JAbRgMl8bfni5qhGB?=
 =?us-ascii?Q?Ehx/czY7LFznPylN95i0XEdVsGw5AkHXq9cbft0xTUpOtmF85aAwrTirPAzj?=
 =?us-ascii?Q?E/9jaMWf3dSDGmnDmaVzUssQwTRAAb0udNkT5nqdDD4s8XWFzYo5w1DZT2Gl?=
 =?us-ascii?Q?xzgds5ODfcWuX+AKO1V4Q46UeYbEyx6EVOQb8GkqZmDScgEw4+Ijjd/6vBsD?=
 =?us-ascii?Q?QXnb4qa+M34esWlQRcPf1ibWx1VQShwvK1gHxfx9uP33jaorp3A/HjM+rJFB?=
 =?us-ascii?Q?mm8NyOou3F4XeuxGJQlX0tyRqufFxcBAJKegK0XHFXtOJxH24NrGEj3YDkhb?=
 =?us-ascii?Q?NR8/A2u0u2B4nwrrPIs2nSlzLw4cDL+ny0Aq1w26PNBL8RLAiDEtqmfQpHvV?=
 =?us-ascii?Q?Ic0vSZeUYJFmnBaUX67k3M1FedzYtqMrAfc/7ro7AuTKlxgTmlVPJubtzM8K?=
 =?us-ascii?Q?cwfAoxEH7vknHTuO0JSe80yzLSvs2HeMd4tvImn5TT0f67ouQRjAZ+/+k6W3?=
 =?us-ascii?Q?AH6T5lYrBIrJ9bR0yXChVnqsfHZ/T/qAk0Aqva09ejAgGAmySM/OA4eMnqLJ?=
 =?us-ascii?Q?E18waO44NMWZ+jiQuiD5e3ZQMvyK5+IuSn6aP6SuTEYET39QUTocauR1Btgv?=
 =?us-ascii?Q?TtblhqCHwetMVdlwA9BAcCgfGTDClUFoMczALoiHKZWhy7xymIZ8igJGpthX?=
 =?us-ascii?Q?UkMmfrcWEi57/XyxuBvBimvis7tP3ilcx7b1dRWhNAO+EqwUz81iS/bg6Qat?=
 =?us-ascii?Q?ta5/rF/dTcSwm3keJ45wR/tNoclu2upZaI9g3SZyjnhPuvje10PdwBh7MSv4?=
 =?us-ascii?Q?G3LCrogCxmZdwnSi5QjaPlhnKLpNU/2GnDHJyEkKHh95jNvWoI6SpnozU/Er?=
 =?us-ascii?Q?wucrEVe5oCIgi6vlTFcROWY4lubtmkdm0toN1NTvj6yN2oWswmys5mYoT8a+?=
 =?us-ascii?Q?uPWgWrzZHuNgqiIqPSzkgMGHvPCm9lCRhK+4QP2MzNe0rqJ23wvfEPcGhMhK?=
 =?us-ascii?Q?nxDeHKB3q8H1kAjzUp+Mm94d0R/cf+299PlZgtEfTI7pdTkyB9u7ejVcHvp4?=
 =?us-ascii?Q?+w=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CEC500C11E18D546BC73634AAFF9D79B@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: 4f297545-7306-4808-3652-08dadeb92d83
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2022 16:26:53.9767
 (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: n6MBPTox+vUbUU5S2DjYTOEvivLOA+STmcHfOuwvc9Q998T+ITWlvoihZtIO1YtDBf1TqcYXs7T3mLiJb+fQWRHR2qnThgS47fmS7ObWtLM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4413
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-12-15_10,2022-12-15_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0
 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000
 definitions=main-2212150135
X-Proofpoint-ORIG-GUID: FNCMvDVxQbE2IgGqKDKdPR_VJp5JO5-F
X-Proofpoint-GUID: FNCMvDVxQbE2IgGqKDKdPR_VJp5JO5-F
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 Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>=20
> On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote:
>> Prior to the introduction of the machine keyring, most distros simply=20
>> allowed all keys contained within the platform keyring to be used
>> for both kernel and module verification.  This was done by an out of
>> tree patch.  Some distros took it even further and loaded all these keys
>> into the secondary trusted keyring.  This also allowed the system owner=
=20
>> to add their own key for IMA usage.
>>=20
>> Each distro contains similar documentation on how to sign kernel modules
>> and enroll the key into the MOK.  The process is fairly straightforward.
>> With the introduction of the machine keyring, the process remains
>> basically the same, without the need for any out of tree patches.
>>=20
>> The machine keyring allowed distros to eliminate the out of tree patches
>> for kernel module signing.  However, it falls short in allowing the end=
=20
>> user to add their own keys for IMA. Currently the machine keyring can no=
t=20
>> be used as another trust anchor for adding keys to the ima keyring, sinc=
e=20
>> CA enforcement does not currently exist.  This would expand the current=
=20
>> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=20
>> Kconfig states that keys may be added to the ima keyrings if the key is=
=20
>> validly signed by a CA cert in the system built-in or secondary trusted=
=20
>> keyring.  Currently there is not code that enforces the contents of a
>> CA cert. Any key in the builtin or secondary keyring can be used.=20
>>=20
>> To allow IMA to be enabled with the machine keyring, this series introdu=
ces
>> enforcement of key usage in the certificate. This series also applies
>> this enforcement across all kernel keyrings.
>>=20
>> The machine keyring shares  similarities with both the builtin and
>> secondary keyrings.  Similar to the builtin, no keys may be added to the
>> machine keyring following boot. The secondary keyring allows user
>> provided keys to be added following boot; however, a previously enrolled
>> kernel key must vouch for the key before it may be included. The system
>> owner may include their own keys into the machine keyring prior to boot.
>> If the end-user is not the system owner, they may not add their own keys
>> to the machine keyring. =20
>>=20
>> The machine keyring is only populated when Secure Boot is enabled.  A
>> system owner has the ability to control the entire Secure Boot keychain
>> (PK, KEK, DB, and DBX).  The system owner can also turn Secure Boot off.
>> With this control, they may use insert-sys-cert to include their own key=
=20
>> and re-sign their kernel and have it boot.  The system owner also has=20
>> control to include or exclude MOK keys. This series does not try to=20
>> interpret how a system owner has configured their machine.  If the syste=
m=20
>> owner has taken the steps to add their own MOK keys, they will be=20
>> included in the machine keyring and used for verification, exactly=20
>> the same way as keys contained in the builtin and secondary keyrings.
>> Since the system owner has the ability to add keys before booting to
>> either the machine or builtin keyrings, it is viewed as inconsequential=
=20
>> if the key originated from one or the other.
>>=20
>> This series introduces two different ways to configure the machine keyri=
ng.
>> By default, nothing changes and all MOK keys are loaded into it.  Whenev=
er
>> a CA cert is found within the machine, builtin, or secondary, a flag=20
>> indicating this is stored in the public key struct.  The other option is=
=20
>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA cert=
s=20
>> will be loaded into the machine keyring. All remaining MOK keys will be=
=20
>> loaded into the platform keyring.
>>=20
>> A CA cert shall be defined as any X509 certificate that contains the=20
>> keyCertSign key usage and has the CA bit set to true.
>=20
> Hi Eric,
>=20
> Allowing CA certificates with the digitalSignature key usage flag
> enabled defeats the purpose of the new Kconfig.  Please update the
> above definition to exclude the digitalSignature key usage flag and
> modify the code accordingly.

Within v2, the request was made to allow Intermediate CA certificates to be=
=20
loaded directly.  The Intermediate CA referenced was the one used by kernel=
.org. =20
This Intermediate CA contains both digitalSignature and keyCertSign.  If th=
e code=20
is changed to exclude this certificate, now the root CA has to be loaded ag=
ain.  Is that=20
the intent?