On Wed, 2011-06-29 at 21:57 -0400, Kyle Moffett wrote: > On Wed, Jun 29, 2011 at 19:42, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2011-06-29 at 16:53 -0400, Kyle Moffett wrote: > >> On Wed, Jun 29, 2011 at 15:50, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > >> > Discretionary Access Control(DAC) and Mandatory Access Control(MAC) can > >> > protect the integrity of a running system from unauthorized changes. When > >> > these protections are not running, such as when booting a malicious OS, > >> > mounting the disk under a different operating system, or physically moving > >> > the disk to another system, an "offline" attack is free to read and write > >> > file data/metadata. > >> > > >> > Extended Verification Module(EVM) detects offline tampering of the security > >> > extended attributes (e.g. security.selinux, security.SMACK64, security.ima), > >> > which is the basis for LSM permission decisions and, with the IMA-appraisal > >> > patchset, integrity appraisal decisions. This patchset provides the framework > >> > and an initial method to detect offline tampering of the security extended > >> > attributes. The initial method maintains an HMAC-sha1 across a set of > >> > security extended attributes, storing the HMAC as the extended attribute > >> > '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'. Other methods of validating the integrity > >> > of a file's metadata will be posted separately (eg. EVM-digital-signatures). > >> > >> 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 *values* > >> of the extended attributes themselves. > > > > True, EVM only protects the file metadata. The patch description says, > > > > While this patchset does authenticate the security xattrs, and > > cryptographically binds them to the inode, coming extensions > > will bind other directory and inode metadata for more complete > > protection. > > > > 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 offline > 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. > > 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 filesystem > then you MUST authenticate *all* of the low-level filesystem data, > including the "implicit" metadata of allocation tables, extents, etc. > > Cheers, > Kyle Moffett Assuming someone does modify the underlying filesystem, how does that break the security model? The purpose of EVM/IMA-appraisal is not to prevent files offline from being modified, but to detect if/when it occurs and to enforce file integrity. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
