On 6/3/2019 4:31 PM, James Bottomley wrote:
On Mon, 2019-06-03 at 16:29 +0200, Roberto Sassu wrote:
On 6/3/2019 3:43 PM, James Bottomley wrote:
On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
On 5/30/2019 2:00 PM, Mimi Zohar wrote:
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
Currently, ima_appraise_measurement() ignores the EVM status
when evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file
has a valid security.ima xattr with type IMA_XATTR_DIGEST or
IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
INTEGRITY_PASS regardless of the EVM status. The problem is
that the EVM status is overwritten with the appraisal statu
Roberto, your framing of this problem is harsh and
misleading. IMA and EVM are intentionally independent of each
other and can be configured independently of each other. The
intersection of the two is the call to
evm_verifyxattr(). INTEGRITY_UNKNOWN is
returned for a number of reasons - when EVM is not configured,
the EVM hmac key has not yet been loaded, the protected
security attribute is unknown, or the file is not in policy.
This patch does not differentiate between any of the above
cases, requiring mutable files to always be protected by EVM,
when specified as an "ima_appraise=" option on the boot command
line.
IMA could be extended to require EVM on a per IMA policy rule
basis. Instead of framing allowing IMA file hashes without EVM
as a bug that has existed from the very beginning, now that
IMA/EVM have matured and is being used, you could frame it as
extending IMA or hardening.
I'm seeing it from the perspective of an administrator that
manages an already hardened system, and expects that the system
only grants access to files with a valid signature/HMAC. That
system would not enforce this behavior if EVM keys are removed
and the digest in security.ima is set to the actual file digest.
Framing it as a bug rather than an extension would in my opinion
help to convince people about the necessity to switch to the safe
mode, if their system is already hardened.
I have a use case for IMA where I use it to enforce immutability of
containers. In this use case, the cluster admin places hashes on
executables as the image is unpacked so that if an executable file
is changed, IMA will cause an execution failure. For this use
case, I don't care about the EVM, in fact we don't use it, because
the only object is to fail execution if a binary is mutated.
How would you prevent root in the container from updating
security.ima?
We don't. We only guarantee immutability for unprivileged containers,
so root can't be inside.
Ok.
Regarding the new behavior, this must be explicitly enabled by adding
ima_appraise=enforce-evm or log-evm to the kernel command line.
Otherwise, the current behavior is preserved with this patch. Would this
be ok?
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
