From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754805AbZHMP36 (ORCPT ); Thu, 13 Aug 2009 11:29:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754221AbZHMP35 (ORCPT ); Thu, 13 Aug 2009 11:29:57 -0400 Received: from mx2.redhat.com ([66.187.237.31]:33624 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752479AbZHMP34 (ORCPT ); Thu, 13 Aug 2009 11:29:56 -0400 Subject: Re: [PATCH 2/3] security: introducing security_request_module From: Eric Paris To: "Serge E. Hallyn" Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, sds@tycho.nsa.gov, davem@davemloft.net, shemminger@linux-foundation.org, kees@ubuntu.com, morgan@kernel.org, casey@schaufler-ca.com, dwalsh@redhat.com In-Reply-To: <20090813140306.GC30731@us.ibm.com> References: <20090813134451.29186.41664.stgit@paris.rdu.redhat.com> <20090813134457.29186.7182.stgit@paris.rdu.redhat.com> <20090813140306.GC30731@us.ibm.com> Content-Type: text/plain Date: Thu, 13 Aug 2009 11:28:54 -0400 Message-Id: <1250177334.2182.88.camel@dhcp231-106.rdu.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-08-13 at 09:03 -0500, Serge E. Hallyn wrote: > Quoting Eric Paris (eparis@redhat.com): > > Calling request_module() will trigger a userspace upcall which will load a > > new module into the kernel. This can be a dangerous event if the process > > able to trigger request_module() is able to control either the modprobe > > binary or the module binary. This patch adds a new security hook to > > request_module() which can be used by an LSM to control a processes ability > > to call request_module(). > > Is there a specific case in which you'd want to deny this ability > from a real task? qemu and any network facing daemon are all programs I don't want to be able to even ask the kernel to load a module. Clearly you are right, that the best protection is done by controlling access to modprobe and the modules on disk (which we are working to fix vs what happened in the xen fb exploit I showed earlier) but stopping it from the other direction is, I feel, a useful defense in depth. If they can't get modprobe called, they can't take over the system directly, even if they did change a module or change modprobe. I agree it's not strong security as if they can change modprobe or modules they might be able to just wait until something else calls modprobe (next reboot maybe?) to take over the system. But I'd find it very interesting to know that a high threat target tried to do anything which attempted to load a module.... -Eric