Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755966Ab3CUPwj (ORCPT ); Thu, 21 Mar 2013 11:52:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753724Ab3CUPwh (ORCPT ); Thu, 21 Mar 2013 11:52:37 -0400 Date: Thu, 21 Mar 2013 11:52:20 -0400 From: Vivek Goyal To: "Serge E. Hallyn" Cc: Matthew Garrett , Mimi Zohar , James Morris , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Message-ID: <20130321155220.GL3934@redhat.com> References: <1363797717.2580.10.camel@falcor1.watson.ibm.com> <1363798166.2553.29.camel@x230.sbx07502.somerma.wayport.net> <1363802506.2580.55.camel@falcor1.watson.ibm.com> <1363803158.2553.33.camel@x230.sbx07502.somerma.wayport.net> <1363806968.2580.86.camel@falcor1.watson.ibm.com> <1363811856.2553.37.camel@x230.sbx07502.somerma.wayport.net> <1363813877.2580.120.camel@falcor1.watson.ibm.com> <1363814289.2553.41.camel@x230.sbx07502.somerma.wayport.net> <20130321134348.GA3934@redhat.com> <20130321153725.GA3656@austin.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321153725.GA3656@austin.hallyn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2132 Lines: 50 On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote: > Quoting Vivek Goyal (vgoyal@redhat.com): > ... > > Giving CAP_MODIFY_KERNEL to processess upon signature verification > > will simplify things a bit. > > > > Only thing is that signature verification alone is not sufficient. We > > also need to make sure after signature verification executable can > > not be modified in memory in any way. So that means atleast couple of > > things. > > Also what about context? If I construct a mounts namespace a certain > way, can I trick this executable into loading an old singed bzImage that > I had laying around? We were thinking that /sbin/kexec will need to verify bzImage signature before loading it. Key for verification is in kernel so idea was to take kernel's help in verifying signature. Not sure how exactly the interface should look like. - I was thinking may be process can mmap() the bzImage with MAP_LOCKED. We can create additional flag say MAP_VERIFY_SIG_POST, which tries to verify signature/integrity of mapped region of file after mapping and locking pages and mmap() fails if signature verification fails. There have been suggestions about creating new system call altogether. > > ISTM the only sane thing to do, if you're going down this road, > is to have CAP_MODIFIY_KERNEL pulled from bounding set for everyone > except a getty started by init on ttyS0. Then log in on serial > to update. Or run a damon with CAP_MODIFIY_KERNEL which listens > to a init_net_ns netlink socket for very basic instructions, like > "find and install latest signed bzImage in /boot". Then you can > at least trust that /boot for that daemon is not faked. daemon does not have the key and can't verify signature of signed bzImage. Even if it had the key, it can't trust the crypto code for signature verification as none of that is signed. Thanks Vivek -- 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/