Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752379Ab3CBBWq (ORCPT ); Fri, 1 Mar 2013 20:22:46 -0500 Received: from mail-oa0-f52.google.com ([209.85.219.52]:47291 "EHLO mail-oa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197Ab3CBBWp (ORCPT ); Fri, 1 Mar 2013 20:22:45 -0500 MIME-Version: 1.0 Date: Fri, 1 Mar 2013 17:22:44 -0800 Message-ID: Subject: user ns: arbitrary module loading From: Kees Cook To: "Eric W. Biederman" Cc: LKML , Serge Hallyn , Brad Spengler , Al Viro 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 Content-Length: 946 Lines: 25 The rearranging done for user ns has resulted in allowing arbitrary kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019) by what is assumed to be an unprivileged process. At present, it does look to require at least CAP_SETUID along the way to set up the uidmap (but things like the setuid helper newuidmap might soon start providing such a thing by default). It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which examines module symbols to verify that request_module() for a filesystem only loads a module that defines "register_filesystem" (among other things). -Kees [1] https://twitter.com/grsecurity/status/307473816672665600 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/