Menu
▾
▴
linux-ima-user — Q&A for users of IMA
This list is closed, nobody may subscribe to it.
| 2007 |
Jan
|
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(26) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
(16) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(13) |
Oct
(10) |
Nov
(12) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
(28) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
(20) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(15) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(53) |
Mar
(15) |
Apr
(4) |
May
(2) |
Jun
(13) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(6) |
| 2013 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(8) |
| 2014 |
Jan
(17) |
Feb
(24) |
Mar
(8) |
Apr
(7) |
May
(18) |
Jun
(15) |
Jul
(5) |
Aug
(2) |
Sep
(49) |
Oct
(28) |
Nov
(7) |
Dec
(30) |
| 2015 |
Jan
(40) |
Feb
|
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(31) |
Jul
(33) |
Aug
(5) |
Sep
(20) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2016 |
Jan
(14) |
Feb
(29) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(19) |
Sep
(21) |
Oct
(2) |
Nov
(36) |
Dec
(30) |
| 2017 |
Jan
(101) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(29) |
Jun
(22) |
Jul
(7) |
Aug
(93) |
Sep
(27) |
Oct
(39) |
Nov
|
Dec
|
|
From: Richard G. B. <rg...@re...> - 2014-06-19 02:24:02
|
On 14/06/17, Mimi Zohar wrote:
> On Mon, 2014-06-16 at 15:52 -0400, Richard Guy Briggs wrote:
> > Replace spaces in op keyword labels in log output since userspace audit tools
> > can't parse orphaned keywords.
>
> The patch didn't apply cleanly to linux-integrity/#next. Please take a
> look at it (linux-integrity/#next-fixes).
Looks like just the change from "const char *op" to "static const char
op[]" in the context. Looks fine to me.
> thanks,
Thanks Mimi.
> Mimi
>
> > Reported-by: Steve Grubb <sg...@re...>
> > Signed-off-by: Richard Guy Briggs <rg...@re...>
> > ---
> > security/integrity/ima/ima_appraise.c | 2 +-
> > security/integrity/ima/ima_policy.c | 6 +++---
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> > index 734e946..61c95af 100644
> > --- a/security/integrity/ima/ima_appraise.c
> > +++ b/security/integrity/ima/ima_appraise.c
> > @@ -214,7 +214,7 @@ int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
> > hash_start = 1;
> > case IMA_XATTR_DIGEST:
> > if (iint->flags & IMA_DIGSIG_REQUIRED) {
> > - cause = "IMA signature required";
> > + cause = "IMA-signature-required";
> > status = INTEGRITY_FAIL;
> > break;
> > }
> > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> > index a9c3d3c..dbdc528 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -330,7 +330,7 @@ void __init ima_init_policy(void)
> > void ima_update_policy(void)
> > {
> > const char *op = "policy_update";
> > - const char *cause = "already exists";
> > + const char *cause = "already-exists";
> > int result = 1;
> > int audit_info = 0;
> >
> > @@ -654,7 +654,7 @@ ssize_t ima_parse_add_rule(char *rule)
> > /* Prevent installed policy from changing */
> > if (ima_rules != &ima_default_rules) {
> > integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> > - NULL, op, "already exists",
> > + NULL, op, "already-exists",
> > -EACCES, audit_info);
> > return -EACCES;
> > }
> > @@ -680,7 +680,7 @@ ssize_t ima_parse_add_rule(char *rule)
> > if (result) {
> > kfree(entry);
> > integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> > - NULL, op, "invalid policy", result,
> > + NULL, op, "invalid-policy", result,
> > audit_info);
> > return result;
> > }
- RGB
--
Richard Guy Briggs <rb...@re...>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
|
|
From: Dmitry K. <d.k...@sa...> - 2014-06-18 13:33:20
|
Hi, use copy command: cp /sys/kernel/security/ima/ascii_runtime_measurements /usr/share/abc.log Then send /usr/share/abc.log as you wish... - Dmitry On 18/06/14 07:03, M.AMJAD wrote: > Hello, > i create a file abc.log via touch (/usr/share/abc.log), then i > applied your suggested command > "cat securityfs /system/kernel/security/ima/ascii_runtime_measurements > /usr/share/abc.log" > > it produce the following like output > > > > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 fa86a27f42339a114b7cc783b4f8eecc86a03ef5 ima > da39a3ee5e6b4b0d3255bfef95601890afd80709 .xauthVSegIB > 10 941cc961977997331b356bd351fd118fa997865a ima > da39a3ee5e6b4b0d3255bfef95601890afd80709 joe.log > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 0000000000000000000000000000000000000000 ima > 0000000000000000000000000000000000000000 utmp > 10 b1f61a7ee0ab98d602efb2b6082e175d05fb96d9 ima > da39a3ee5e6b4b0d3255bfef95601890afd80709 abc.log > 10 9ca77a51309afcd364da46441c8f340a85ee451a ima > 21e9a21b4244e9e5ddb7503f7e27d37a5793ad48 /bin/vi > 10 10f8e161c760375b52ee648c17c7edba81f00459 ima > ddcbcf9392dbdde58c43533bf5e8c59b8ec9f3f2 virc > > > but i need to store a hash (SML) in a file like abc.log so that i can > transfer it to a remote server, please . > > > M.AMJAD > +92-345-9208119 > Please consider the environment before printing > > > On Tuesday, 17 June 2014, 17:54, Mimi Zohar <zo...@li...> > wrote: > > > On Mon, 2014-06-16 at 21:12 -0700, M.AMJAD wrote: > > > Hello everyone, > > i am new to IMA, i can see the integrated, boot etc hashes but how > > to store these hashes as a SML file on hard disk, and where , please. > > > Redirect the measurement list output: > cat <securityfs>/ima/ascii_runtime_measurements > <pathname> > > Mimi > > > > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > > > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user |
|
From: M.AMJAD <am...@ya...> - 2014-06-18 04:03:14
|
Hello, i create a file abc.log via touch (/usr/share/abc.log), then i applied your suggested command "cat securityfs /system/kernel/security/ima/ascii_runtime_measurements /usr/share/abc.log" it produce the following like output 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 fa86a27f42339a114b7cc783b4f8eecc86a03ef5 ima da39a3ee5e6b4b0d3255bfef95601890afd80709 .xauthVSegIB 10 941cc961977997331b356bd351fd118fa997865a ima da39a3ee5e6b4b0d3255bfef95601890afd80709 joe.log 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 0000000000000000000000000000000000000000 ima 0000000000000000000000000000000000000000 utmp 10 b1f61a7ee0ab98d602efb2b6082e175d05fb96d9 ima da39a3ee5e6b4b0d3255bfef95601890afd80709 abc.log 10 9ca77a51309afcd364da46441c8f340a85ee451a ima 21e9a21b4244e9e5ddb7503f7e27d37a5793ad48 /bin/vi 10 10f8e161c760375b52ee648c17c7edba81f00459 ima ddcbcf9392dbdde58c43533bf5e8c59b8ec9f3f2 virc but i need to store a hash (SML) in a file like abc.log so that i can transfer it to a remote server, please . M.AMJAD +92-345-9208119 On Tuesday, 17 June 2014, 17:54, Mimi Zohar <zo...@li...> wrote: On Mon, 2014-06-16 at 21:12 -0700, M.AMJAD wrote: > Hello everyone, > i am new to IMA, i can see the integrated, boot etc hashes but how > to store these hashes as a SML file on hard disk, and where , please. Redirect the measurement list output: cat <securityfs>/ima/ascii_runtime_measurements > <pathname> Mimi |
|
From: Mimi Z. <zo...@li...> - 2014-06-18 02:08:54
|
On Mon, 2014-06-16 at 15:52 -0400, Richard Guy Briggs wrote:
> Replace spaces in op keyword labels in log output since userspace audit tools
> can't parse orphaned keywords.
The patch didn't apply cleanly to linux-integrity/#next. Please take a
look at it (linux-integrity/#next-fixes).
thanks,
Mimi
> Reported-by: Steve Grubb <sg...@re...>
> Signed-off-by: Richard Guy Briggs <rg...@re...>
> ---
> security/integrity/ima/ima_appraise.c | 2 +-
> security/integrity/ima/ima_policy.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index 734e946..61c95af 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -214,7 +214,7 @@ int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
> hash_start = 1;
> case IMA_XATTR_DIGEST:
> if (iint->flags & IMA_DIGSIG_REQUIRED) {
> - cause = "IMA signature required";
> + cause = "IMA-signature-required";
> status = INTEGRITY_FAIL;
> break;
> }
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index a9c3d3c..dbdc528 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -330,7 +330,7 @@ void __init ima_init_policy(void)
> void ima_update_policy(void)
> {
> const char *op = "policy_update";
> - const char *cause = "already exists";
> + const char *cause = "already-exists";
> int result = 1;
> int audit_info = 0;
>
> @@ -654,7 +654,7 @@ ssize_t ima_parse_add_rule(char *rule)
> /* Prevent installed policy from changing */
> if (ima_rules != &ima_default_rules) {
> integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> - NULL, op, "already exists",
> + NULL, op, "already-exists",
> -EACCES, audit_info);
> return -EACCES;
> }
> @@ -680,7 +680,7 @@ ssize_t ima_parse_add_rule(char *rule)
> if (result) {
> kfree(entry);
> integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> - NULL, op, "invalid policy", result,
> + NULL, op, "invalid-policy", result,
> audit_info);
> return result;
> }
|
|
From: Mimi Z. <zo...@li...> - 2014-06-17 12:54:51
|
On Mon, 2014-06-16 at 21:12 -0700, M.AMJAD wrote: > Hello everyone, > i am new to IMA, i can see the integrated, boot etc hashes but how > to store these hashes as a SML file on hard disk, and where , please. Redirect the measurement list output: cat <securityfs>/ima/ascii_runtime_measurements > <pathname> Mimi |
|
From: M.AMJAD <am...@ya...> - 2014-06-17 04:12:21
|
Hello everyone, i am new to IMA, i can see the integrated, boot etc hashes but how to store these hashes as a SML file on hard disk, and where , please. M.AMJAD +92-345-9208119 |
|
From: Richard G. B. <rg...@re...> - 2014-06-16 19:52:45
|
Replace spaces in op keyword labels in log output since userspace audit tools
can't parse orphaned keywords.
Reported-by: Steve Grubb <sg...@re...>
Signed-off-by: Richard Guy Briggs <rg...@re...>
---
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_policy.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 734e946..61c95af 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -214,7 +214,7 @@ int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
hash_start = 1;
case IMA_XATTR_DIGEST:
if (iint->flags & IMA_DIGSIG_REQUIRED) {
- cause = "IMA signature required";
+ cause = "IMA-signature-required";
status = INTEGRITY_FAIL;
break;
}
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index a9c3d3c..dbdc528 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -330,7 +330,7 @@ void __init ima_init_policy(void)
void ima_update_policy(void)
{
const char *op = "policy_update";
- const char *cause = "already exists";
+ const char *cause = "already-exists";
int result = 1;
int audit_info = 0;
@@ -654,7 +654,7 @@ ssize_t ima_parse_add_rule(char *rule)
/* Prevent installed policy from changing */
if (ima_rules != &ima_default_rules) {
integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
- NULL, op, "already exists",
+ NULL, op, "already-exists",
-EACCES, audit_info);
return -EACCES;
}
@@ -680,7 +680,7 @@ ssize_t ima_parse_add_rule(char *rule)
if (result) {
kfree(entry);
integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
- NULL, op, "invalid policy", result,
+ NULL, op, "invalid-policy", result,
audit_info);
return result;
}
--
1.7.1
|
|
From: Richard G. B. <rg...@re...> - 2014-06-15 02:45:51
|
On 14/06/14, Mimi Zohar wrote: > On Sat, 2014-06-14 at 12:43 +0300, Dmitry Kasatkin wrote: > > On 14 June 2014 03:02, Richard Guy Briggs <rg...@re...> wrote: > > > On 14/04/02, Richard Guy Briggs wrote: > > >> On 14/04/02, Mimi Zohar wrote: > > >> > On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: > > >> > > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote: > > >> > > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: > > >> > > > > Hello Mimi, > > >> > > > > > > >> > > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote: > > >> > > > > > This change is already being upstreamed as commit 73a6b44 "Integrity: > > >> > > > > > Pass commname via get_task_comm()". > > >> > > > > > > >> > > > > While I was looking at Richard's patch, I noticed a few places where cause and > > >> > > > > op are logged and the string isn't tied together with a _ or -. These are in > > >> > > > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are > > >> > > > > these fixed upstream? Or should a patch be made? > > >> > > > > > >> > > > Nothing has changed in terms of 'cause' and 'op'. I would suggest > > >> > > > making the changes in integrity_audit.c: integrity_audit_msg(). > > >> > > >> That function could massage incoming text fields and convert spaces to > > >> hyphens or underscores, but I'd assume the right place to do it would be > > >> in the original text. If you suggest the former, it could just be done > > >> in audit_log_string(), but then grepping the source for error messages > > >> would not be nearly as useful. Is this what you were suggesting? > > >> > > >> > > The question is actually, do you know of anyone who is expecting the > > >> > > space, instead of a more 'audit standard' - or _ ? If not, we'll change > > >> > > it. If so, we'll discuss more :) > > >> > > > >> > CC'ing linux-ima-user as well. > > >> > > >> Thanks. > > > > > > Was there any response from linux-ima-user? > > > > > >> > Mimi > > >> > > >> - RGB > > > > > > > Hi, > > > > I will find this patch and have a look. > > As nobody has responded, I would assume it is safe to change. Thanks! :) > Mimi - RGB -- Richard Guy Briggs <rb...@re...> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 |
|
From: Mimi Z. <zo...@li...> - 2014-06-15 01:46:20
|
On Sat, 2014-06-14 at 12:43 +0300, Dmitry Kasatkin wrote: > On 14 June 2014 03:02, Richard Guy Briggs <rg...@re...> wrote: > > On 14/04/02, Richard Guy Briggs wrote: > >> On 14/04/02, Mimi Zohar wrote: > >> > On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: > >> > > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote: > >> > > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: > >> > > > > Hello Mimi, > >> > > > > > >> > > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote: > >> > > > > > This change is already being upstreamed as commit 73a6b44 "Integrity: > >> > > > > > Pass commname via get_task_comm()". > >> > > > > > >> > > > > While I was looking at Richard's patch, I noticed a few places where cause and > >> > > > > op are logged and the string isn't tied together with a _ or -. These are in > >> > > > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are > >> > > > > these fixed upstream? Or should a patch be made? > >> > > > > >> > > > Nothing has changed in terms of 'cause' and 'op'. I would suggest > >> > > > making the changes in integrity_audit.c: integrity_audit_msg(). > >> > >> That function could massage incoming text fields and convert spaces to > >> hyphens or underscores, but I'd assume the right place to do it would be > >> in the original text. If you suggest the former, it could just be done > >> in audit_log_string(), but then grepping the source for error messages > >> would not be nearly as useful. Is this what you were suggesting? > >> > >> > > The question is actually, do you know of anyone who is expecting the > >> > > space, instead of a more 'audit standard' - or _ ? If not, we'll change > >> > > it. If so, we'll discuss more :) > >> > > >> > CC'ing linux-ima-user as well. > >> > >> Thanks. > > > > Was there any response from linux-ima-user? > > > >> > Mimi > >> > >> - RGB > > > > Hi, > > I will find this patch and have a look. As nobody has responded, I would assume it is safe to change. Mimi |
|
From: Dmitry K. <dmi...@gm...> - 2014-06-14 09:43:22
|
On 14 June 2014 03:02, Richard Guy Briggs <rg...@re...> wrote: > On 14/04/02, Richard Guy Briggs wrote: >> On 14/04/02, Mimi Zohar wrote: >> > On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: >> > > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote: >> > > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: >> > > > > Hello Mimi, >> > > > > >> > > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote: >> > > > > > This change is already being upstreamed as commit 73a6b44 "Integrity: >> > > > > > Pass commname via get_task_comm()". >> > > > > >> > > > > While I was looking at Richard's patch, I noticed a few places where cause and >> > > > > op are logged and the string isn't tied together with a _ or -. These are in >> > > > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are >> > > > > these fixed upstream? Or should a patch be made? >> > > > >> > > > Nothing has changed in terms of 'cause' and 'op'. I would suggest >> > > > making the changes in integrity_audit.c: integrity_audit_msg(). >> >> That function could massage incoming text fields and convert spaces to >> hyphens or underscores, but I'd assume the right place to do it would be >> in the original text. If you suggest the former, it could just be done >> in audit_log_string(), but then grepping the source for error messages >> would not be nearly as useful. Is this what you were suggesting? >> >> > > The question is actually, do you know of anyone who is expecting the >> > > space, instead of a more 'audit standard' - or _ ? If not, we'll change >> > > it. If so, we'll discuss more :) >> > >> > CC'ing linux-ima-user as well. >> >> Thanks. > > Was there any response from linux-ima-user? > >> > Mimi >> >> - RGB > Hi, I will find this patch and have a look. Thanks, Dmitry > - RGB > > -- > Richard Guy Briggs <rb...@re...> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat > Remote, Ottawa, Canada > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user -- Thanks, Dmitry |
|
From: Richard G. B. <rg...@re...> - 2014-06-14 00:03:12
|
On 14/04/02, Richard Guy Briggs wrote: > On 14/04/02, Mimi Zohar wrote: > > On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: > > > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote: > > > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: > > > > > Hello Mimi, > > > > > > > > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote: > > > > > > This change is already being upstreamed as commit 73a6b44 "Integrity: > > > > > > Pass commname via get_task_comm()". > > > > > > > > > > While I was looking at Richard's patch, I noticed a few places where cause and > > > > > op are logged and the string isn't tied together with a _ or -. These are in > > > > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are > > > > > these fixed upstream? Or should a patch be made? > > > > > > > > Nothing has changed in terms of 'cause' and 'op'. I would suggest > > > > making the changes in integrity_audit.c: integrity_audit_msg(). > > That function could massage incoming text fields and convert spaces to > hyphens or underscores, but I'd assume the right place to do it would be > in the original text. If you suggest the former, it could just be done > in audit_log_string(), but then grepping the source for error messages > would not be nearly as useful. Is this what you were suggesting? > > > > The question is actually, do you know of anyone who is expecting the > > > space, instead of a more 'audit standard' - or _ ? If not, we'll change > > > it. If so, we'll discuss more :) > > > > CC'ing linux-ima-user as well. > > Thanks. Was there any response from linux-ima-user? > > Mimi > > - RGB - RGB -- Richard Guy Briggs <rb...@re...> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 |
|
From: Mimi Z. <zo...@li...> - 2014-05-15 13:57:56
|
On Thu, 2014-05-15 at 15:23 +0300, Dmitry Kasatkin wrote:
> On 15 May 2014 14:18, Mimi Zohar <zo...@li...> wrote:
> > On Thu, 2014-05-15 at 09:11 +0200, Roberto Sassu wrote:
> >> On 05/15/2014 08:55 AM, Dmitry Kasatkin wrote:
> >> > On 15 May 2014 00:32, Mimi Zohar <zo...@li...> wrote:
> >> >> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
> >> >>> For remote attestion it is important for the ima measurement values
> >> >>> to be platform-independent. Therefore integer fields to be hashed
> >> >>> must be converted to network order first.
> >> >>>
> >> >>> Signed-off-by: Andreas Steffen <and...@st...>
> >> >>> ---
> >> >>> security/integrity/ima/ima_crypto.c | 5 +++--
> >> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >> >>>
> >> >>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> >> >>> index 1bde8e6..8725bff 100644
> >> >>> --- a/security/integrity/ima/ima_crypto.c
> >> >>> +++ b/security/integrity/ima/ima_crypto.c
> >> >>> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> >> >>> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
> >> >>> u8 *data_to_hash = field_data[i].data;
> >> >>> u32 datalen = field_data[i].len;
> >> >>> + u32 datalen_to_hash = htonl(datalen);
> >> >>>
> >> >>> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
> >> >>> rc = crypto_shash_update(&desc.shash,
> >> >>> - (const u8 *) &field_data[i].len,
> >> >>> - sizeof(field_data[i].len));
> >> >>> + (const u8 *) &datalen_to_hash,
> >> >>> + sizeof(datalen_to_hash));
> >> >>> if (rc)
> >> >>> break;
> >> >>> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
> >> >>
> >> >> After thinking about this some more, and discussing it with Roberto and
> >> >> Dave, this change is probably unnecessary. Assuming the measurement
> >> >> list is sent in host native format, a hash of the template data will
> >> >> match the value contained in the measurement list. Only if the template
> >> >> data is converted to network byte order, prior to sending it, would
> >> >> there be a problem.
> >> >>
> >> >> The PCR value provides a good heuristic for determining the data
> >> >> endianness.
> >> >>
> >> >
> >> > So you suggestion is try to change endianness if PCR reconstruction fails?
> >
> > No, from the raw data the endianness can be heuristically determined. So
> > if the raw data is sent to the attestation server, there is no problem.
> > As Roberto pointed out, we need a method of indicating this in the
> > integrity reports.
> >
>
> Yes. It is very easy to check length field and understand what endianness is.
> It will be very big number if it is incorrect.
>
> But what about PCR. I have not understood that.
The first element in the measurement list is the PCR number, normally 10
for IMA. Currently there are only 23 PCR registers. So it should be
simple to determine the endianness.
At this point, I don't see a need for this patch to be upstreamed.
thanks,
Mimi
|
|
From: Dmitry K. <dmi...@gm...> - 2014-05-15 12:24:04
|
On 15 May 2014 14:18, Mimi Zohar <zo...@li...> wrote:
> On Thu, 2014-05-15 at 09:11 +0200, Roberto Sassu wrote:
>> On 05/15/2014 08:55 AM, Dmitry Kasatkin wrote:
>> > On 15 May 2014 00:32, Mimi Zohar <zo...@li...> wrote:
>> >> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
>> >>> For remote attestion it is important for the ima measurement values
>> >>> to be platform-independent. Therefore integer fields to be hashed
>> >>> must be converted to network order first.
>> >>>
>> >>> Signed-off-by: Andreas Steffen <and...@st...>
>> >>> ---
>> >>> security/integrity/ima/ima_crypto.c | 5 +++--
>> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
>> >>> index 1bde8e6..8725bff 100644
>> >>> --- a/security/integrity/ima/ima_crypto.c
>> >>> +++ b/security/integrity/ima/ima_crypto.c
>> >>> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
>> >>> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
>> >>> u8 *data_to_hash = field_data[i].data;
>> >>> u32 datalen = field_data[i].len;
>> >>> + u32 datalen_to_hash = htonl(datalen);
>> >>>
>> >>> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
>> >>> rc = crypto_shash_update(&desc.shash,
>> >>> - (const u8 *) &field_data[i].len,
>> >>> - sizeof(field_data[i].len));
>> >>> + (const u8 *) &datalen_to_hash,
>> >>> + sizeof(datalen_to_hash));
>> >>> if (rc)
>> >>> break;
>> >>> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
>> >>
>> >> After thinking about this some more, and discussing it with Roberto and
>> >> Dave, this change is probably unnecessary. Assuming the measurement
>> >> list is sent in host native format, a hash of the template data will
>> >> match the value contained in the measurement list. Only if the template
>> >> data is converted to network byte order, prior to sending it, would
>> >> there be a problem.
>> >>
>> >> The PCR value provides a good heuristic for determining the data
>> >> endianness.
>> >>
>> >
>> > So you suggestion is try to change endianness if PCR reconstruction fails?
>
> No, from the raw data the endianness can be heuristically determined. So
> if the raw data is sent to the attestation server, there is no problem.
> As Roberto pointed out, we need a method of indicating this in the
> integrity reports.
>
Yes. It is very easy to check length field and understand what endianness is.
It will be very big number if it is incorrect.
But what about PCR. I have not understood that.
- Dmitry
> Mimi
>
>> >
>> > BTW.
>> >
>> > Remote attestation agent is sending measurement list to the remote
>> > attestation server.
>> > Can agent also send "endianness" of the attested client?
>> >
>>
>> Hi Dmitry
>>
>> I think yes. I'm not aware of a standardized way to do it,
>> but this information could be included in integrity reports
>> (within the XML whose format is defined by the TCG).
>
>
--
Thanks,
Dmitry
|
|
From: Mimi Z. <zo...@li...> - 2014-05-15 11:19:59
|
On Thu, 2014-05-15 at 09:11 +0200, Roberto Sassu wrote:
> On 05/15/2014 08:55 AM, Dmitry Kasatkin wrote:
> > On 15 May 2014 00:32, Mimi Zohar <zo...@li...> wrote:
> >> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
> >>> For remote attestion it is important for the ima measurement values
> >>> to be platform-independent. Therefore integer fields to be hashed
> >>> must be converted to network order first.
> >>>
> >>> Signed-off-by: Andreas Steffen <and...@st...>
> >>> ---
> >>> security/integrity/ima/ima_crypto.c | 5 +++--
> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> >>> index 1bde8e6..8725bff 100644
> >>> --- a/security/integrity/ima/ima_crypto.c
> >>> +++ b/security/integrity/ima/ima_crypto.c
> >>> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> >>> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
> >>> u8 *data_to_hash = field_data[i].data;
> >>> u32 datalen = field_data[i].len;
> >>> + u32 datalen_to_hash = htonl(datalen);
> >>>
> >>> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
> >>> rc = crypto_shash_update(&desc.shash,
> >>> - (const u8 *) &field_data[i].len,
> >>> - sizeof(field_data[i].len));
> >>> + (const u8 *) &datalen_to_hash,
> >>> + sizeof(datalen_to_hash));
> >>> if (rc)
> >>> break;
> >>> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
> >>
> >> After thinking about this some more, and discussing it with Roberto and
> >> Dave, this change is probably unnecessary. Assuming the measurement
> >> list is sent in host native format, a hash of the template data will
> >> match the value contained in the measurement list. Only if the template
> >> data is converted to network byte order, prior to sending it, would
> >> there be a problem.
> >>
> >> The PCR value provides a good heuristic for determining the data
> >> endianness.
> >>
> >
> > So you suggestion is try to change endianness if PCR reconstruction fails?
No, from the raw data the endianness can be heuristically determined. So
if the raw data is sent to the attestation server, there is no problem.
As Roberto pointed out, we need a method of indicating this in the
integrity reports.
Mimi
> >
> > BTW.
> >
> > Remote attestation agent is sending measurement list to the remote
> > attestation server.
> > Can agent also send "endianness" of the attested client?
> >
>
> Hi Dmitry
>
> I think yes. I'm not aware of a standardized way to do it,
> but this information could be included in integrity reports
> (within the XML whose format is defined by the TCG).
|
|
From: Roberto S. <rob...@po...> - 2014-05-15 07:12:14
|
On 05/15/2014 08:55 AM, Dmitry Kasatkin wrote:
> On 15 May 2014 00:32, Mimi Zohar <zo...@li...> wrote:
>> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
>>> For remote attestion it is important for the ima measurement values
>>> to be platform-independent. Therefore integer fields to be hashed
>>> must be converted to network order first.
>>>
>>> Signed-off-by: Andreas Steffen <and...@st...>
>>> ---
>>> security/integrity/ima/ima_crypto.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
>>> index 1bde8e6..8725bff 100644
>>> --- a/security/integrity/ima/ima_crypto.c
>>> +++ b/security/integrity/ima/ima_crypto.c
>>> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
>>> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
>>> u8 *data_to_hash = field_data[i].data;
>>> u32 datalen = field_data[i].len;
>>> + u32 datalen_to_hash = htonl(datalen);
>>>
>>> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
>>> rc = crypto_shash_update(&desc.shash,
>>> - (const u8 *) &field_data[i].len,
>>> - sizeof(field_data[i].len));
>>> + (const u8 *) &datalen_to_hash,
>>> + sizeof(datalen_to_hash));
>>> if (rc)
>>> break;
>>> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
>>
>> After thinking about this some more, and discussing it with Roberto and
>> Dave, this change is probably unnecessary. Assuming the measurement
>> list is sent in host native format, a hash of the template data will
>> match the value contained in the measurement list. Only if the template
>> data is converted to network byte order, prior to sending it, would
>> there be a problem.
>>
>> The PCR value provides a good heuristic for determining the data
>> endianness.
>>
>
> So you suggestion is try to change endianness if PCR reconstruction fails?
>
>
> BTW.
>
> Remote attestation agent is sending measurement list to the remote
> attestation server.
> Can agent also send "endianness" of the attested client?
>
Hi Dmitry
I think yes. I'm not aware of a standardized way to do it,
but this information could be included in integrity reports
(within the XML whose format is defined by the TCG).
Roberto
> - Dmitry
>
>> Mimi
>>
>
>
>
|
|
From: Dmitry K. <dmi...@gm...> - 2014-05-15 06:55:45
|
On 15 May 2014 00:32, Mimi Zohar <zo...@li...> wrote:
> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
>> For remote attestion it is important for the ima measurement values
>> to be platform-independent. Therefore integer fields to be hashed
>> must be converted to network order first.
>>
>> Signed-off-by: Andreas Steffen <and...@st...>
>> ---
>> security/integrity/ima/ima_crypto.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
>> index 1bde8e6..8725bff 100644
>> --- a/security/integrity/ima/ima_crypto.c
>> +++ b/security/integrity/ima/ima_crypto.c
>> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
>> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
>> u8 *data_to_hash = field_data[i].data;
>> u32 datalen = field_data[i].len;
>> + u32 datalen_to_hash = htonl(datalen);
>>
>> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
>> rc = crypto_shash_update(&desc.shash,
>> - (const u8 *) &field_data[i].len,
>> - sizeof(field_data[i].len));
>> + (const u8 *) &datalen_to_hash,
>> + sizeof(datalen_to_hash));
>> if (rc)
>> break;
>> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
>
> After thinking about this some more, and discussing it with Roberto and
> Dave, this change is probably unnecessary. Assuming the measurement
> list is sent in host native format, a hash of the template data will
> match the value contained in the measurement list. Only if the template
> data is converted to network byte order, prior to sending it, would
> there be a problem.
>
> The PCR value provides a good heuristic for determining the data
> endianness.
>
So you suggestion is try to change endianness if PCR reconstruction fails?
BTW.
Remote attestation agent is sending measurement list to the remote
attestation server.
Can agent also send "endianness" of the attested client?
- Dmitry
> Mimi
>
--
Thanks,
Dmitry
|
|
From: Mimi Z. <zo...@li...> - 2014-05-14 21:33:36
|
On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
> For remote attestion it is important for the ima measurement values
> to be platform-independent. Therefore integer fields to be hashed
> must be converted to network order first.
>
> Signed-off-by: Andreas Steffen <and...@st...>
> ---
> security/integrity/ima/ima_crypto.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 1bde8e6..8725bff 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
> u8 *data_to_hash = field_data[i].data;
> u32 datalen = field_data[i].len;
> + u32 datalen_to_hash = htonl(datalen);
>
> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
> rc = crypto_shash_update(&desc.shash,
> - (const u8 *) &field_data[i].len,
> - sizeof(field_data[i].len));
> + (const u8 *) &datalen_to_hash,
> + sizeof(datalen_to_hash));
> if (rc)
> break;
> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
After thinking about this some more, and discussing it with Roberto and
Dave, this change is probably unnecessary. Assuming the measurement
list is sent in host native format, a hash of the template data will
match the value contained in the measurement list. Only if the template
data is converted to network byte order, prior to sending it, would
there be a problem.
The PCR value provides a good heuristic for determining the data
endianness.
Mimi
|
|
From: Mimi Z. <zo...@li...> - 2014-05-14 14:09:27
|
On Wed, 2014-05-14 at 09:02 -0400, Mimi Zohar wrote:
> On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
> > For remote attestion it is important for the ima measurement values
> > to be platform-independent. Therefore integer fields to be hashed
> > must be converted to network order first.
> >
> > Signed-off-by: Andreas Steffen <and...@st...>
>
> Prior to this patch, verifying the measurement list didn't require any
> knowledge of the template format. The local host would calculate the
> hash on the entire template data and compare it with the hash value in
> the measurement list. Now, verifying the measurement list requires
> parsing the template data and converting each of the length fields from
> network byte order to host order.
Basically, if the length fields are included in the hash in network byte
order, then the lengths fields in the binary runtime measurement list
should also be converted to use network byte order.
diff --git a/security/integrity/ima/ima_template_lib.c b/security/integrity/ima/ima_template_lib.c
index 1506f02..63c6a8a 100644
--- a/security/integrity/ima/ima_template_lib.c
+++ b/security/integrity/ima/ima_template_lib.c
@@ -103,8 +103,10 @@ static void ima_show_template_data_binary(struct seq_file *m,
u32 len = (show == IMA_SHOW_BINARY_OLD_STRING_FMT) ?
strlen(field_data->data) : field_data->len;
- if (show != IMA_SHOW_BINARY_NO_FIELD_LEN)
- ima_putc(m, &len, sizeof(len));
+ if (show != IMA_SHOW_BINARY_NO_FIELD_LEN) {
+ u32 nl_len = htonl(len);
+ ima_putc(m, &nl_len, sizeof(len));
+ }
if (!len)
return;
Mimi
|
|
From: Mimi Z. <zo...@li...> - 2014-05-14 13:03:59
|
On Wed, 2014-05-07 at 18:13 +0200, Andreas Steffen wrote:
> For remote attestion it is important for the ima measurement values
> to be platform-independent. Therefore integer fields to be hashed
> must be converted to network order first.
>
> Signed-off-by: Andreas Steffen <and...@st...>
Prior to this patch, verifying the measurement list didn't require any
knowledge of the template format. The local host would calculate the
hash on the entire template data and compare it with the hash value in
the measurement list. Now, verifying the measurement list requires
parsing the template data and converting each of the length fields from
network byte order to host order.
Mimi
> ---
> security/integrity/ima/ima_crypto.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 1bde8e6..8725bff 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
> u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
> u8 *data_to_hash = field_data[i].data;
> u32 datalen = field_data[i].len;
> + u32 datalen_to_hash = htonl(datalen);
>
> if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
> rc = crypto_shash_update(&desc.shash,
> - (const u8 *) &field_data[i].len,
> - sizeof(field_data[i].len));
> + (const u8 *) &datalen_to_hash,
> + sizeof(datalen_to_hash));
> if (rc)
> break;
> } else if (strcmp(td->fields[i]->field_id, "n") == 0) {
|
|
From: Mimi Z. <zo...@li...> - 2014-05-08 11:18:19
|
On Thu, 2014-05-08 at 10:13 +0300, Dmitry Kasatkin wrote: > On 6 May 2014 23:42, Mimi Zohar <zo...@li...> wrote: > > On Mon, 2014-05-05 at 12:28 +0200, Andreas Steffen wrote: > >> Hello Mimi, > >> > >> here is the datalen_to_hash patch. > >> > >> Best regards > >> > >> Andreas > >> > >> On 02.05.2014 14:52, Mimi Zohar wrote: > >> > > >> > Andreas, did you want to post the patch? > > > > Thanks! Would you mind adding a short patch description? In the > > future, please post the patch inline. > > > > thanks, > > > > Mimi > > > > Hi, > > > binary_runtime_measurements also contains platform specific field > length encoding... To summarize the discussion, the kernel does not need to convert from host to platform independent byte order. A userspace app running on the host system can do the conversion before sending the data. The only fields of concern are those included in the hash calculation. thanks, Mimi |
|
From: Dmitry K. <dmi...@gm...> - 2014-05-08 07:13:22
|
On 6 May 2014 23:42, Mimi Zohar <zo...@li...> wrote: > On Mon, 2014-05-05 at 12:28 +0200, Andreas Steffen wrote: >> Hello Mimi, >> >> here is the datalen_to_hash patch. >> >> Best regards >> >> Andreas >> >> On 02.05.2014 14:52, Mimi Zohar wrote: >> > >> > Andreas, did you want to post the patch? > > Thanks! Would you mind adding a short patch description? In the > future, please post the patch inline. > > thanks, > > Mimi > Hi, binary_runtime_measurements also contains platform specific field length encoding... -- Thanks, Dmitry |
|
From: Andreas S. <and...@st...> - 2014-05-07 16:13:08
|
For remote attestion it is important for the ima measurement values
to be platform-independent. Therefore integer fields to be hashed
must be converted to network order first.
Signed-off-by: Andreas Steffen <and...@st...>
---
security/integrity/ima/ima_crypto.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 1bde8e6..8725bff 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -170,11 +170,12 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
u8 buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
u8 *data_to_hash = field_data[i].data;
u32 datalen = field_data[i].len;
+ u32 datalen_to_hash = htonl(datalen);
if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
rc = crypto_shash_update(&desc.shash,
- (const u8 *) &field_data[i].len,
- sizeof(field_data[i].len));
+ (const u8 *) &datalen_to_hash,
+ sizeof(datalen_to_hash));
if (rc)
break;
} else if (strcmp(td->fields[i]->field_id, "n") == 0) {
--
1.9.1
|
|
From: Mimi Z. <zo...@li...> - 2014-05-06 20:43:48
|
On Mon, 2014-05-05 at 12:28 +0200, Andreas Steffen wrote: > Hello Mimi, > > here is the datalen_to_hash patch. > > Best regards > > Andreas > > On 02.05.2014 14:52, Mimi Zohar wrote: > > > > Andreas, did you want to post the patch? Thanks! Would you mind adding a short patch description? In the future, please post the patch inline. thanks, Mimi |
|
From: Andreas S. <and...@st...> - 2014-05-05 10:35:04
|
Hi Mimi, over the weekend I wrote a HOWTO on remote attestation using Ubuntu 14.04 LTS, the strongSwan VPN solution and the strongTNC policy manager. http://wiki.strongswan.org/projects/strongswan/wiki/IMA Kind regards Andreas ====================================================================== Andreas Steffen and...@st... strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== |
|
From: Andreas S. <and...@st...> - 2014-05-05 10:28:39
|
Hello Mimi, here is the datalen_to_hash patch. Best regards Andreas On 02.05.2014 14:52, Mimi Zohar wrote: > > Andreas, did you want to post the patch? > ====================================================================== Andreas Steffen and...@st... strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== |
32 messages has been excluded from this view by a project administrator.
