Re: [Acl-devel] [PATCH 2/2] Suppress error messages when copying security.ima fails

[Mimi Zohar]

cc'ing Patrick Ohly, linux-ima-user

On Fri, 2016-12-09 at 17:31 -0500, Stefan Berger wrote:
> On 12/09/2016 04:58 PM, Mike Frysinger wrote:
> > On 09 Dec 2016 16:14, Stefan Berger wrote:
> >> On 12/09/2016 04:02 PM, Mike Frysinger wrote:
> >>> On 09 Dec 2016 15:18, Stefan Berger wrote:
> >>>> On 12/09/2016 02:40 PM, Mike Frysinger wrote:
> >>>>> On 25 Oct 2016 13:36, Stefan Berger wrote:
> >>>>>> The security.ima extended attribute may be copied when it contains
> >>>>>> a digital signature. In case it is a hash, the copying will fail
> >>>>>> and we suppress the error message in that case.
> >>>>> i'm not sure hardcoding specific attributes in the C code like this
> >>>>> is a good idea.  can't we leverage the existing conf file ?
> >>>> Should we add an option to not display an error? Like 'quiet' ?
> >>> that's already possible by not passing in an error context.
> >>> but that's not what i meant.  we already have xattr.conf that
> >>> explicitly lists attributes and whether we should skip them.
> >>> can't we leverage that database in these files and have it
> >>> (silently) skip attributes when they're listed as "skip" ?
> >> The security.ima extended attribute can either be a hash or a signature.
> >> In case of a signature, we want it to be copied, in case of a hash we
> >> don't want to show the error messages appearing when the copying failed.
> > i haven't been following the ima work closely.  but if the xattr is just
> > a hash of the content, why would copying it be rejected by the kernel ?
> 
> I believe it was a recently extension that prevents userspace from 
> writing the hash value. Mimi can probably say more about this.

As part of Dmity Kasatkin's work on locking down IMA, we disabled
userspace from writing a file hash (c68ed80c97d9 "ima: limit file hash
setting by user to fix and log modes"), since the kernel automatically
calculates and writes the file hash as an extended attribute for files
in policy.  Only writing file signatures is permitted.

Mainly because of these unnecessary error messages, which make it
difficult to notice real errors,  Patrick Ohly requested we revert
Dmitry's patch.  Reluctantly I agreed to revert it (f5acb3dcba1f), which
is being upstreamed in this open window.  The better solution would be
to suppress these messages (and fix the other issues).

Mimi