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
| ||
|
Date: Tue, 17 Mar 2015 12:40:12 +0100 From: Stephan Mueller <smueller@...onox.de> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH] crypto: prevent helper ciphers from being allocated by users 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists