From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754356AbbCQLk7 (ORCPT ); Tue, 17 Mar 2015 07:40:59 -0400 Received: from mail.eperm.de ([89.247.134.16]:46696 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751895AbbCQLk4 convert rfc822-to-8bit (ORCPT ); Tue, 17 Mar 2015 07:40:56 -0400 From: Stephan Mueller To: Herbert Xu Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] crypto: prevent helper ciphers from being allocated by users Date: Tue, 17 Mar 2015 12:40:12 +0100 Message-ID: <1442292.caf3IdtESe@tauon> User-Agent: KMail/4.14.4 (Linux/3.18.8-201.fc21.x86_64; KDE/4.14.4; x86_64; ; ) In-Reply-To: <20150317112350.GA11671@gondor.apana.org.au> References: <13986065.EbkBp8M36a@tachyon.chronox.de> <20150317112350.GA11671@gondor.apana.org.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Dienstag, 17. März 2015, 22:23:50 schrieb Herbert Xu: Hi Herbert, >On Fri, Mar 13, 2015 at 10:09:21PM +0100, Stephan Mueller wrote: >> +struct crypto_tfm *__crypto_alloc_tfm_safe(struct crypto_alg *alg, >> u32 type, + u32 mask) >> +{ >> + /* >> + * Prevent all ciphers from being loaded which have a cra_priority >> + * of 0. Those cipher implementations are helper ciphers and >> + * are not intended for general consumption. >> + * >> + * The only exceptions are the compression algorithms which >> + * have no priority. >> + */ >> + if (!alg->cra_priority && >> + ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) != >> + CRYPTO_ALG_TYPE_PCOMPRESS) && >> + ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) != >> + CRYPTO_ALG_TYPE_COMPRESS)) >> + return ERR_PTR(-ENOENT); > >How about adding a flag to all these internal algorithms and then >change crypto_alg_mod_lookup to disable that flag by default? The issue with flags is the following: first we have to think about whether we want a black list or white list approach. Your suggestion implies a black list. Black lists for ensuring security is not good IMHO as it has a tendency to miss cases. This especially applies to this area where we have already an indicator for internal ciphers: the prio is so low that it will never ever be selected based on the name. Now, adding a flag means that we mark such an internal cipher twice. Therefore, I would not opt for such a flag (at least for a black list) and stay with the prio approach. Ciao Stephan