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 16:53:24 -0400 Message-ID: References: <1309377038-4550-1-git-send-email-zohar@linux.vnet.ibm.com> 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: In-Reply-To: <1309377038-4550-1-git-send-email-zohar@linux.vnet.ibm.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 29, 2011 at 15:50, Mimi Zohar wr= ote: > Discretionary Access Control(DAC) and Mandatory Access Control(MAC) c= an > protect the integrity of a running system from unauthorized changes. = When > these protections are not running, such as when booting a malicious O= S, > mounting the disk under a different operating system, or physically m= oving > the disk to another system, an "offline" attack is free to read and w= rite > file data/metadata. > > Extended Verification Module(EVM) detects offline tampering of the se= curity > extended attributes (e.g. security.selinux, security.SMACK64, securit= y.ima), > which is the basis for LSM permission decisions and, with the IMA-app= raisal > patchset, integrity appraisal decisions. This patchset provides the f= ramework > and an initial method to detect offline tampering of the security ext= ended > attributes. =C2=A0The initial method maintains an HMAC-sha1 across a = set of > security extended attributes, storing the HMAC as the extended attrib= ute > 'security.evm'. To verify the integrity of an extended attribute, EVM= exports > evm_verifyxattr(), which re-calculates the HMAC and compares it with = the > version stored in 'security.evm'. =C2=A0Other methods of validating t= he integrity > of a file's metadata will be posted separately (eg. EVM-digital-signa= tures). Hmm, I'm not sure that this design actually provides the protection tha= t you claim it does. Specifically, you don't actually protect the on-disk data-structures th= at are far more vulnerable to malicious modification than the actual *valu= es* of the extended attributes themselves. =46or example, compare the number of actual practical exploits of image buffer-overflow vulnerabilities involving user-generated content versus the number of Man-in-the-middle exploits of trusted content, I guarante= e you there are a lot more of the former in the wild. It's also worth mentioning that one of the reasons we have traditionall= y prevented user mounts of many filesystems is because the filesystem drivers tended to be buggy and susceptible to panic or buffer overflow. To give you a trivial example of how this could be subverted, you could modify the block mapping table of an unprotected file to reference some blocks used in a "protected" file.=C2=A0 Then boot up the system and "v= erify" the protected file, and then write new data to the unprotected file and generate some memory pressure to force the protected data to be reloade= d from disk. Another good example of how this breaks down in practice would be the various incompatibilities in different VFAT filesystem behavior with NUL filenames.=C2=A0 I don't remember what the change was on Linux, but= in practice on several operating systems you can "mkdir" a new directory entry and several more could suddenly appear (because the NUL entry is now populated). If you want to use HMAC verification of disk contents then you should n= ot be performing the HMAC of some partial logical view of them, but instea= d protect the *disk contents* themselves!!! Perhaps modifying dm-crypt to support HMAC-based authentication modes would be one approach.=C2=A0 You could probably even code it to store t= he HMAC metadata in a separate partition to allow for read-only access by your bootloader, etc. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html