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
| ||
|
Date: Mon, 23 Nov 2020 14:49:10 -0500 From: Mimi Zohar <zohar@...ux.ibm.com> To: Pavel Machek <pavel@....cz> Cc: Tushar Sugandhi <tusharsu@...ux.microsoft.com>, 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 On Mon, 2020-11-23 at 18:18 +0100, Pavel Machek wrote: > > > 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. > > So, why not simply measure everything that is ro_after_init? I guess we could, but the original discussion, a long time ago prior to LSM stacking, was limited to measuring the LSM hooks. Mimi
Powered by blists - more mailing lists