RE: [RFC][PATCH 1/3] evm: Move hooks outside LSM infrastructure
From: Roberto Sassu <roberto.sassu@huawei.com>
Date: 2020-05-07 16:48:05
Also in:
linux-fsdevel, linux-integrity, lkml
-----Original Message----- From: Mimi Zohar [mailto:zohar@linux.ibm.com] On Thu, 2020-05-07 at 07:53 +0000, Roberto Sassu wrote:quoted
quoted
-----Original Message----- From: Mimi Zohar [mailto:zohar@linux.ibm.com] Sent: Wednesday, May 6, 2020 11:10 PM To: Roberto Sassu <roberto.sassu@huawei.com>;david.safford@gmail.com;quoted
quoted
viro@zeniv.linux.org.uk; jmorris@namei.org; John Johansen [off-list ref] Cc: linux-fsdevel@vger.kernel.org; linux-integrity@vger.kernel.org;linux-quoted
quoted
security-module@vger.kernel.org; linux-kernel@vger.kernel.org; Silviu Vlasceanu [off-list ref] Subject: Re: [RFC][PATCH 1/3] evm: Move hooks outside LSMinfrastructure Roberto, please fix your mailer or at least manually remove this sort of info from the email.quoted
quoted
On Wed, 2020-05-06 at 15:44 -0400, Mimi Zohar wrote:quoted
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 bealwaysquoted
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 asubsetquoted
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?
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?
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. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli