lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Nov 2020 08:41:35 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Pavel Machek <pavel@....cz>,
        Tushar Sugandhi <tusharsu@...ux.microsoft.com>
Cc:     stephen.smalley.work@...il.com, casey@...aufler-ca.com,
        agk@...hat.com, snitzer@...hat.com, gmazyland@...il.com,
        paul@...l-moore.com, tyhicks@...ux.microsoft.com,
        sashal@...nel.org, jmorris@...ei.org, nramas@...ux.microsoft.com,
        linux-integrity@...r.kernel.org, selinux@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, dm-devel@...hat.com
Subject: Re: [PATCH v6 0/8] IMA: support for measuring kernel integrity
 critical data

Hi Pavel,

On Sun, 2020-11-22 at 22:00 +0100, Pavel Machek wrote:
> Hi!
> 
> > >How is it supposed to be useful?
> > >
> > >I'm pretty sure there are critical data that are not measured by
> > >proposed module... and that are written under normal circumstances.
> > >
> > The goal of this series is to introduce the IMA hook
> > measure_critical_data() and the necessary policies to use it; and
> > illustrate that use with one example (SELinux). It is not scalable to
> > identify and update all the critical data sources to use the proposed
> > module at once.
> > 
> > A piecemeal approach to add more critical data measurement in subsequent
> > patches would be easy to implement and review.
> 
> Basically every other data structure in kernel is "critical" by your
> definition, and you can't really measure them all; some of them change
> rather often. Going piecemeal does not really help here.

Agreed, measuring data structures that change is not really applicable.
However, measuring data structures that once initialized don't change,
does make sense (similar concept to __ro_after_init).  The attestation
server doesn't need to know anything about the measurement, other than
more than a single measurement is indicative of a problem.

Mimi

> Example of critical data structure: page table entries for process I
> own.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ