Re: [PATCH V2 3/4] IMA: Optionally make use of filesystem-provided hashes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 7, 2019 at 12:48 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
>
> On Wed, 2019-03-06 at 20:19 -0800, Matthew Garrett wrote:
> > I'm not sure I understand the additional risk, though. Either a
> > filesystem is already being measured using a full read, in which case
> > adding an additional rule won't change behaviour, or it's not being
> > measured at all, in which case there's no incentive for an attacker to
> > add a new rule.
>
> In an environment where the initramfs contains everything, including
> the IMA policy, and is verified, then what you're saying is true - the
> IMA policy doesn't need to be signed.  However, the existing dracut
> and systemd IMA modules read the IMA policy not from the initramfs,
> but from real root.  In this environment where the IMA policy is on
> real root, an attacker could modify the IMA policy.  I realize this is
> an existing problem, not particular to "get_hash'.  Unlike other
> policy changes, the attestation server would have no way of detecting
> this particular change.

Ah, got you. Would measuring the policy be sufficient here?

> > In both cases we're placing trust in the filesystem's correctness.
> > It's certainly possible for the get_hash call to be broken, but that's
> > something we can put additional testing into.
>
> The call itself wouldn't be broken, but determining if the filesystem
> is actually calculating/re-calculating the file hash properly or
> simply returning a stored/cached value.  I do see the benefit of the
> filesystems being responsible for the file hash.  Perhaps I'm just
> being overly cautious.  I'd like to hear other people's opinions.

Yup, happy to get further feedback on this.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux