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