Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173Ab2JHCY5 (ORCPT ); Sun, 7 Oct 2012 22:24:57 -0400 Received: from ozlabs.org ([203.10.76.45]:47913 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092Ab2JHCYz (ORCPT ); Sun, 7 Oct 2012 22:24:55 -0400 From: Rusty Russell To: Mimi Zohar , "Kasatkin\, Dmitry" Cc: Kasatkin@ozlabs.org, Kees Cook , David Howells , LKML Subject: Re: Module xattr signatures In-Reply-To: <1349457006.20387.41.camel@falcor> References: <87a9w11yhs.fsf@rustcorp.com.au> <1349457006.20387.41.camel@falcor> User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Mon, 08 Oct 2012 10:03:58 +1030 Message-ID: <874nm5rh5l.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2653 Lines: 71 Mimi Zohar writes: > On Fri, 2012-10-05 at 17:42 +0300, Kasatkin, Dmitry wrote: >> Hello, >> >> On Fri, Oct 5, 2012 at 4:47 AM, Rusty Russell wrote: >> > >> > Hi all, >> > >> > Had a talk with Mimi, and IMA still wants xattr signatures on >> > modules like they have for other files with EVM. With Kees' patches now >> > merged into my modules-wip branch (warning, rebases frequently), this >> > should be pretty simple. Dmitry? >> > >> >> Yes, there is no difference for IMA/EVM what type of file has a >> signature to verify. >> It just reads the signature from the xattr. With the module hook it >> will just do the same >> for modules as well. It is independent of appended signature verification. >> The format of signatures is different at the moment. > >> > The question of whether this falls back to appended signatures >> > if there's no xattr support, or whether we fix cpio depends on whether >> > someone is prepared to do the latter. As Mimi points out, AIX, bsd, >> > solaris all have versions of cpio that support extended attributes, as >> > does the bsdcpio Debian package, for example. >> > >> >> As I already said in one of my early mails, I am not sure at all if >> IMA really needs to verify a signature, >> if primary mechanism is to use appended signature. > > Which is the preferred method is exactly the point. That depends on your > use case. For systems with IMA-appraisal already enabled, there would > not be any reason for the appended signature verification. > > Now, with the MODULE_CHECK hook, systems could define an IMA-appraisal > policy to appraise just kernel modules. > > The remaining issue is how to deal with filesystems that don't have > extended attribute support. As we've already had this discussion, lets > summarize the different options: > > - don't support them > > Not very friendly. > > - modify the new syscall to pass the signature and signature length > > Kees nixed this idea. > > - fall back to appended signature verification > > In addition to David Howell's version of the appended signature > verification, I would like having the existing EVM/IMA-appraisal > signature format, based on Dmitry's proposed kernel module patches, as > another option. Or: - Reduce the set of filesystems which don't support xattrs to the empty set ;) Which I prefer... Cheers, Rusty. -- 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/