From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Moffett Subject: Re: [PATCH v7 00/16] EVM Date: Wed, 29 Jun 2011 21:57:41 -0400 Message-ID: References: <1309377038-4550-1-git-send-email-zohar@linux.vnet.ibm.com> <1309390941.3205.22.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, James Morris , David Safford , Andrew Morton , Greg KH , Dmitry Kasatkin To: Mimi Zohar Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:60468 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757529Ab1F3B6D convert rfc822-to-8bit (ORCPT ); Wed, 29 Jun 2011 21:58:03 -0400 In-Reply-To: <1309390941.3205.22.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jun 29, 2011 at 19:42, Mimi Zohar wr= ote: > On Wed, 2011-06-29 at 16:53 -0400, Kyle Moffett wrote: >> On Wed, Jun 29, 2011 at 15:50, Mimi Zohar = wrote: >> > Discretionary Access Control(DAC) and Mandatory Access Control(MAC= ) can >> > protect the integrity of a running system from unauthorized change= s. When >> > these protections are not running, such as when booting a maliciou= s OS, >> > mounting the disk under a different operating system, or physicall= y moving >> > the disk to another system, an "offline" attack is free to read an= d write >> > file data/metadata. >> > >> > Extended Verification Module(EVM) detects offline tampering of the= security >> > extended attributes (e.g. security.selinux, security.SMACK64, secu= rity.ima), >> > which is the basis for LSM permission decisions and, with the IMA-= appraisal >> > patchset, integrity appraisal decisions. This patchset provides th= e framework >> > and an initial method to detect offline tampering of the security = extended >> > attributes. =C2=A0The initial method maintains an HMAC-sha1 across= a set of >> > security extended attributes, storing the HMAC as the extended att= ribute >> > 'security.evm'. To verify the integrity of an extended attribute, = EVM exports >> > evm_verifyxattr(), which re-calculates the HMAC and compares it wi= th the >> > version stored in 'security.evm'. =C2=A0Other methods of validatin= g the integrity >> > of a file's metadata will be posted separately (eg. EVM-digital-si= gnatures). >> >> Hmm, I'm not sure that this design actually provides the protection = that >> you claim it does. >> >> Specifically, you don't actually protect the on-disk data-structures= that >> are far more vulnerable to malicious modification than the actual *v= alues* >> of the extended attributes themselves. > > True, EVM only protects the file metadata. The patch description says= , > > =C2=A0 =C2=A0 =C2=A0 =C2=A0While this patchset does authenticate the = security xattrs, and > =C2=A0 =C2=A0 =C2=A0 =C2=A0cryptographically binds them to the inode,= coming extensions > =C2=A0 =C2=A0 =C2=A0 =C2=A0will bind other directory and inode metada= ta for more complete > =C2=A0 =C2=A0 =C2=A0 =C2=A0protection. > > It should have said, "bind other directory, inode data and inode > metadata." > > In particular, IMA-appraisal stores the file data's hash as the > security.ima xattr, which is EVM protected. Other methods, such as > digital signatures, could be used instead of the file's hash, to > additionally provide authenticity. The problem is that your *design* assumes that the filesystem itself is valid, but your stated threat model assumes that the attacker has offli= ne access to the filesystem, an explicit contradiction. There have been numerous cases in the past where a corrupt or invalid filesystem causes kernel panics or even exploitable overflows or memory corruption; see the history of the "fsfuzzer" tool for more information= =2E =46urthermore, if the attacker can intentionally cause data extent or i= node extended attribute aliasing (shared space-on-disk) between different files then your entire security model falls flat. So if you assume the attacker has raw access to the underlying filesyst= em then you MUST authenticate *all* of the low-level filesystem data, including the "implicit" metadata of allocation tables, extents, etc. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html