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.