linux-kernel - Re: [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1588884313.5685.110.camel@linux.ibm.com>
Date:   Thu, 07 May 2020 16:45:13 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        "david.safford@...il.com" <david.safford@...il.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        John Johansen <john.johansen@...onical.com>
Cc:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>
Subject: Re: [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure

On Thu, 2020-05-07 at 16:47 +0000, Roberto Sassu wrote:
> > > > On Wed, 2020-05-06 at 15:44 -0400, Mimi Zohar wrote:
> > > > > Since copying the EVM HMAC or original signature isn't applicable, I
> > > > > would prefer exploring an EVM portable and immutable signature only
> > > > > solution.
> > > >
> > > > To prevent copying the EVM xattr, we added "security.evm" to
> > > > /etc/xattr.conf.  To support copying just the EVM portable and
> > > > immutable signatures will require a different solution.
> > >
> > > This patch set removes the need for ignoring security.evm. It can be
> > always
> > > copied, even if it is an HMAC. EVM will update it only when verification in
> > > the pre hook is successful. Combined with the ability of protecting a
> > subset
> > > of files without introducing an EVM policy, these advantages seem to
> > > outweigh the effort necessary to make the switch.
> > 
> > As the EVM file HMAC and original signature contain inode specific
> > information (eg. i_version, i_generation), these xattrs cannot ever be
> > copied.  The proposed change is in order to support just the new EVM
> > signatures.
> 
> Right, I didn't consider it.
> 
> Would it make sense instead to introduce an alias like security.evm_immutable
> so that this xattr can be copied?

Being portable, not the attribute of being immutable, allows copying
the EVM xattr.  Your original problem - the order in which the xattrs
are copied - might still be an issue.  We need to look at "cp" closer
to understand what it is doing.  For example, are the xattrs written
while the target file is tagged as a new file?

There have been similar problems in the past.  For example, tar calls
mknodat to create the file, but doesn't write the file data.  The
solution there was to tag the file as a new file.

We need to understand the problem better, before deciding how to
resolve it.

> 
> > At least IMA file hashes should always be used in conjunction with
> > EVM.  EVM xattrs should always require a security.ima xattr to bind
> 
> I proposed to enforce this restriction some time ago:
> 
> https://patchwork.kernel.org/patch/10979351/
> 
> Is it ok to enforce it globally?

Doing this would then be dependent on upstreaming the initramfs xattr
patches first, wouldn't it?  :)

> 
> > the file metadata to the file data.  The IMA and EVM policies really
> > need to be in sync.
> 
> It would be nice, but at the moment EVM considers also files that are
> not selected by the IMA policy. An example of why this is a problem is
> the audit service that fails to start when it tries to adjust the permissions
> of the log files. Those files don't have security.evm because they are
> not appraised by IMA, but EVM denies the operation.

No, this is a timing issue as to whether or not the builtin policy or
a custom policy has been loaded.  A custom policy could exclude the
log files based on LSM labels, but they are included in the builtin
policy.

Mimi