Re: Allow FUSE filesystems to provide out-of-band hashes to IMA

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

 



On Mon, Oct 8, 2018 at 4:25 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> On Fri, 2018-10-05 at 12:25 -0700, Matthew Garrett wrote:
> > 1) You trust FUSE mounts, perhaps because you have some other policy
> > in place to ensure that only trusted binaries can mount stuff. In this
> > scenario you already trust that the filesystem will give you
> > consistent results when you read data from it -
>
> In the trusted mount scenario, we trust the data should not change
> between calculating the file hash and reading the file data, making it
> similar to other local filesystems.  Unlike other local filesystems,
> however, we can't detect when the file changes.  For this reason we
> need to re-calculate the file hash to measure/appraise the file each
> time.

But we don't re-measure for every read, so it's still possible for the
filesystem to give us back different results without affecting the
measurement.

> > it seems reasonable to
> > also trust it to give you back an accurate hash if you ask for one.
>
> Going from trusting the filesystem to behave properly, to trusting the
> file hash that the filesystem provides is a major leap.  We don't do
> this today for any local filesystem.

I don't think any local filesystems provide a mechanism for this - we
have FUSE filesystems that do.

> > I agree that using FUSE in general is incompatible with IMA's goals,
> > but it's possible to configure systems where you can ensure that only
> > trustworthy code is involved. In that scenario this patch improves
> > performance without compromising security.
>
> If you trust a FUSE filesystem to not only behave properly, but also
> to return file hashes, what is the value of measuring/appraising the
> files?  Define a custom policy that doesn't measure/appraise files on
> FUSE filesystems.

We trust that the filesystem will return us accurate binaries and
hashes, but we don't the binaries themselves may not be trustworthy -
we want the same level of audit trail associated with their execution
that we'd have for something run off local disk. We could certainly
rearchitect our filesystems to generate audit events themselves, but
we'd be duplicating functionality that already exists in the kernel.



[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