From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Moffett Subject: Re: [PATCH v7 00/16] EVM Date: Thu, 30 Jun 2011 18:32:59 -0400 Message-ID: References: <1309377038-4550-1-git-send-email-zohar@linux.vnet.ibm.com> <1309390941.3205.22.camel@localhost.localdomain> <1309405895.3205.57.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 To: Mimi Zohar Return-path: In-Reply-To: <1309405895.3205.57.camel@localhost.localdomain> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Whoops, resent in plain text, sorry about the HTML On Wed, Jun 29, 2011 at 23:51, Mimi Zohar wr= ote: > On Wed, 2011-06-29 at 21:57 -0400, Kyle Moffett wrote: >> On Wed, Jun 29, 2011 at 19:42, Mimi Zohar = wrote: >> > On Wed, 2011-06-29 at 16:53 -0400, Kyle Moffett wrote: >> >> Hmm, I'm not sure that this design actually provides the protecti= on that >> >> you claim it does. >> >> >> >> Specifically, you don't actually protect the on-disk data-structu= res that >> >> are far more vulnerable to malicious modification than the actual= *values* >> >> of the extended attributes themselves. >> > >> > True, EVM only protects the file metadata. The patch description s= ays, >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0While this patchset does authenticate t= he security xattrs, and >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0cryptographically binds them to the ino= de, coming extensions >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0will bind other directory and inode met= adata 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 of= fline >> access to the filesystem, an explicit contradiction. >> >> There have been numerous cases in the past where a corrupt or invali= d >> filesystem causes kernel panics or even exploitable overflows or mem= ory >> corruption; see the history of the "fsfuzzer" tool for more informat= ion. >> >> Furthermore, if the attacker can intentionally cause data extent or = inode >> 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 files= ystem >> then you MUST authenticate *all* of the low-level filesystem data, >> including the "implicit" metadata of allocation tables, extents, etc= =2E >> >> Cheers, >> Kyle Moffett > > Assuming someone does modify the underlying filesystem, how does that > break the security model? =C2=A0The purpose of EVM/IMA-appraisal is n= ot to > prevent files offline from being modified, but to detect if/when it > occurs and to enforce file integrity. The problem is that you are assuming that a large chunk of filesystem code is capable of properly and securely handling untrusted and malicio= us content. Historically filesystem drivers are NOT capable of handling such things, as evidenced by the large number of bugs that tools such a= s fsfuzzer tend to trigger. If you want to use IMA as-designed then you need to perform a relatively extensive audit of filesystem and fsck cod= e. =46urthermore, even when the filesystem does not have any security issu= es itself, you are assuming that intentionally malicious data-aliasing between "trusted" and "untrusted" files can have no potential security implications. You should look at the prevalence of simple stupid "/tmp= " symlink attacks for more counter-examples there. In addition, IMA relies on the underlying attribute and data caching properties of the VFS, which won't hold true for intentionally maliciou= s corrupted filesystems. It effectively assumes that writing data or metadata for one file will not invalidate the cached data or metadata f= or another which is blatantly false when filesystem extents overlap each other. Overall, the IMA architecture assumes that if it loads and validates th= e file data or metadata that it cannot be changed except through a kernel access to that particular inode. For a corrupted filesystem that is absolutely untrue. 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