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 Tue, 2019-03-05 at 12:27 -0800, Matthew Garrett wrote:
> On Tue, Mar 5, 2019 at 11:51 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> > On Tue, 2019-03-05 at 10:39 -0800, Matthew Garrett wrote:
> > > We can trust in-kernel filesystems to return reliable information.
> > > Network filesystems have the same issue as FUSE - we're trusting that
> > > the remote endpoint won't give us different information on successive
> > > reads. What's the threat that's blocked by requiring signed policy
> > > here?
> >
> > Today, IMA calculates the file hash by reading the file.  If
> > "get_hash" is a generic filesystem ops, then any filesystem could
> > implement it, properly or not.  sysadmins shouldn't have to review
> > kernel code to understand the source of the file hash, but should be
> > able to assume that unless they explicitly authorize "get_hash" usage,
> > IMA reads the file and calculates the file hash.
> 
> But what's the threat? If an attacker is in a position to inject
> additional IMA policy then in general they're already in a position to
> violate other security assumptions. Admins who have a threat model
> that includes an attacker being able to do this are already requiring
> signed policy. What's the threat that requiring signed policy for this
> specific option mitigates?

That might be true, but this "feature" isn't a minor change.  It
totally changes the IMA measurement list meaning, without any
indication of the change in meaning.

Mimi




[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