Re: [Linux-ima-user] looking for suggestions on rule use

[Patrick O. <pat...@in...>]

On Tue, 2015-07-14 at 11:53 -0400, Mimi Zohar wrote:
> On Tue, 2015-07-14 at 17:11 +0200, Patrick Ohly wrote:
> > On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > > > Then the only appraisal rule is:
> > > > 
> > > >         # Appraise all operations on files with floor label.
> > > >         appraise obj_user=_
> > > > 
> > > > But IMHO such a system is not really secure, because an attacker could
> > > > simply turn a protected file (label _) into an unprotected one (label
> > > > System), either at runtime or offline. System services then wouldn't
> > > > notice a difference (they can read System files just like _ files) and
> > > > use a potentially modified file.
> > > > 
> > > > Do I miss something here or is my conclusion correct?
> > > 
> > > On a running system with Smack enabled, Smack should be limiting who can
> > > modify security xattrs.
> > 
> > There will be privileged processes which can modify the Smack label; if
> > an attacker manages to take control of those, they could disable IMA.
> 
> No, changing the xattr doesn't disable IMA nor affect the existing
> policy.  If your policy measures/appraises everything, then the file
> would still be measured/appraised appropriately.

But it doesn't appraise everything - that was exactly my concern about a
policy with just the one rule above.

> > My understanding was that by requiring signing and not having private
> > keys on the device, such a breach could be detected even for privileged
> > processes.
> 
> The rule "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig"
> requires all files owned by root to be signed.  Signed files in policy
> are considered "immutable".

The problem which keeps coming up is that such a policy is not practical
when root processes are meant to modify files on the device.

> > If an attacker changes the Smack label, EVM indeed becomes invalid, but
> > because the Smack label was changed, the appraise rule no longer matches
> > and the kernel will not raise any error when using the modified file,
> > will it?
> 
> Right, so the issue is defining an appropriate policy.  If you can't
> trust the Smack labels, then don't write a policy based on them.

Agreed.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.