| Message ID | 20240327150019.81477-1-zohar@linux.ibm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | ima: define an init_module critical data record | expand |
On Wed Mar 27, 2024 at 5:00 PM EET, Mimi Zohar wrote: > The init_module syscall loads an ELF image into kernel space without > measuring the buffer containing the ELF image. To close this kernel > module integrity gap, define a new critical-data record which includes > the hash of the ELF image. > > Instead of including the buffer data in the IMA measurement list, > include the hash of the buffer data to avoid large IMA measurement > list records. The buffer data hash would be the same value as the > finit_module syscall file hash. > > To enable measuring the init_module buffer and other critical data from > boot, define "ima_policy=critical_data" on the boot command line. Since > builtin policies are not persistent, a custom IMA policy must include > the rule as well: measure func=CRITICAL_DATA label=modules > > To verify the template data hash value, first convert the buffer data > hash to binary: > grep "init_module" \ > /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ > tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum > > Reported-by: Ken Goldman <kgold@linux.ibm.com> > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > --- > security/integrity/ima/ima_main.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c > index c84e8c55333d..4b4348d681a6 100644 > --- a/security/integrity/ima/ima_main.c > +++ b/security/integrity/ima/ima_main.c > @@ -902,6 +902,13 @@ static int ima_post_load_data(char *buf, loff_t size, > return 0; > } > > + /* > + * Measure the init_module syscall buffer containing the ELF image. > + */ > + if (load_id == LOADING_MODULE) > + ima_measure_critical_data("modules", "init_module", > + buf, size, true, NULL, 0); No reason not to ack but could be just as well (passing checkpatch): if (load_id == LOADING_MODULE) ima_measure_critical_data("modules", "init_module", buf, size, true, NULL, 0); < 100 characters > + > return 0; > } > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> BR, Jarkko
On Wed, 2024-03-27 at 18:54 +0200, Jarkko Sakkinen wrote: > On Wed Mar 27, 2024 at 5:00 PM EET, Mimi Zohar wrote: > > The init_module syscall loads an ELF image into kernel space without > > measuring the buffer containing the ELF image. To close this kernel > > module integrity gap, define a new critical-data record which includes > > the hash of the ELF image. > > > > Instead of including the buffer data in the IMA measurement list, > > include the hash of the buffer data to avoid large IMA measurement > > list records. The buffer data hash would be the same value as the > > finit_module syscall file hash. > > > > To enable measuring the init_module buffer and other critical data from > > boot, define "ima_policy=critical_data" on the boot command line. Since > > builtin policies are not persistent, a custom IMA policy must include > > the rule as well: measure func=CRITICAL_DATA label=modules > > > > To verify the template data hash value, first convert the buffer data > > hash to binary: > > grep "init_module" \ > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ > > tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum > > > > Reported-by: Ken Goldman <kgold@linux.ibm.com> > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > --- > > security/integrity/ima/ima_main.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/security/integrity/ima/ima_main.c > > b/security/integrity/ima/ima_main.c > > index c84e8c55333d..4b4348d681a6 100644 > > --- a/security/integrity/ima/ima_main.c > > +++ b/security/integrity/ima/ima_main.c > > @@ -902,6 +902,13 @@ static int ima_post_load_data(char *buf, loff_t size, > > return 0; > > } > > > > + /* > > + * Measure the init_module syscall buffer containing the ELF image. > > + */ > > + if (load_id == LOADING_MODULE) > > + ima_measure_critical_data("modules", "init_module", > > + buf, size, true, NULL, 0); > > No reason not to ack but could be just as well (passing checkpatch): Please review the tag usage as defined in https://docs.kernel.org/process/submitting-patches.html. > > if (load_id == LOADING_MODULE) > ima_measure_critical_data("modules", "init_module", buf, size, > true, NULL, 0); > > < 100 characters From what I understand, it's still preferable to stay under the 80 character limit, but checkpatch.pl will not complain. From https://www.kernel.org/doc/Documentation/process/maintainer-tip.rst: "The 80 character rule is not a strict rule, so please use common sense when breaking lines. Especially format strings should never be broken up." > > > + > > return 0; > > } > > > > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Thanks! Mimi
On Wed Mar 27, 2024 at 11:37 PM EET, Mimi Zohar wrote: > On Wed, 2024-03-27 at 18:54 +0200, Jarkko Sakkinen wrote: > > On Wed Mar 27, 2024 at 5:00 PM EET, Mimi Zohar wrote: > > > The init_module syscall loads an ELF image into kernel space without > > > measuring the buffer containing the ELF image. To close this kernel > > > module integrity gap, define a new critical-data record which includes > > > the hash of the ELF image. > > > > > > Instead of including the buffer data in the IMA measurement list, > > > include the hash of the buffer data to avoid large IMA measurement > > > list records. The buffer data hash would be the same value as the > > > finit_module syscall file hash. > > > > > > To enable measuring the init_module buffer and other critical data from > > > boot, define "ima_policy=critical_data" on the boot command line. Since > > > builtin policies are not persistent, a custom IMA policy must include > > > the rule as well: measure func=CRITICAL_DATA label=modules > > > > > > To verify the template data hash value, first convert the buffer data > > > hash to binary: > > > grep "init_module" \ > > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ > > > tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum > > > > > > Reported-by: Ken Goldman <kgold@linux.ibm.com> > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> > > > --- > > > security/integrity/ima/ima_main.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/security/integrity/ima/ima_main.c > > > b/security/integrity/ima/ima_main.c > > > index c84e8c55333d..4b4348d681a6 100644 > > > --- a/security/integrity/ima/ima_main.c > > > +++ b/security/integrity/ima/ima_main.c > > > @@ -902,6 +902,13 @@ static int ima_post_load_data(char *buf, loff_t size, > > > return 0; > > > } > > > > > > + /* > > > + * Measure the init_module syscall buffer containing the ELF image. > > > + */ > > > + if (load_id == LOADING_MODULE) > > > + ima_measure_critical_data("modules", "init_module", > > > + buf, size, true, NULL, 0); > > > > No reason not to ack but could be just as well (passing checkpatch): > > Please review the tag usage as defined in > https://docs.kernel.org/process/submitting-patches.html. > > > > > if (load_id == LOADING_MODULE) > > ima_measure_critical_data("modules", "init_module", buf, size, > > true, NULL, 0); > > > > < 100 characters > > From what I understand, it's still preferable to stay under the 80 character > limit, but checkpatch.pl will not complain. From > https://www.kernel.org/doc/Documentation/process/maintainer-tip.rst: > > "The 80 character rule is not a strict rule, so please use common sense when > breaking lines. Especially format strings should never be broken up." I agree with that is your decision to make (as maintainer of IMA)! BTW, I guess process/coding-style.rst would be better ref here because maintainer-tip.rst is meant only for arch/x86 tree (aka tip.git). That said, both maintainer-tip.rst and coding-style.rst recommend the same 80 character length. I have no idea whether 80 or 100 character should be considered as "recommended". The formatted string example is somewhat weird too because you should not break that even if it was 150 characters so it does not have any relation to 100 character limit... R, Jarkko
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index c84e8c55333d..4b4348d681a6 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -902,6 +902,13 @@ static int ima_post_load_data(char *buf, loff_t size, return 0; } + /* + * Measure the init_module syscall buffer containing the ELF image. + */ + if (load_id == LOADING_MODULE) + ima_measure_critical_data("modules", "init_module", + buf, size, true, NULL, 0); + return 0; }
The init_module syscall loads an ELF image into kernel space without measuring the buffer containing the ELF image. To close this kernel module integrity gap, define a new critical-data record which includes the hash of the ELF image. Instead of including the buffer data in the IMA measurement list, include the hash of the buffer data to avoid large IMA measurement list records. The buffer data hash would be the same value as the finit_module syscall file hash. To enable measuring the init_module buffer and other critical data from boot, define "ima_policy=critical_data" on the boot command line. Since builtin policies are not persistent, a custom IMA policy must include the rule as well: measure func=CRITICAL_DATA label=modules To verify the template data hash value, first convert the buffer data hash to binary: grep "init_module" \ /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum Reported-by: Ken Goldman <kgold@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> --- security/integrity/ima/ima_main.c | 7 +++++++ 1 file changed, 7 insertions(+)