linux-ima-user — Q&A for users of IMA

[Linux-ima-user] question about measuring modules

[z. <zha...@qq...>]

hello, 
    I have another question about measuring modules. Why did not you measuring executable files just like measuring modules? 
     

 
------------------ Original ------------------
From:  "zhangkai"<zha...@ic...>;
Date:  Tue, Nov 3, 2009 03:01 PM
To:  "linux-ima-user"<lin...@li...>; 

Subject:  question about measure modules

 
 hello,
    I am reading ima sourecode, why the "ima_measure_kernel_module" function does not be called by any function?
    Thank you.

[Linux-ima-user] question about measure modules

[z. <zha...@ic...>]

hello,
    I am reading ima sourecode, why the "ima_measure_kernel_module" function does not be called by any function?
    Thank you.

Re: [Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Mimi Z. <zo...@li...>]

On Tue, 2009-10-13 at 16:02 +0200, Roberto Sassu wrote: 
> On Tuesday 13 October 2009 14:17:02 Mimi Zohar wrote:
> > On Tue, 2009-10-13 at 10:18 +0200, Roberto Sassu wrote:
> > > On Tuesday 13 October 2009 01:24:17 Mimi Zohar wrote:
> > > > On Mon, 2009-10-12 at 11:15 +0200, Roberto Sassu wrote:
> > > > > Hi all
> > > > >
> > > > > i have tried to write an IMA policy in order to measure all files, in
> > > > > a system with SELinux installed, accessed by subjects with security
> > > > > context starting as "system_u:system_r" and to skip files with label
> > > > > "initrc_var_run_t" (/var/run/utmp) which is the origin of multiple
> > > > > violations.
> > > > > The policy is:
> > > > >
> > > > > --------
> > > > > dont_measure obj_type=initrc_var_run_t
> > > > > measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
> > > > > measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
> > > > > --------
> > > >
> > > > The policy order, as you realized, is important. The action is based on
> > > > the first rule matched. Are you running an SELinux targeted policy?  To
> > > > see the LSM labels associated with a process execute: ps -aeZ. With a
> > > > targeted policy, a number of processes are run as unconfined. Instead
> > > > of the above policy rules, please try these:
> > > >
> > > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> > > > measure func=PATH_CHECK mask=MAY_READ uid=0
> > > >
> > > > Thanks!
> > > >
> > > > Mimi
> > >
> > > I'm running Fedora 11 with the targeted policy in a virtual machine and i
> > > log in with ssh. By enabling some system services i encountered other
> > > some violations. One is caused by the service "pcsd" which i disabled for
> > > now. I added other few exceptions in the policy you suggested, to clean
> > > the others:
> > >
> > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=sendmail_var_run_t
> > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=hald_var_run_t
> > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=consolekit_log_t
> > > measure func=PATH_CHECK mask=MAY_READ uid=0
> > 
> > For now, with these types of rules we can eliminate the
> > ToMToU/open_writers auditing messages and prevent invalidating the PCR,
> > but before adding these types of rules, we should really understand the
> > underlying problem.
> > 
> > For example:
> > ck-history opens for read /var/log/ConsoleKit/history, while
> > console-kit-daemon has it open for write. (open-writers)
> > 
> > # lsof +c 0  /var/log/ConsoleKit/history
> > 
> > COMMAND          PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
> > console-kit-dae 2067 root    9w   REG    8,2  1550104 1196033
> > /var/log/ConsoleKit/history
> > 
> > So, is it necessary for console-kit-daemon to open for write and never
> > close /var/log/ConsoleKit/history or should console-kit-daemon be
> > modified?
> > 
> > Mimi
> > 
> 
> 
> I'm thinking the concept of violation is too restrictive.
> In the case of "read_writers" checking, a violation can happens if a reader 
> tries to open a file which is already opened for writing by another process. 
> But it's possible that the writer has not already modified the file.
> If it is true that the reader sees modifications done by the writer only after 
> the inode "i_version" field is updated, we can report in the measurement list 
> that there's a possible violation but we can delay the detection until the 
> reader ends to use the resource.
> This is a possible sequence of operations done by two processes A, B which 
> they can be considered safe:
> 
> 1) Process A opens file "file1" for writing
> 
> 2) Process B opens file "file1" for reading ---> IMA in the ima_path_check() 
> function store inside the ima_iint_cache structure of the inode of file1 these 
> data {pid of reader process, current i_version } and report in the measurement 
> list that there is a possible violation.
> 
> 3) Process B close file "file1"---> IMA in the ima_file_free() function verifies 
> the data {pid, i_version} stored previously: if the reader ends to use the file 
> and the i_version is not changed, IMA reports in its measurement list that the 
> possible violation is solved.
> 
> 4) Process A writes on "file1" ---> OK, data are changed but process B used the 
> previously version of the file. 

This would only work if the i_version is updated after every write,
which isn't the case for mmapped files.

Mimi

Re: [Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Roberto S. <rob...@po...>]

On Tuesday 13 October 2009 14:17:02 Mimi Zohar wrote:
> On Tue, 2009-10-13 at 10:18 +0200, Roberto Sassu wrote:
> > On Tuesday 13 October 2009 01:24:17 Mimi Zohar wrote:
> > > On Mon, 2009-10-12 at 11:15 +0200, Roberto Sassu wrote:
> > > > Hi all
> > > >
> > > > i have tried to write an IMA policy in order to measure all files, in
> > > > a system with SELinux installed, accessed by subjects with security
> > > > context starting as "system_u:system_r" and to skip files with label
> > > > "initrc_var_run_t" (/var/run/utmp) which is the origin of multiple
> > > > violations.
> > > > The policy is:
> > > >
> > > > --------
> > > > dont_measure obj_type=initrc_var_run_t
> > > > measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
> > > > measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
> > > > --------
> > >
> > > The policy order, as you realized, is important. The action is based on
> > > the first rule matched. Are you running an SELinux targeted policy?  To
> > > see the LSM labels associated with a process execute: ps -aeZ. With a
> > > targeted policy, a number of processes are run as unconfined. Instead
> > > of the above policy rules, please try these:
> > >
> > > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> > > measure func=PATH_CHECK mask=MAY_READ uid=0
> > >
> > > Thanks!
> > >
> > > Mimi
> >
> > I'm running Fedora 11 with the targeted policy in a virtual machine and i
> > log in with ssh. By enabling some system services i encountered other
> > some violations. One is caused by the service "pcsd" which i disabled for
> > now. I added other few exceptions in the policy you suggested, to clean
> > the others:
> >
> > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=sendmail_var_run_t
> > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=hald_var_run_t
> > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=consolekit_log_t
> > measure func=PATH_CHECK mask=MAY_READ uid=0
> 
> For now, with these types of rules we can eliminate the
> ToMToU/open_writers auditing messages and prevent invalidating the PCR,
> but before adding these types of rules, we should really understand the
> underlying problem.
> 
> For example:
> ck-history opens for read /var/log/ConsoleKit/history, while
> console-kit-daemon has it open for write. (open-writers)
> 
> # lsof +c 0  /var/log/ConsoleKit/history
> 
> COMMAND          PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
> console-kit-dae 2067 root    9w   REG    8,2  1550104 1196033
> /var/log/ConsoleKit/history
> 
> So, is it necessary for console-kit-daemon to open for write and never
> close /var/log/ConsoleKit/history or should console-kit-daemon be
> modified?
> 
> Mimi
> 


I'm thinking the concept of violation is too restrictive.
In the case of "read_writers" checking, a violation can happens if a reader 
tries to open a file which is already opened for writing by another process. 
But it's possible that the writer has not already modified the file.
If it is true that the reader sees modifications done by the writer only after 
the inode "i_version" field is updated, we can report in the measurement list 
that there's a possible violation but we can delay the detection until the 
reader ends to use the resource.
This is a possible sequence of operations done by two processes A, B which 
they can be considered safe:

1) Process A opens file "file1" for writing

2) Process B opens file "file1" for reading ---> IMA in the ima_path_check() 
function store inside the ima_iint_cache structure of the inode of file1 these 
data {pid of reader process, current i_version } and report in the measurement 
list that there is a possible violation.

3) Process B close file "file1"---> IMA in the ima_file_free() function verifies 
the data {pid, i_version} stored previously: if the reader ends to use the file 
and the i_version is not changed, IMA reports in its measurement list that the 
possible violation is solved.

4) Process A writes on "file1" ---> OK, data are changed but process B used the 
previously version of the file. 







 

Re: [Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Mimi Z. <zo...@li...>]

On Tue, 2009-10-13 at 10:18 +0200, Roberto Sassu wrote: 
> On Tuesday 13 October 2009 01:24:17 Mimi Zohar wrote:
> > On Mon, 2009-10-12 at 11:15 +0200, Roberto Sassu wrote:
> > > Hi all
> > >
> > > i have tried to write an IMA policy in order to measure all files, in a
> > > system with SELinux installed, accessed by subjects with security context
> > > starting as "system_u:system_r" and to skip files with label
> > > "initrc_var_run_t" (/var/run/utmp) which is the origin of multiple
> > > violations.
> > > The policy is:
> > >
> > > --------
> > > dont_measure obj_type=initrc_var_run_t
> > > measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
> > > measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
> > > --------
> > 
> > The policy order, as you realized, is important. The action is based on
> > the first rule matched. Are you running an SELinux targeted policy?  To
> > see the LSM labels associated with a process execute: ps -aeZ. With a
> > targeted policy, a number of processes are run as unconfined. Instead of
> > the above policy rules, please try these:
> > 
> > dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> > measure func=PATH_CHECK mask=MAY_READ uid=0
> > 
> > Thanks!
> > 
> > Mimi
> > 
> 
> I'm running Fedora 11 with the targeted policy in a virtual machine and i log 
> in with ssh. By enabling some system services i encountered other some 
> violations. One is caused by the service "pcsd" which i disabled for now. I 
> added other few exceptions in the policy you suggested, to clean the others:
> 
> dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> dont_measure func=PATH_CHECK mask=MAY_READ obj_type=sendmail_var_run_t
> dont_measure func=PATH_CHECK mask=MAY_READ obj_type=hald_var_run_t
> dont_measure func=PATH_CHECK mask=MAY_READ obj_type=consolekit_log_t
> measure func=PATH_CHECK mask=MAY_READ uid=0

For now, with these types of rules we can eliminate the
ToMToU/open_writers auditing messages and prevent invalidating the PCR,
but before adding these types of rules, we should really understand the
underlying problem.

For example:
ck-history opens for read /var/log/ConsoleKit/history, while
console-kit-daemon has it open for write. (open-writers)

# lsof +c 0  /var/log/ConsoleKit/history 

COMMAND          PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
console-kit-dae 2067 root    9w   REG    8,2  1550104 1196033 
/var/log/ConsoleKit/history

So, is it necessary for console-kit-daemon to open for write and never
close /var/log/ConsoleKit/history or should console-kit-daemon be
modified?

Mimi

Re: [Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Roberto S. <rob...@po...>]

On Tuesday 13 October 2009 01:24:17 Mimi Zohar wrote:
> On Mon, 2009-10-12 at 11:15 +0200, Roberto Sassu wrote:
> > Hi all
> >
> > i have tried to write an IMA policy in order to measure all files, in a
> > system with SELinux installed, accessed by subjects with security context
> > starting as "system_u:system_r" and to skip files with label
> > "initrc_var_run_t" (/var/run/utmp) which is the origin of multiple
> > violations.
> > The policy is:
> >
> > --------
> > dont_measure obj_type=initrc_var_run_t
> > measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
> > measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
> > --------
> 
> The policy order, as you realized, is important. The action is based on
> the first rule matched. Are you running an SELinux targeted policy?  To
> see the LSM labels associated with a process execute: ps -aeZ. With a
> targeted policy, a number of processes are run as unconfined. Instead of
> the above policy rules, please try these:
> 
> dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
> measure func=PATH_CHECK mask=MAY_READ uid=0
> 
> Thanks!
> 
> Mimi
> 

I'm running Fedora 11 with the targeted policy in a virtual machine and i log 
in with ssh. By enabling some system services i encountered other some 
violations. One is caused by the service "pcsd" which i disabled for now. I 
added other few exceptions in the policy you suggested, to clean the others:

dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
dont_measure func=PATH_CHECK mask=MAY_READ obj_type=sendmail_var_run_t
dont_measure func=PATH_CHECK mask=MAY_READ obj_type=hald_var_run_t
dont_measure func=PATH_CHECK mask=MAY_READ obj_type=consolekit_log_t
measure func=PATH_CHECK mask=MAY_READ uid=0

Re: [Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Mimi Z. <zo...@li...>]

On Mon, 2009-10-12 at 11:15 +0200, Roberto Sassu wrote:
> Hi all
> 
> i have tried to write an IMA policy in order to measure all files, in a system 
> with SELinux installed, accessed by subjects with security context starting as 
> "system_u:system_r" and to skip files with label "initrc_var_run_t" 
> (/var/run/utmp) which is the origin of multiple violations. 
> The policy is:
> 
> --------
> dont_measure obj_type=initrc_var_run_t
> measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
> measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
> --------

The policy order, as you realized, is important. The action is based on
the first rule matched. Are you running an SELinux targeted policy?  To
see the LSM labels associated with a process execute: ps -aeZ. With a
targeted policy, a number of processes are run as unconfined. Instead of
the above policy rules, please try these:

dont_measure func=PATH_CHECK mask=MAY_READ obj_type=initrc_var_run_t
measure func=PATH_CHECK mask=MAY_READ uid=0

Thanks!

Mimi

[Linux-ima-user] IMA policy with LSM rules not correctly loaded

[Roberto S. <rob...@po...>]

Hi all

i have tried to write an IMA policy in order to measure all files, in a system 
with SELinux installed, accessed by subjects with security context starting as 
"system_u:system_r" and to skip files with label "initrc_var_run_t" 
(/var/run/utmp) which is the origin of multiple violations. 
The policy is:

--------
dont_measure obj_type=initrc_var_run_t
measure subj_user=system_u func=PATH_CHECK mask=MAY_READ
measure subj_role=system_r func=PATH_CHECK mask=MAY_READ
--------

Depending on the order of directives i got different results.
I searched in the kernel code where the IMA policy is loaded and i see that in 
the file "security/integrity/ima/ima_policy.c" only an entry is created for 
every LSM rules even if there are different directives "measure/dont_measure".
Then i modified the code in order to create an new object of  "struct 
ima_measure_rule_entry" for each line of the policy which will contain the 
criteria parsed and it will have associated an action (measure/dont_measure).
After the parsing procedure each new object is added to the list referenced by 
the variable "measure_policy_rules".
Finally i modified the measurement decision logic located in the function 
"ima_match_policy".
The procedure scans the list which contains the policy loaded and we have the 
following cases: 
- if none of rules loaded are matched by the subject/object security context 
the decision taken is "false" (this case is handled by the variable 
"flag_matched"); 
- the function will return "true" if, for all rules matched by the current 
subject/object security context, the bound action is "measure"; if just one 
rule contains the action "dont_measure" the result returned will be "false". 

I have not verified the correctness for all possible cases, but with the 
proposed modification, i can have a list of measured files accessed during the 
boot procedure (my system is a Fedora 11) without any violation.
The file attached contains the patch i have applied to the vanilla kernel 
version 2.6.31.3.

Re: [Linux-ima-user] IMA and MAC labels integrity check

[Mimi Z. <zo...@li...>]

On Sat, 2009-10-03 at 01:08 +0600, Shaz wrote:
> 
> 
> On Fri, Oct 2, 2009 at 8:27 PM, Roberto Sassu
> <rob...@po...> wrote:
>         Hi all
>         
>         i'm trying to protect the integrity of labels used by a
>         Mandatory Access
>         Control to enforce security policies.
>         
>         I see that it's possible to create custom ima policies that
>         permit to find with
>         more fine granularity objects of the system to be measured.
>         
>         In SELinux i have such transition:
>         
>         type_transition initrc_t myapp_exec_t:process myapp_t;
>         
>         and such type of executable is the only entrypoint for the
>         domain myapp_t.
>         
>         Instead of adding an hmac signature over the executable, i'm
>         thinking of
>         modify IMA in order to measure and verify the binary against a
>         value
>         previously collected and to allow/deny the operation requested
>         depending on
>         the result.
>         
>         I can have a rule that filter the execve of myapp by writing
>         such ima policy:
>         
>         obj_type=myapp_exec_t func=BPRM_CHECK
>         
>         with the addition:
>         HASH=<good value>
>         
>         In such case, if the calculated hash is different, IMA will
>         deny the operation.
>         Does this proposal addresses the issue?
>         
> 
> IMA works as a trusted boot not secure boot so it will load the binary
> but report it as a bad SHA1 hash. SHA1 is the default but HMAC is also
> an option.  SELinux is trustworthy as long as you can trust the system
> administrator. So if your policy is correct and labeling rules are
> correct and intact then your problem will be solved. IMA only reports
> if the software is the expected one. You can measure file context
> labeling file to be sure that your application will get the same label
> that you expect but that is too static for me :)
>  
>         Thanks for replies.
> 
> 
> -- 
> Shaz

Roberto,

Thanks Shaz! Now that IMA is in the Linux kernel.  We are working on
adding hash verification to IMA, based on our earlier EVM work. For more
information on EVM, refer to:
http://lists.jammed.com/linux-security-module/2005/11/0011.html

“Trusted Computing and Open Source”, D. Safford, M. Zohar, Elsevier
Information Security Technical Report, Volume 10 Issue 2, pp 74-82 2005.

Mimi

Re: [Linux-ima-user] IMA and MAC labels integrity check

[Shaz <sha...@gm...>]

On Fri, Oct 2, 2009 at 8:27 PM, Roberto Sassu <rob...@po...>wrote:

> Hi all
>
> i'm trying to protect the integrity of labels used by a Mandatory Access
> Control to enforce security policies.
>
> I see that it's possible to create custom ima policies that permit to find
> with
> more fine granularity objects of the system to be measured.
>
> In SELinux i have such transition:
>
> type_transition initrc_t myapp_exec_t:process myapp_t;
>
> and such type of executable is the only entrypoint for the domain myapp_t.
>
> Instead of adding an hmac signature over the executable, i'm thinking of
> modify IMA in order to measure and verify the binary against a value
> previously collected and to allow/deny the operation requested depending on
> the result.
>
> I can have a rule that filter the execve of myapp by writing such ima
> policy:
>
> obj_type=myapp_exec_t func=BPRM_CHECK
>
> with the addition:
> HASH=<good value>
>
> In such case, if the calculated hash is different, IMA will deny the
> operation.
> Does this proposal addresses the issue?
>
>
IMA works as a trusted boot not secure boot so it will load the binary but
report it as a bad SHA1 hash. SHA1 is the default but HMAC is also an
option.  SELinux is trustworthy as long as you can trust the system
administrator. So if your policy is correct and labeling rules are correct
and intact then your problem will be solved. IMA only reports if the
software is the expected one. You can measure file context labeling file to
be sure that your application will get the same label that you expect but
that is too static for me :)


> Thanks for replies.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>



-- 
Shaz

[Linux-ima-user] IMA and MAC labels integrity check

[Roberto S. <rob...@po...>]

Hi all

i'm trying to protect the integrity of labels used by a Mandatory Access 
Control to enforce security policies.

I see that it's possible to create custom ima policies that permit to find with 
more fine granularity objects of the system to be measured.

In SELinux i have such transition:

type_transition initrc_t myapp_exec_t:process myapp_t;

and such type of executable is the only entrypoint for the domain myapp_t.

Instead of adding an hmac signature over the executable, i'm thinking of 
modify IMA in order to measure and verify the binary against a value 
previously collected and to allow/deny the operation requested depending on 
the result.

I can have a rule that filter the execve of myapp by writing such ima policy:

obj_type=myapp_exec_t func=BPRM_CHECK  

with the addition:
HASH=<good value>

In such case, if the calculated hash is different, IMA will deny the operation.
Does this proposal addresses the issue?

Thanks for replies.

[Linux-ima-user] IMA integration with xen

[z. <zha...@qq...>]

hello all,
       I have installed IMA in xen-linux-2.6.18. However, I find the commad of "xend start" can not be used no longer after IMA is installed. Is it because IMA stop the "xend start" command?

Re: [Linux-ima-user] a question about invalidate pcr

[Mimi Z. <zo...@li...>]

On Sun, 2009-09-20 at 21:17 +0800, zhangkai108 wrote:
> hello,
>        I read a part of source codes in ima.h. I can't understand it.
>        #define MEM_MINOR     1 
> 
> #define KMEM_MINOR   2
> 
> #ifdef CONFIG_IMA_KMEM_BYPASS_PROTECTION
> 
> static inline void check_kmem_bypass(struct inode *inode)
> 
> {
> 
>          if ((imajor(inode) == MEM_MAJOR)
> 
>             && S_ISCHR(inode->i_mode) && (iminor(inode) ==
> KMEM_MINOR))
> 
>                    invalidate_pcr("/dev/kmem write violation");
> 
> }
> 
> #else
> 
> static inline void check_kmem_bypass(struct inode *inode)
> 
> {
> 
>          return;
> 
> }
> 
> #endif
> 
> why  the "invalidate pcr" function is called  after passing the
> judgement of if confiditional statment ? I hope you can explain it for
> me. Thank you.

PCR invalidation is an indication that something could modify a file
without the modification being reported in the IMA measurement list.

This code is from the original LSM based IMA code, not the current code
in the mainline Linux kernel. Originally, as only one module could use
the LSM hooks, IMA and an LSM module, which implements access control,
could not co-exist. Today, ima_ hooks are directly imbedded in the
mainline code. So, access control is left up to the LSM module.

Mimi

Re: [Linux-ima-user] Extended verification module (EVM) and IMA

[Mimi Z. <zo...@li...>]

On Fri, 2009-09-18 at 10:09 +0200, Roberto Sassu wrote: 
> Hi all
> 
> i downloaded the old IBM "tpm" package and i see that the "EVM" module grants 
> extended attribute integrity for files, but it's is implemented only for 2.6.20 
> kernel series. There's a plan to integrate such feature together with IMA in 
> the mainline?
> Thanks in advance.

Yes and no. Now that IMA is in the mainline Linux kernel, we are
planning on adding the EVM functionality - integrity appraisal of
data/metadata. There were some performance issues with the original
design, which we first need to address. So no, it isn't a simple port.

Mimi

[Linux-ima-user] Extended verification module (EVM) and IMA

[Roberto S. <rob...@po...>]

Hi all

i downloaded the old IBM "tpm" package and i see that the "EVM" module grants 
extended attribute integrity for files, but it's is implemented only for 2.6.20 
kernel series. There's a plan to integrate such feature together with IMA in 
the mainline?
Thanks in advance.

Re: [Linux-ima-user] Fw:a question about IMA

[Mimi Z. <zo...@li...>]

On Tue, 2009-09-15 at 16:03 +0800, zhangkai108 wrote:
> Hello, 
>       I am doing a project with IMA. Now, I meet a problem. I need
> your help. I have read the paper " Design and Implementation of a
> TCG-based Integrity Measurement Architecture", there is a passage in
> section " 5.3 Measurement Bypass-Protection", which says " Whenever we
> encounter a situation in which our measurement architecture cannot
> provide correct measurements or is potentially being bypassed, we
> invalidate the TPM aggregate by extending it with random values
> without extending the measurement list and deleting the random value
> to protect
> it from later use. Thus, from this time on, validations of the
> aggregate will fail against the measurement list. We do not interfere
> with the system (non-intrusive) but we disable such a system from
> successful attestation until it reboots. In our experiments, none of
> these mechanisms was triggered throughout normal system usage but only
> by malicious or very unusual behavior." 
>        I don't have hardware TPM, so I using the virtual TPM instead.
> Sometimes, when guest os startup, the invalidate_pcr is called, the
> debug messages are in accessory, I add some debug messages in
> ima_extend function. 
>        Why my guest os can cause invalidate_pcr is called? Would you
> like to help me? Thank you.

There are two reasons for the IMA measurement list to be invalidated:
open_writers or ToMToU. In the first case, open_writers, something is
opening the file for read, that has already been opened for write. In
the latter case, Time of Measure Time of Use (ToMToU), the file is
already open for read and is now being opened for write. Both reasons
add an entry to the measurement list containing a 0 hash value, but the
PCR is extended with 0xFF's.

The cause for the invalidations can be found in
either /var/log/audit/audit.log, if you're running auditd, or
in /var/log/messages.  You can search for "invalid_pcr".

The LTP IMA testsuite includes programs to generate invalidations and
verify the measurement list.

Mimi

Re: [Linux-ima-user] a question about IMA

[Mimi Z. <zo...@li...>]

On Sat, 2009-09-12 at 13:25 +0800, zhangkai108 wrote:
> hello,
>      I am doing some experiments with IMA, now I meet a problem about
> verifying the measurement list. I verify the measurement list like
> what the IMA INSTALL document said:
>        SHA1_Init(&c);
>        SHA1_Update(&c, PCR, SHA_DIGEST_LENGTH); /* PCR = SHA(PCR ||
> MEASUREMENT) */
>        SHA1_Update(&c, hex, SHA_DIGEST_LENGTH);
>        SHA1_Final(PCR, &c);
>      However, the value of PCR is not equal with the value of PCR10.
> Then, I calculate the measurement list using the TPM_Extend command
> like this:
>       unsigned char extend_cmd[] = {0, TPM_TAG_RQU_COMMAND,
>              0, 0, 0, 34,
>              0, 0, 0, TPM_ORD_Extend,
>              0, 0, 0, 11,
>              hex[0],hex[1],hex[2],hex[3],hex[4],hex[5],
>              hex[6],hex[7],hex[8],hex[9],hex[10],hex[11],
> 
> hex[12],hex[13],hex[14],hex[15],hex[16],hex[17],hex[18],hex[19]};
>       Now the value of PCR11 is equal with the value of PCR, but they
> are not equal with the value of PCR10.
>      would you like to explain this for me? Thank you.

Could you please supply some additional information, such as which
kernel you're running?  You also might want to check out the website
http://linux-ima.sourceforge.net/, which contains information on
enabling IMA in the kernel and verifying the measurement list.

Mimi

Re: [Linux-ima-user] Questions about the i_version field of the inode structure is used by IMA

[Mimi Z. <zo...@li...>]

On Thu, 2009-07-23 at 14:17 +0200, Roberto Sassu wrote:
> Hello all
> 
> i have a two questions about how IMA (distributed in the last 2.6.30.2 kernel) 
> detects file changes.
> First, I see that the i_version field of an inode structure is incremented each 
> time the file gets modified. It's possible to change the file many times as it's 
> necessary to overflow the counter and to obtain the same value stored in the 
> IMA table? (to avoid this event to be reported)

As i_version is defined as u64, the file would have to be modified
(2^64)-1 times.

> The second one, i see that the sb_umount hook is no longer used, then all 
> measured files in a removable device are not marked as DIRTY, but i suppose 
> that the measurement decision will be taken next time the volume is mounted 
> comparing the two i_version integers. 

When an inode entry is removed from dcache, the corresponding iint entry
is removed from the radix tree. Unmounting an fs will cause the inodes,
and by extension iint's, to be freed.  When the fs is remounted, any
file accessed will result in allocating a new iint structure with the
i_version set to 0.

> Doesn't it is dangerous because the i_version modification of inodes in the 
> removable device is out of the control of the integrity system? (For example i 
> can mount the removable device in another unsecure system that modifies some 
> files without incrementing the i_version field of the inode).
> 
> Thanks in advance

Only re-measuring a file is based on i_version. The described scenario
is the equivalent to measuring the file for the first time, not
re-measuring, as the i_version number in the iint is 0.

Mimi

[Linux-ima-user] Questions about the i_version field of the inode structure is used by IMA

[Roberto S. <myr...@gm...>]

Hello all

i have a two questions about how IMA (distributed in the last 2.6.30.2 kernel) 
detects file changes.
First, I see that the i_version field of an inode structure is incremented each 
time the file gets modified. It's possible to change the file many times as it's 
necessary to overflow the counter and to obtain the same value stored in the 
IMA table? (to avoid this event to be reported)
The second one, i see that the sb_umount hook is no longer used, then all 
measured files in a removable device are not marked as DIRTY, but i suppose 
that the measurement decision will be taken next time the volume is mounted 
comparing the two i_version integers. 
Doesn't it is dangerous because the i_version modification of inodes in the 
removable device is out of the control of the integrity system? (For example i 
can mount the removable device in another unsecure system that modifies some 
files without incrementing the i_version field of the inode).

Thanks in advance

[Linux-ima-user] Questions about the i_version field of the inode structure is used by IMA

[Roberto S. <rob...@po...>]

Hello all

i have a two questions about how IMA (distributed in the last 2.6.30.2 kernel) 
detects file changes.
First, I see that the i_version field of an inode structure is incremented each 
time the file gets modified. It's possible to change the file many times as it's 
necessary to overflow the counter and to obtain the same value stored in the 
IMA table? (to avoid this event to be reported)
The second one, i see that the sb_umount hook is no longer used, then all 
measured files in a removable device are not marked as DIRTY, but i suppose 
that the measurement decision will be taken next time the volume is mounted 
comparing the two i_version integers. 
Doesn't it is dangerous because the i_version modification of inodes in the 
removable device is out of the control of the integrity system? (For example i 
can mount the removable device in another unsecure system that modifies some 
files without incrementing the i_version field of the inode).

Thanks in advance

[Linux-ima-user] ltp: IMA cross platform fixes

[Mimi Z. <zo...@li...>]

- Instead of using the default platform shell, explicitly use bash.
- To create a file using 'sudo -u', some platforms require 'user' to exist.
- Document verifying PCR-10 fails on Ubuntu 9 on reboot due to kexec.

Signed-off-by: Mimi Zohar <zo...@us...>

Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 ################################################################################
 ##                                                                            ##
@@ -137,12 +137,13 @@ test03()
 
 	# create file user-test.txt
 	mkdir -m 0700 $LTPIMA/user
-	chown 99.99 $LTPIMA/user
+	chown nobody.nobody $LTPIMA/user
 	cd $LTPIMA/user
 	hash=0
 
-	# As user 99, create and cat the new file
-	sudo -u \#99 sh -c "echo `date` - create test.txt > ./test.txt;
+	# As user nobody, create and cat the new file
+	# (The LTP tests assumes existence of 'nobody'.)
+	sudo -u nobody sh -c "echo `date` - create test.txt > ./test.txt;
 				cat ./test.txt > /dev/null"
 
 	# Calculating the hash will add the measurement to the measurement
Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_policy.sh
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/tests/ima_policy.sh
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_policy.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 ################################################################################
 ##                                                                            ##
 ## Copyright (C) 2009 IBM Corporation                                         ##
Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 ################################################################################
 ##                                                                            ##
 ## Copyright (C) 2009 IBM Corporation                                         ##
Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 ################################################################################
 ##                                                                            ##
Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_violations.sh
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/tests/ima_violations.sh
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/tests/ima_violations.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 ################################################################################
 ##                                                                            ##
 ## Copyright (C) 2009 IBM Corporation                                         ##
Index: ltp-full-20090531/testcases/kernel/security/integrity/ima/README
===================================================================
--- ltp-full-20090531.orig/testcases/kernel/security/integrity/ima/README
+++ ltp-full-20090531/testcases/kernel/security/integrity/ima/README
@@ -52,6 +52,10 @@ open for read by root. If the default po
 another measurement policy will fail, as the policy may only be replaced
 once per boot. Some of the policy dependency tests might also fail as well.
 
+ima_tpm.sh: test02, verifying the PCR-10 value, requires a hard reboot.
+[On Ubuntu 9, before running the ltp tests, disable /etc/init.d/kexec-load
+and reboot.]
+
 Run tests
 ---------
 After doing 'make' and 'make install' from the top-level,

Re: [Linux-ima-user] [LTP] Can not run Test

[Mimi Z. <zo...@li...>]

On Tue, 2009-06-30 at 11:33 +0600, waqar afridi wrote:
> 
> 
> On Tue, Jun 30, 2009 at 11:23 AM, waqar afridi
> <afr...@gm...> wrote:

>         
>         I tried that and the result was
>         
>         # ./ima_tpm.sh 
>         ./ima_tpm.sh: 164: setup: not found
>         
>         It did solved the source not found error. but the setup not
>         found error still exists. May some thing wrong with ima_setup?
>         Thanx

My mistake. Could you try replacing "source " with a ". " like ".
`dirname $0`/ima_setup.sh"?

Thanks!

Mimi

Re: [Linux-ima-user] [LTP] Can not run Test

[waqar a. <afr...@gm...>]

On Tue, Jun 30, 2009 at 11:23 AM, waqar afridi <afr...@gm...>wrote:

>
>
> On Mon, Jun 29, 2009 at 10:45 PM, Mimi Zohar <zo...@li...>wrote:
>
>> On Mon, 2009-06-29 at 19:14 +0600, Shaz wrote:
>>
>> > On Mon, Jun 29, 2009 at 7:13 PM, Shaz <sha...@gm...> wrote:
>> >
>> >
>> > Yes the scripts are there.
>>
>> In each of the scripts, there is a line:
>> 'source `dirname $0`\/ima_setup.sh'.
>> Could you try replacing 'source' with './' like:
>> ./`dirname $0`\/ima_setup.sh'
>>
>
> I tried that and the result was
>
> # ./ima_tpm.sh
> ./ima_tpm.sh: 164: setup: not found
>
> It did solved the *source not found* error. but the *setup not found*error still exists. May some thing wrong with ima_setup?
> Thanx
>

Almost forgot, the output of *./runltp -f ima* is

**************************************************************************************************************************************************************************

remove test cases which require the block device.
You can specify it with option -b
-e LOG File:
/root/Desktop/ltp/ltp-full-20090531/results/LTP_RUN_ON-2009_Jun_30-11h_28m_35s.log
*-e FAILED COMMAND File:
/root/Desktop/ltp/ltp-full-20090531/output/LTP_RUN_ON-2009_Jun_30-11h_28m_35s.failed
*
Running tests.......
<<<test_start>>>
tag=ima01 stime=1246339716
cmdline="  ima_measurements.sh"
contacts=""
analysis=exit
initiation_status="ok"
<<<test_output>>>
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_measurements.sh: 170:
.//root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_setup.sh: not found*
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_measurements.sh: 171:
setup: not found*
<<<execution_status>>>
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ima02 stime=1246339716
cmdline="  ima_policy.sh"
contacts=""
analysis=exit
initiation_status="ok"
<<<test_output>>>
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_policy.sh: 158:
.//root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_setup.sh: not found*
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_policy.sh: 159:
setup: not found*
<<<execution_status>>>
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ima03 stime=1246339716
cmdline="  ima_tpm.sh"
contacts=""
analysis=exit
initiation_status="ok"
<<<test_output>>>
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_tpm.sh: 163:
.//root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_setup.sh: not found*
*/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_tpm.sh: 164: setup:
not found*
<<<execution_status>>>
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ima04 stime=1246339716
cmdline="  ima_violations.sh"
contacts=""
analysis=exit
initiation_status="ok"
<<<test_output>>>
incrementing stop
/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_violations.sh: 178:
.//root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_setup.sh: not found
/root/Desktop/ltp/ltp-full-20090531/testcases/bin/ima_violations.sh: 179:
setup: not found
<<<execution_status>>>
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
INFO: ltp-pan reported all tests PASS
LTP Version: LTP-20090531

       ###############################################################"

            Done executing testcases."
            LTP Version:  LTP-20090531
       ###############################################################"

**********************************************************************************************************************************************************

I have bold out the a few lines.


>
>
>> Thanks!
>>
>> Mimi
>>
>>
>>
>>
>>
>
>
> --
> Waqar Afridi
> Research Associate
> Member of Security Engineering Research Group (SERG)
> IM | Sciences Peshawar
>



-- 
Waqar Afridi
Research Associate
Member of Security Engineering Research Group (SERG)
IM | Sciences Peshawar

Re: [Linux-ima-user] [LTP] Can not run Test

[waqar a. <afr...@gm...>]

On Mon, Jun 29, 2009 at 10:45 PM, Mimi Zohar <zo...@li...>wrote:

> On Mon, 2009-06-29 at 19:14 +0600, Shaz wrote:
>
> > On Mon, Jun 29, 2009 at 7:13 PM, Shaz <sha...@gm...> wrote:
> >
> >
> > Yes the scripts are there.
>
> In each of the scripts, there is a line:
> 'source `dirname $0`\/ima_setup.sh'.
> Could you try replacing 'source' with './' like:
> ./`dirname $0`\/ima_setup.sh'
>

I tried that and the result was

# ./ima_tpm.sh
./ima_tpm.sh: 164: setup: not found

It did solved the *source not found* error. but the *setup not found* error
still exists. May some thing wrong with ima_setup?
Thanx

>
> Thanks!
>
> Mimi
>
>
>
>
>


-- 
Waqar Afridi
Research Associate
Member of Security Engineering Research Group (SERG)
IM | Sciences Peshawar

Re: [Linux-ima-user] [LTP] Can not run Test

[Mimi Z. <zo...@li...>]

On Mon, 2009-06-29 at 19:14 +0600, Shaz wrote:

> On Mon, Jun 29, 2009 at 7:13 PM, Shaz <sha...@gm...> wrote:
>         
> 
> Yes the scripts are there.

In each of the scripts, there is a line:
'source `dirname $0`\/ima_setup.sh'.
Could you try replacing 'source' with './' like:
./`dirname $0`\/ima_setup.sh'

Thanks!

Mimi