Re: [PATCH v7 00/16] EVM

[David Safford]

On Thu, 2011-06-30 at 18:32 -0400, Kyle Moffett wrote:
> Whoops, resent in plain text, sorry about the HTML
> 
> On Wed, Jun 29, 2011 at 23:51, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> > 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:
> >> >> 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.
> 
> The problem is that you are assuming that a large chunk of filesystem
> code is capable of properly and securely handling untrusted and malicious
> content.  Historically filesystem drivers are NOT capable of handling
> such things, as evidenced by the large number of bugs that tools such as
> 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 code.

Seems to me exploitable bugs in fs code should be fixed regardless of EVM...

> Furthermore, even when the filesystem does not have any security issues
> 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 malicious
> corrupted filesystems.  It effectively assumes that writing data or
> metadata for one file will not invalidate the cached data or metadata for
> another which is blatantly false when filesystem extents overlap each
> other.

As discussed, this is a tradeoff in IMA-Appraisal-HASH, which allows
data in protected files to be updated. The attacks do not work on EVM,
IMA-Appraisal-DigitalSignature, or IMA attestation, where the attacker
cannot forge valid verifiers, even with arbitrary access to the raw device.

> Overall, the IMA architecture assumes that if it loads and validates the
> 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.
 
IMA-Appraisal-HASH does as a deliberate tradeoff. The other integrity 
modules do not.

thanks
dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/