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: Mimi Z. <zo...@li...> - 2011-09-12 20:35:20
|
On Mon, 2011-09-12 at 11:50 -0700, Subodh Nijsure wrote: > Hello, > > I have been using repo that Dmitry pointed to few days ago to get > familiar with IMA/EVM feature set. > > I work for a embedded software hw/sw company and we are greatly > interested in this feature, and exactly what we are looking to assure > customers that stuff running on our device is not being compromised. > > Anyway, I have compiled the kernel as described at > http://linux-ima.sourceforge.net/. For testing I am running the this > kernel to boot a Ubuntu system under Virtualbox. > > I am running evm_enable.sh script that is part of evm-utils. > > So I booted the system with kernel parameters rootflags=i_version > ima_audit=1 ima_appraise=fix evm=fix and ran the script > evm_label_all.sh. I created a test script call /bin/myscript.sh this > script had following security.* info > (This script just does echo "Hello World". ) > > # file: bin/myscript.sh > security.evm=0x02be034301cffd95fd237197ddf895d1e7e09ceed2 > security.ima=0x01c0c5e04cf9c08652faf0247afb19c6d708ccf5ba > > Now I rebooted this machine with kernel parameters rootflags=i_version > ima_audit=1 ima_tcb, then I updated /bin/myscript.sh to say echo > "Hello World1". Now this updates the security.* info on this file as > shown below. > > # file: bin/myscript.sh > security.evm=0x02acf40095e80e65a44c50724b723dea8363f1e26ebe > security.ima=0x01dc29420238f18fca4e06d970eec75725a36373ee > > My keyctl show following output: > > sudo keyctl list @u > 4 keys in keyring: > 666858261: --alswrv 0 0 user: kmk > 461487313: --alswrv 0 0 encrypted: evm-key > 715895674: --alswrv 0 0 keyring: _ima > 793114560: --alswrv 0 0 keyring: _evm > > > But I expected since I booted the system with ima_tcb I shouldn't be > able to execute the updated myscript.sh? What am doing wrong in doing > the basic IMA/EVM test? Nothing went wrong. :-) It's working as designed, permitting 'security.ima' and 'security.evm' to be updated, assuming the original values are valid. Modifying either security xattr offline will prevent the myscript.sh from being modified online. If 'security.ima' had been a digital signature, it wouldn't have been updated. As a result, executing myscripts.sh would subsequently fail. > I also see bunch of no evm keyring: -126, messages in the log, few > instances from the log shown below. > > [ 342.476799] type=1804 audit(1315852167.927:2686): pid=1548 uid=1000 > auid=4294967295 ses=4294967295 op="add_template_measure" > cause="hash_added" comm="bash" name="/bin/more" dev=sda1 ino=97 res=0 > [ 416.364434] no evm keyring: -126 > [ 425.707144] no evm keyring: -126 > [ 425.707883] type=1804 audit(1315852251.155:2687): pid=1583 uid=1000 > auid=4294967295 ses=4294967295 op="add_template_measure" > cause="hash_added" comm="bash" name="/usr/bin/scp" dev=sda1 ino=1424 > res=0 > [ 466.291967] no evm keyring: -126 > [ 466.292507] type=1804 audit(1315852291.743:2688): pid=1591 uid=1000 > auid=4294967295 ses=4294967295 op="add_template_measure" > cause="hash_added" comm="bash" name="/bin/ping" dev=sda1 ino=123 res=0 > [ 484.024376] no evm keyring: -126 > [ 484.024629] type=1804 audit(1315852309.475:2689): pid=1599 uid=1000 > auid=4294967295 ses=4294967295 op="add_template_measure" > cause="hash_added" comm="scp" name="/usr/bin/ssh" dev=sda1 ino=1512 > res=0 > [ 485.860190] no evm keyring: -126 > > > > A minor correct to FAQ section of http://linux-ima.sourceforge.net/. > The last question refers to kernel parameter ima-appraisal=fix and > should it not be ima_appraise=fix? > > > -Subodh Thanks for catching that. Mimi |
|
From: Subodh N. <nij...@gm...> - 2011-09-12 18:50:40
|
Hello, I have been using repo that Dmitry pointed to few days ago to get familiar with IMA/EVM feature set. I work for a embedded software hw/sw company and we are greatly interested in this feature, and exactly what we are looking to assure customers that stuff running on our device is not being compromised. Anyway, I have compiled the kernel as described at http://linux-ima.sourceforge.net/. For testing I am running the this kernel to boot a Ubuntu system under Virtualbox. I am running evm_enable.sh script that is part of evm-utils. So I booted the system with kernel parameters rootflags=i_version ima_audit=1 ima_appraise=fix evm=fix and ran the script evm_label_all.sh. I created a test script call /bin/myscript.sh this script had following security.* info (This script just does echo "Hello World". ) # file: bin/myscript.sh security.evm=0x02be034301cffd95fd237197ddf895d1e7e09ceed2 security.ima=0x01c0c5e04cf9c08652faf0247afb19c6d708ccf5ba Now I rebooted this machine with kernel parameters rootflags=i_version ima_audit=1 ima_tcb, then I updated /bin/myscript.sh to say echo "Hello World1". Now this updates the security.* info on this file as shown below. # file: bin/myscript.sh security.evm=0x02acf40095e80e65a44c50724b723dea8363f1e26ebe security.ima=0x01dc29420238f18fca4e06d970eec75725a36373ee My keyctl show following output: sudo keyctl list @u 4 keys in keyring: 666858261: --alswrv 0 0 user: kmk 461487313: --alswrv 0 0 encrypted: evm-key 715895674: --alswrv 0 0 keyring: _ima 793114560: --alswrv 0 0 keyring: _evm But I expected since I booted the system with ima_tcb I shouldn't be able to execute the updated myscript.sh? What am doing wrong in doing the basic IMA/EVM test? I also see bunch of no evm keyring: -126, messages in the log, few instances from the log shown below. [ 342.476799] type=1804 audit(1315852167.927:2686): pid=1548 uid=1000 auid=4294967295 ses=4294967295 op="add_template_measure" cause="hash_added" comm="bash" name="/bin/more" dev=sda1 ino=97 res=0 [ 416.364434] no evm keyring: -126 [ 425.707144] no evm keyring: -126 [ 425.707883] type=1804 audit(1315852251.155:2687): pid=1583 uid=1000 auid=4294967295 ses=4294967295 op="add_template_measure" cause="hash_added" comm="bash" name="/usr/bin/scp" dev=sda1 ino=1424 res=0 [ 466.291967] no evm keyring: -126 [ 466.292507] type=1804 audit(1315852291.743:2688): pid=1591 uid=1000 auid=4294967295 ses=4294967295 op="add_template_measure" cause="hash_added" comm="bash" name="/bin/ping" dev=sda1 ino=123 res=0 [ 484.024376] no evm keyring: -126 [ 484.024629] type=1804 audit(1315852309.475:2689): pid=1599 uid=1000 auid=4294967295 ses=4294967295 op="add_template_measure" cause="hash_added" comm="scp" name="/usr/bin/ssh" dev=sda1 ino=1512 res=0 [ 485.860190] no evm keyring: -126 A minor correct to FAQ section of http://linux-ima.sourceforge.net/. The last question refers to kernel parameter ima-appraisal=fix and should it not be ima_appraise=fix? -Subodh -Subodh |
|
From: Kasatkin, D. <dmi...@in...> - 2011-09-09 12:26:56
|
Hi, Yes, as kernel.org is down and no one knows when it comes back I put it back to gitorious as well https://meego.gitorious.org/meego-platform-security/ima-ksign - Dmitry On Fri, Sep 9, 2011 at 6:02 AM, Subodh Nijsure <nij...@gm...> wrote: > Hello Dmitry, > > >> Hello, >> >> Updated before LSS. >> >> >> All patches on the top of ima-2.6 (3.x.x) kernel are available here: >> git://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/ima-ksign.git >> >> Supporting utility for key handling and signing is available here: >> http://meego.gitorious.org/meego-platform-security/evm-utils >> > > Since kernel.org is still down, and its going to be while before it > will be up. Any chance one can access this code via gitorious.org? > > -Subodh Nijsure > > ------------------------------------------------------------------------------ > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Subodh N. <nij...@gm...> - 2011-09-09 03:02:09
|
Hello Dmitry, > Hello, > > Updated before LSS. > > > All patches on the top of ima-2.6 (3.x.x) kernel are available here: > git://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/ima-ksign.git > > Supporting utility for key handling and signing is available here: > http://meego.gitorious.org/meego-platform-security/evm-utils > Since kernel.org is still down, and its going to be while before it will be up. Any chance one can access this code via gitorious.org? -Subodh Nijsure |
|
From: Mimi Z. <zo...@li...> - 2011-09-08 00:31:02
|
Hi everyone, Since the linux-ima project webpage was last updated, a number of things have happened - trusted/encrypted keys were upstreamed, EVM is now in linux-next via the security-testing tree, and the dracut git repo contains Roberto's masterkey/integrity modules. These changes are now reflected in the updated linux-ima project webpage. Take a look and let me know what you think of the new format. thanks, Mimi |
|
From: Mimi Z. <zo...@li...> - 2011-08-23 19:57:46
|
On Tue, 2011-08-23 at 10:00 -0700, Sam Gandhi wrote: > Sorry if this is obvious. Is there a git repo that one can use if I > want to access the IMA-appriasal as well as EVM code that has been > sent out for review? > > Thanks. > /Sam Hi Sam, Perfect timing. I pushed out the latest patches earlier this morning and am working on updating the linux-ima website. Both #next-evm and #next-ima-appraisal branches are available from: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/ima-2.6.git thanks, Mimi |
|
From: Sam G. <sam...@gm...> - 2011-08-23 17:00:19
|
Sorry if this is obvious. Is there a git repo that one can use if I want to access the IMA-appriasal as well as EVM code that has been sent out for review? Thanks. /Sam |
|
From: David Li <w.d...@gm...> - 2011-08-19 20:49:31
|
Hi Rajiv,
One thing just occurred to me:
My machine was PXEbooted and diskless. Is this supported in trusted boot
measurement list?
Regards,
David
On Mon, Aug 8, 2011 at 7:45 PM, Rajiv Andrade <sr...@li...>wrote:
> Maybe I can help with the first section:
>
> On 08-08-2011 13:01, Mimi Zohar wrote:
> > On Fri, 2011-08-05 at 12:13 -0700, David Li wrote:
> >> Hi Mimi,
> >>
> >> A few more questions. Maybe this is because I am not familiar with the
> >> TPM specs.
> >>
> >> 1. For boot measurements, I don't quite understand the contents in
> >> tpm0/ascii_bios_measurements:
> >> ------------------------
> >> -bash-4.1# cat ascii_bios_measurements
> >> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version]
> >> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 []
> >> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 []
> >> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 []
> >> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 []
> >> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> <snip>
> >>
> >> The 1st col is the PCR#.
> > yes
> >
> >> Is the 2nd col the hash value corresponding to some BIOS executable or
> >> file? Why do some of them have the same hash value for the same PCR?
> > Yes, this is the hash. I'll defer to others on the mailing list about
> > the BIOS measurement specifics.
> It doesn't happen here, maybe the bios is registering such events
> duplicated by mistake? Can you send us the binary blob of such event log
> (binary_bios_measurements)?
> >> What's the 3rd col?
> The event type, according to tpm_bios.c:
>
> enum tcpa_event_types {
> PREBOOT = 0,
> POST_CODE,
> UNUSED,
> NO_ACTION,
> SEPARATOR,
> ACTION,
> EVENT_TAG,
> SCRTM_CONTENTS,
> SCRTM_VERSION,
> CPU_MICROCODE,
> PLATFORM_CONFIG_FLAGS,
> TABLE_OF_DEVICES,
> COMPACT_HASH,
> IPL,
> IPL_PARTITION_DATA,
> NONHOST_CODE,
> NONHOST_CONFIG,
> NONHOST_INFO,
> };
>
> It's odd though that there's a high bit being set for some of them, the
> same doesn't happen here. After looking at the binary log we can say who's
> the culprit, tpm_bios or the bios itself setting the event log incorrectly,
> and then come up with a workaround.
>
> Rajiv
>
>
|
|
From: David Li <w.d...@gm...> - 2011-08-14 00:30:18
|
Hi Rajiv,
Sorry I have been away from office. I 'll send you the binaries once I get
back in next week.
Regards,
David
On Mon, Aug 8, 2011 at 7:45 PM, Rajiv Andrade <sr...@li...>wrote:
> Maybe I can help with the first section:
>
> On 08-08-2011 13:01, Mimi Zohar wrote:
> > On Fri, 2011-08-05 at 12:13 -0700, David Li wrote:
> >> Hi Mimi,
> >>
> >> A few more questions. Maybe this is because I am not familiar with the
> >> TPM specs.
> >>
> >> 1. For boot measurements, I don't quite understand the contents in
> >> tpm0/ascii_bios_measurements:
> >> ------------------------
> >> -bash-4.1# cat ascii_bios_measurements
> >> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version]
> >> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 []
> >> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 []
> >> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 []
> >> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 []
> >> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
> >> <snip>
> >>
> >> The 1st col is the PCR#.
> > yes
> >
> >> Is the 2nd col the hash value corresponding to some BIOS executable or
> >> file? Why do some of them have the same hash value for the same PCR?
> > Yes, this is the hash. I'll defer to others on the mailing list about
> > the BIOS measurement specifics.
> It doesn't happen here, maybe the bios is registering such events
> duplicated by mistake? Can you send us the binary blob of such event log
> (binary_bios_measurements)?
> >> What's the 3rd col?
> The event type, according to tpm_bios.c:
>
> enum tcpa_event_types {
> PREBOOT = 0,
> POST_CODE,
> UNUSED,
> NO_ACTION,
> SEPARATOR,
> ACTION,
> EVENT_TAG,
> SCRTM_CONTENTS,
> SCRTM_VERSION,
> CPU_MICROCODE,
> PLATFORM_CONFIG_FLAGS,
> TABLE_OF_DEVICES,
> COMPACT_HASH,
> IPL,
> IPL_PARTITION_DATA,
> NONHOST_CODE,
> NONHOST_CONFIG,
> NONHOST_INFO,
> };
>
> It's odd though that there's a high bit being set for some of them, the
> same doesn't happen here. After looking at the binary log we can say who's
> the culprit, tpm_bios or the bios itself setting the event log incorrectly,
> and then come up with a workaround.
>
> Rajiv
>
>
|
|
From: Seiji M. <sei...@gm...> - 2011-08-09 19:42:21
|
On Sat, Aug 6, 2011 at 4:13 AM, David Li <w.d...@gm...> wrote: > 1. For boot measurements, I don't quite understand the contents in > tpm0/ascii_bios_measurements: > ------------------------ > -bash-4.1# cat ascii_bios_measurements > 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > <snip> > > The 1st col is the PCR#. > > Is the 2nd col the hash value corresponding to some BIOS executable or > file? Why do some of them have the same hash value for the same PCR? > > What's the 3rd col? > > Are all BIOS boot measurements stored in PCR0-7? yes. It seems this is EFI BIOS. 3rd col means: 80000008 EV_EFI_PLATFORM_FIRMWARE_BLOB 80000004 EV_EFI_BOOT_SERVICES_DRIVER 80000005 EV_EFI_RUNTIME_SERVICES_DRIVER The detail described by "TCG EFI Platform Specification" at http://www.trustedcomputinggroup.org/resources/tcg_efi_platform_specification_version_120_revision_10 -- Seiji |
|
From: Rajiv A. <sr...@li...> - 2011-08-09 03:15:56
|
Maybe I can help with the first section:
On 08-08-2011 13:01, Mimi Zohar wrote:
> On Fri, 2011-08-05 at 12:13 -0700, David Li wrote:
>> Hi Mimi,
>>
>> A few more questions. Maybe this is because I am not familiar with the
>> TPM specs.
>>
>> 1. For boot measurements, I don't quite understand the contents in
>> tpm0/ascii_bios_measurements:
>> ------------------------
>> -bash-4.1# cat ascii_bios_measurements
>> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version]
>> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 []
>> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 []
>> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 []
>> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 []
>> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 []
>> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
>> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
>> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
>> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 []
>> <snip>
>>
>> The 1st col is the PCR#.
> yes
>
>> Is the 2nd col the hash value corresponding to some BIOS executable or
>> file? Why do some of them have the same hash value for the same PCR?
> Yes, this is the hash. I'll defer to others on the mailing list about
> the BIOS measurement specifics.
It doesn't happen here, maybe the bios is registering such events duplicated by mistake? Can you send us the binary blob of such event log (binary_bios_measurements)?
>> What's the 3rd col?
The event type, according to tpm_bios.c:
enum tcpa_event_types {
PREBOOT = 0,
POST_CODE,
UNUSED,
NO_ACTION,
SEPARATOR,
ACTION,
EVENT_TAG,
SCRTM_CONTENTS,
SCRTM_VERSION,
CPU_MICROCODE,
PLATFORM_CONFIG_FLAGS,
TABLE_OF_DEVICES,
COMPACT_HASH,
IPL,
IPL_PARTITION_DATA,
NONHOST_CODE,
NONHOST_CONFIG,
NONHOST_INFO,
};
It's odd though that there's a high bit being set for some of them, the same doesn't happen here. After looking at the binary log we can say who's the culprit, tpm_bios or the bios itself setting the event log incorrectly, and then come up with a workaround.
Rajiv
|
|
From: Mimi Z. <zo...@li...> - 2011-08-08 16:01:38
|
On Fri, 2011-08-05 at 12:13 -0700, David Li wrote: > Hi Mimi, > > A few more questions. Maybe this is because I am not familiar with the > TPM specs. > > 1. For boot measurements, I don't quite understand the contents in > tpm0/ascii_bios_measurements: > ------------------------ > -bash-4.1# cat ascii_bios_measurements > 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > <snip> > > The 1st col is the PCR#. yes > Is the 2nd col the hash value corresponding to some BIOS executable or > file? Why do some of them have the same hash value for the same PCR? Yes, this is the hash. I'll defer to others on the mailing list about the BIOS measurement specifics. > What's the 3rd col? > > Are all BIOS boot measurements stored in PCR0-7? > Which PCR stores the boot_aggregate hash value? PCR 0 - 7 are stored in the IMA boot aggregate. > 2. For run time measurements > in /sys/kernel/security/ima/ascii_runtime_measurements: > ---------------------------------------------------------------- > 10 69d8e44453545591bedff7503598be62f0182cc6 ima > ee3b9bfb435482e64a5fca0ea60f2d3de0698dd9 boot_aggregate > 10 9ac8605fbbfa5d8ba909b635c7b7ad4a654a8eb5 ima > 78cdc547d4a9930ad6e7880f18a496785538e13e /init > 10 d0ac68b0927683a741efc10b886a76cb4c99926a ima > b30285be1079de1138b669180955a3ba54e1ee84 /init > 10 5c1abd04e37ae96ab0eea44ca8edb628c3053ae4 ima > 06309cd5fae6e9bddc73cd2fe8f3e6167106c227 ld-2.12.so > 10 516910c25617785536dd83ee8b621ce4a8097a0a ima > d0960a31ea00318947d0e2d7b866dbda69d1dc88 ld.so.cache > > why do we need both template and filedata hash values? It seems > ima_measure only uses the template hash value. The template hash is the hash of the template data, which includes the file hash and other file metadata. Templates, originally introduced with the Linux Integrity Module, extended the IMA infrastructure to attest to data other than file measurements, but for lack of users, was not upstreamed. ima-ng and ima-nglong are two proposed templates ima-ng and ima-nglong. ima-ng adds support for different hash algorithms, while ima-nglong adds the object uid, gid, and LSM object and subject labels. For a description of these templates, refer to http://sourceforge.net/mailarchive/forum.php?thread_name=1275914594-8808-5-git-send-email-zohar%40linux.vnet.ibm.com&forum_name=linux-ima-user > My calculated PCRAggr (re-calculated): DE C7 CC ED 07 06 22 F0 C8 2D > 95 2E A4 DE D5 AC F7 24 2B 99-bash-4.1# > doesn't match > -bash-4.1# cat /sys/devices/pnp0/00:09/pcrs | grep PCR-10 > PCR-10: B0 C0 81 C2 93 A7 42 09 60 01 99 68 80 69 C2 E1 25 04 38 0C If the measurement list is invalidated (<securityfs>/ima/violations), then it purposely doesn't match. To validate the measurement list, which contain invalidations, add the '--validate' option. > I noticed that in http://linux-ima.sourceforge.net/, > it's /sys/devices/pnp0/00.0a/pcrs but in my case, "pcrs" in is > in /sys/devices/pnp0/00.09/. Does this make a difference? No, it shouldn't make a difference. > Or maybe this is because the real-time measurement is continuously > changing and being updated but the values in "pcrs" doesn't. Is this > true? > > Thanks.and Regards, > > > David Where the PCRs are located, has nothing to do with the runtime measurements. thanks, Mimi |
|
From: David Li <w.d...@gm...> - 2011-08-05 19:13:43
|
Hi Mimi, A few more questions. Maybe this is because I am not familiar with the TPM specs. 1. For boot measurements, I don't quite understand the contents in tpm0/ascii_bios_measurements: ------------------------ -bash-4.1# cat ascii_bios_measurements 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] <snip> The 1st col is the PCR#. Is the 2nd col the hash value corresponding to some BIOS executable or file? Why do some of them have the same hash value for the same PCR? What's the 3rd col? Are all BIOS boot measurements stored in PCR0-7? Which PCR stores the boot_aggregate hash value? 2. For run time measurements in /sys/kernel/security/ima/ascii_runtime_measurements: ---------------------------------------------------------------- 10 69d8e44453545591bedff7503598be62f0182cc6 ima ee3b9bfb435482e64a5fca0ea60f2d3de0698dd9 boot_aggregate 10 9ac8605fbbfa5d8ba909b635c7b7ad4a654a8eb5 ima 78cdc547d4a9930ad6e7880f18a496785538e13e /init 10 d0ac68b0927683a741efc10b886a76cb4c99926a ima b30285be1079de1138b669180955a3ba54e1ee84 /init 10 5c1abd04e37ae96ab0eea44ca8edb628c3053ae4 ima 06309cd5fae6e9bddc73cd2fe8f3e6167106c227 ld-2.12.so 10 516910c25617785536dd83ee8b621ce4a8097a0a ima d0960a31ea00318947d0e2d7b866dbda69d1dc88 ld.so.cache why do we need both template and filedata hash values? It seems ima_measure only uses the template hash value. My calculated PCRAggr (re-calculated): DE C7 CC ED 07 06 22 F0 C8 2D 95 2E A4 DE D5 AC F7 24 2B 99-bash-4.1# doesn't match -bash-4.1# cat /sys/devices/pnp0/00:09/pcrs | grep PCR-10 PCR-10: B0 C0 81 C2 93 A7 42 09 60 01 99 68 80 69 C2 E1 25 04 38 0C I noticed that in http://linux-ima.sourceforge.net/, it's /sys/devices/pnp0/00.0a/pcrs but in my case, "pcrs" in is in /sys/devices/pnp0/00.09/. Does this make a difference? Or maybe this is because the real-time measurement is continuously changing and being updated but the values in "pcrs" doesn't. Is this true? Thanks.and Regards, David On Fri, Aug 5, 2011 at 8:23 AM, David Li <w.d...@gm...> wrote: > Hi Mimi, > > Yes, you are right. Now I got both. > I think the first time IMA wasn't really enabled properly. SO I only saw > tpm0 and no ima directory under /sys/kernel/security/. > Now I see both. > > Thanks for the help. > > David > > > > On Friday, August 5, 2011, Mimi Zohar <zo...@li...> wrote: > > On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: > >> > >> Hi Mimi, > >> > >> I used your latest test code and added ima_tcb and ima=on to the > >> kernel cmds. I still got the the same error. Any suggestions? - > >> Thanks. > >> > >> > >> -bash-4.1# ./ima_measure > /sys/kernel/security/tpm0/binary_bios_measurements --verbose > >> ### PCR HASH TEMPLATE-NAME > >> 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > >> 87248900926 ERROR: event name too long! > >> > >> > >> -bash-4.1# cat /proc/cmdline > >> initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw > >> ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > >> > >> Regards, > >> > >> > >> David > > > > Sorry, it's a bit confusing. There are two similarly named > > files /sys/kernel/security/tpm0/binary_bios_measurements > > and /sys/kernel/security/ima/binary_runtime_measurements. The input to > > ima_boot_aggregate is the first; the input to ima_measure is the latter. > > > > thanks, > > > > Mimi > > > > > > -- > Regards, > > David > > |
|
From: David Li <w.d...@gm...> - 2011-08-05 15:24:05
|
Hi Mimi, Yes, you are right. Now I got both. I think the first time IMA wasn't really enabled properly. SO I only saw tpm0 and no ima directory under /sys/kernel/security/. Now I see both. Thanks for the help. David On Friday, August 5, 2011, Mimi Zohar <zo...@li...> wrote: > On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: >> >> Hi Mimi, >> >> I used your latest test code and added ima_tcb and ima=on to the >> kernel cmds. I still got the the same error. Any suggestions? - >> Thanks. >> >> >> -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose >> ### PCR HASH TEMPLATE-NAME >> 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 >> 87248900926 ERROR: event name too long! >> >> >> -bash-4.1# cat /proc/cmdline >> initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw >> ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 >> >> Regards, >> >> >> David > > Sorry, it's a bit confusing. There are two similarly named > files /sys/kernel/security/tpm0/binary_bios_measurements > and /sys/kernel/security/ima/binary_runtime_measurements. The input to > ima_boot_aggregate is the first; the input to ima_measure is the latter. > > thanks, > > Mimi > > -- Regards, David |
|
From: Mimi Z. <zo...@li...> - 2011-08-05 14:48:37
|
On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: > > Hi Mimi, > > I used your latest test code and added ima_tcb and ima=on to the > kernel cmds. I still got the the same error. Any suggestions? - > Thanks. > > > -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose > ### PCR HASH TEMPLATE-NAME > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > 87248900926 ERROR: event name too long! > > > -bash-4.1# cat /proc/cmdline > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw > ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > > Regards, > > > David Sorry, it's a bit confusing. There are two similarly named files /sys/kernel/security/tpm0/binary_bios_measurements and /sys/kernel/security/ima/binary_runtime_measurements. The input to ima_boot_aggregate is the first; the input to ima_measure is the latter. thanks, Mimi |
|
From: David Li <w.d...@gm...> - 2011-08-05 00:57:23
|
Hi Mimi, I used your latest test code and added ima_tcb and ima=on to the kernel cmds. I still got the the same error. Any suggestions? - Thanks. -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose ### PCR HASH TEMPLATE-NAME 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 87248900926 ERROR: event name too long! -bash-4.1# cat /proc/cmdline initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 Regards, David On Thu, Aug 4, 2011 at 3:38 PM, Mimi Zohar <zo...@li...> wrote: > On Thu, 2011-08-04 at 10:55 -0700, David Li wrote: > > Hi Mimi, > > > > > > My HS22 is running RHEL6: > > > > > > -bash-4.1# uname -r > > 2.6.32-131.6.1.el6.cs.x86_64 > > > > > > The machine is PXEBooted: > > > > > > -bash-4.1# cat /proc/cmdline > > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw > > BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > > IMA is enabled in RHEL6 by default, but to collect measurements requires > replacing the null policy with the TCB one, by specifying the 'ima_tcb' > boot command line parameter. In addition, you might need to specify the > 'ima=on' parameter as well. > > Instead of downloading the individual IMA test programs and the LTP > 'glue' (eg. include files, definitions and stub functions) separately, > the new ltp-ima-standalone tar file includes the IMA tests. > ( > http://downloads.sf.net/project/linux-ima/linux-ima/ltp-ima-standalone.tar.gz > ) > (The IMA LTP test programs require the openssl and openssl-devel > packages.) > > thanks, > > Mimi > > > |
|
From: Mimi Z. <zo...@li...> - 2011-08-04 22:38:28
|
On Thu, 2011-08-04 at 10:55 -0700, David Li wrote: > Hi Mimi, > > > My HS22 is running RHEL6: > > > -bash-4.1# uname -r > 2.6.32-131.6.1.el6.cs.x86_64 > > > The machine is PXEBooted: > > > -bash-4.1# cat /proc/cmdline > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw > BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 IMA is enabled in RHEL6 by default, but to collect measurements requires replacing the null policy with the TCB one, by specifying the 'ima_tcb' boot command line parameter. In addition, you might need to specify the 'ima=on' parameter as well. Instead of downloading the individual IMA test programs and the LTP 'glue' (eg. include files, definitions and stub functions) separately, the new ltp-ima-standalone tar file includes the IMA tests. (http://downloads.sf.net/project/linux-ima/linux-ima/ltp-ima-standalone.tar.gz) (The IMA LTP test programs require the openssl and openssl-devel packages.) thanks, Mimi |
|
From: David Li <w.d...@gm...> - 2011-08-04 17:56:22
|
Hi Mimi, My HS22 is running RHEL6: -bash-4.1# uname -r 2.6.32-131.6.1.el6.cs.x86_64 The machine is PXEBooted: -bash-4.1# cat /proc/cmdline initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 Regards, David On Thu, Aug 4, 2011 at 10:37 AM, Mimi Zohar <zo...@li...>wrote: > On Tue, 2011-08-02 at 20:08 -0700, David Li wrote: > > Hi, > > > > I am new to TPM and IMA. I followed the following instructions : > > > > http://linux-ima.sourceforge.net/ > > > > to compile the test code. I got the following error in running > > ima_measure: > > > > -bash-4.1# ./ima_measure > /sys/kernel/security/tpm0/binary_bios_measurements --verbose > > ### PCR HASH TEMPLATE-NAME > > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > > 87248900926 ERROR: event name too long! > > > > Now I don't have a clue about the file name length 87248900926. > > > > Can anyone help to explain? > > The entire record is bogus. Is IMA enabled? The output should look > something like: > ### PCR HASH TEMPLATE-NAME > 0 010 1A 44 67 C5 8D 55 4B 75 EB EF 6F 90 02 C4 EE E6 95 61 71 B5 ima 2A > C8 > DF A1 69 23 65 5E F1 A6 48 87 21 EB 9F 97 2C 23 F1 12 boot_aggregate > > Which kernel are you running (uname -r)? What boot command line > parameters did you supply (cat /proc/cmdline)? > > thanks, > > Mimi > > |
|
From: Mimi Z. <zo...@li...> - 2011-08-04 17:38:05
|
On Tue, 2011-08-02 at 20:08 -0700, David Li wrote: > Hi, > > I am new to TPM and IMA. I followed the following instructions : > > http://linux-ima.sourceforge.net/ > > to compile the test code. I got the following error in running > ima_measure: > > -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose > ### PCR HASH TEMPLATE-NAME > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > 87248900926 ERROR: event name too long! > > Now I don't have a clue about the file name length 87248900926. > > Can anyone help to explain? The entire record is bogus. Is IMA enabled? The output should look something like: ### PCR HASH TEMPLATE-NAME 0 010 1A 44 67 C5 8D 55 4B 75 EB EF 6F 90 02 C4 EE E6 95 61 71 B5 ima 2A C8 DF A1 69 23 65 5E F1 A6 48 87 21 EB 9F 97 2C 23 F1 12 boot_aggregate Which kernel are you running (uname -r)? What boot command line parameters did you supply (cat /proc/cmdline)? thanks, Mimi |
|
From: David Li <w.d...@gm...> - 2011-08-03 03:08:29
|
Hi, I am new to TPM and IMA. I followed the following instructions : http://linux-ima.sourceforge.net/ to compile the test code. I got the following error in running ima_measure: -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose ### PCR HASH TEMPLATE-NAME 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 87248900926 ERROR: event name too long! Now I don't have a clue about the file name length 87248900926. Can anyone help to explain? Regards, David |
|
From: Dmitry K. <dmi...@no...> - 2011-05-02 11:45:14
|
Sorry.. Delivery test. |
|
From: Mimi Z. <zo...@li...> - 2011-04-27 14:05:58
|
Hi everyone, The latest EVM patches were posted a couple of weeks ago on lsm/lkml (http://lkml.org/lkml/2011/3/28/319). A version, rebased on the latest security-testing-2-6/#next, is available from: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/ima-2.6.git/#next-evm. To upstream the EVM patches, and subsequently the IMA-appraisal patches, requires a showing of community interest and support. Over the years, a number of different projects have been based on EVM/IMA-appraisal. I would really appreciate your taking the time to review/Ack the current patches. thanks, Mimi |
|
From: Shaz <sha...@gm...> - 2011-04-13 11:14:32
|
On Wed, Apr 13, 2011 at 1:51 PM, Sohail Khan <soh...@gm...> wrote: > Updates: > > I've also upgraded my kernel to a newer version but the problem remains the > same. The templates ima-ng & ima-nglong deals with the larger digest size > and LSM subject/objects receptively. I guess these templates will not > resolve the issue on hand. > > The numbers in the measurement list shows process IDs as I double checked > it. The problem is that these process IDs changes almost every time on > executing the same process. > > Is there any way to exclude these PIDs from the measurements? > > Regards, Sohail can you check what processes are associated with these ids. Once the you know which processes they are then they can be excluded AFAI remember. I am enabling IMA on my lappy to check it out. By the way [1] can explain how you can control what should be measured and not measured. Having background with SELinux I would go for labeling these files and then use lsm ima_policy to control the required behavior. Take care. [1] http://www.mjmwired.net/kernel/Documentation/ABI/testing/ima_policy -- Shahbaz Khan R&D Engineer, Tactical Engineering and Consultancy. http://shazkhan.wordpress.com/ http://pk.linkedin.com/pub/shahbaz-khan/20/116/b49 http://imsciences.edu.pk/serg/ http://csrdu.org/ +92-91-332-9915828 |
|
From: Sohail K. <soh...@gm...> - 2011-04-13 08:51:36
|
Updates: I've also upgraded my kernel to a newer version but the problem remains the same. The templates ima-ng & ima-nglong deals with the larger digest size and LSM subject/objects receptively. I guess these templates will not resolve the issue on hand. The numbers in the measurement list shows process IDs as I double checked it. The problem is that these process IDs changes almost every time on executing the same process. Is there any way to exclude these PIDs from the measurements? Regards, -- sohail On Wed, Apr 13, 2011 at 2:51 PM, waqar afridi <afr...@gm...>wrote: > > I am also having the Same problem, Installing New kernel also didnt > solved the Problem plus I dont know how to use templates. > > Are there any proper documentation of IMA and how to use Templates? > if yes can any one provide the Link? > > My kernel version is 2.6.35.11 > > On Sat, Apr 9, 2011 at 8:45 AM, Sohail Khan <soh...@gm...>wrote: > >> Thanks for the prompt reply. I am going for the newer kernel now and will >> update on the problem (if persist) soon. >> >> Regards, >> >> -- >> sohail >> >> On Fri, Apr 8, 2011 at 7:56 PM, Mimi Zohar <zo...@li...>wrote: >> >>> On Fri, 2011-04-08 at 11:27 +0800, Sohail Khan wrote: >>> > Hi, >>> > >>> > The measurement list shows numbers in the filename-hint. Some >>> > measurements are given below. Can anyone specify what are these >>> > numbers and what should I do if I don't want to measure whatever the >>> > numbers represent? >>> > >>> > I've comment out the BPRM_CHECK & the FILE_CHECK but again getting >>> > these numbers. The Kernel version is 2.6.30. >>> > >>> > --------------------------------------------------------- >>> > 10 1508a15636cdbce65789204533e16308d7318b9f ima >>> > 10b3c3c4461920e3823e0190168f5a6134c78acc libswt-gnome-gtk-3659.so >>> > 10 d8283931375705ce28a09e2e300b033c2de46eae ima >>> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6450 >>> > 10 a51b159cce6296eddcc40c5046f513829a87de96 ima >>> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6468 >>> > 10 cdc372dce5550ce20dceffd46c809e0b5ac612b5 ima >>> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6485 >>> > 10 fdc01dac5eaedf77599667109078e2409bc9670e ima >>> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6502 >>> > 10 bf2bb4bb74175a793cda379617371fc8a6b6adca ima >>> > ceb7eb4c7d34ebcbaa0837e70bf6b7d5603ecc5a firefox >>> > 10 23088bdc778e63ac862c9d218f246941bd84d0e5 ima >>> > ad918da9521707e09f2188696e8412e420ad974a libsqlite3.so >>> > >>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> > >>> > Thanks. >>> >>> Identifying records in the measurement list is a known issue, which will >>> be addressed by 'templates'. Two new templates are being defined, >>> ima-ng and ima-nglong, containing additional 'hint' information. For >>> more details on templates, refer to >>> http://sourceforge.net/mailarchive/message.php?msg_id=25460938. >>> >>> Controlling which files to measure, or not, is specified in the IMA >>> measurement policy. Refer to Documentation/ABI/testing/ima_policy of >>> the specific kernel. (Changes are backwards compatible, but not forward >>> compatible. FILE_CHECK, for example, was previously called PATH_CHECK.) >>> >>> As IMA was first enabled in 2.6.30 and has gone through numerous changes >>> since, how about upgrading to something a bit newer? >>> >>> thanks, >>> >>> Mimi >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev >> _______________________________________________ >> Linux-ima-user mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-ima-user >> >> > > > -- > *Waqar Afridi* > > |
|
From: waqar a. <afr...@gm...> - 2011-04-13 06:51:50
|
I am also having the Same problem, Installing New kernel also didnt solved the Problem plus I dont know how to use templates. Are there any proper documentation of IMA and how to use Templates? if yes can any one provide the Link? My kernel version is 2.6.35.11 On Sat, Apr 9, 2011 at 8:45 AM, Sohail Khan <soh...@gm...> wrote: > Thanks for the prompt reply. I am going for the newer kernel now and will > update on the problem (if persist) soon. > > Regards, > > -- > sohail > > On Fri, Apr 8, 2011 at 7:56 PM, Mimi Zohar <zo...@li...>wrote: > >> On Fri, 2011-04-08 at 11:27 +0800, Sohail Khan wrote: >> > Hi, >> > >> > The measurement list shows numbers in the filename-hint. Some >> > measurements are given below. Can anyone specify what are these >> > numbers and what should I do if I don't want to measure whatever the >> > numbers represent? >> > >> > I've comment out the BPRM_CHECK & the FILE_CHECK but again getting >> > these numbers. The Kernel version is 2.6.30. >> > >> > --------------------------------------------------------- >> > 10 1508a15636cdbce65789204533e16308d7318b9f ima >> > 10b3c3c4461920e3823e0190168f5a6134c78acc libswt-gnome-gtk-3659.so >> > 10 d8283931375705ce28a09e2e300b033c2de46eae ima >> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6450 >> > 10 a51b159cce6296eddcc40c5046f513829a87de96 ima >> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6468 >> > 10 cdc372dce5550ce20dceffd46c809e0b5ac612b5 ima >> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6485 >> > 10 fdc01dac5eaedf77599667109078e2409bc9670e ima >> > 5188431849b4613152fd7bdba6a3ff0a4fd6424b 6502 >> > 10 bf2bb4bb74175a793cda379617371fc8a6b6adca ima >> > ceb7eb4c7d34ebcbaa0837e70bf6b7d5603ecc5a firefox >> > 10 23088bdc778e63ac862c9d218f246941bd84d0e5 ima >> > ad918da9521707e09f2188696e8412e420ad974a libsqlite3.so >> > >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> > >> > Thanks. >> >> Identifying records in the measurement list is a known issue, which will >> be addressed by 'templates'. Two new templates are being defined, >> ima-ng and ima-nglong, containing additional 'hint' information. For >> more details on templates, refer to >> http://sourceforge.net/mailarchive/message.php?msg_id=25460938. >> >> Controlling which files to measure, or not, is specified in the IMA >> measurement policy. Refer to Documentation/ABI/testing/ima_policy of >> the specific kernel. (Changes are backwards compatible, but not forward >> compatible. FILE_CHECK, for example, was previously called PATH_CHECK.) >> >> As IMA was first enabled in 2.6.30 and has gone through numerous changes >> since, how about upgrading to something a bit newer? >> >> thanks, >> >> Mimi >> >> > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > -- *Waqar Afridi* |