From: Mimi Zohar <zohar@linux.ibm.com>
To: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>,
dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
zhangliguang@linux.alibaba.com
Cc: linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, Nayna Jain <nayna@linux.ibm.com>
Subject: Re: [PATCH 0/2] support to read and tune appraise mode in runtime
Date: Tue, 14 Apr 2020 09:41:14 -0400 [thread overview]
Message-ID: <1586871674.7311.189.camel@linux.ibm.com> (raw)
In-Reply-To: <a767d0e0-6c57-254a-3c95-f78026e80c1d@linux.alibaba.com>
On Tue, 2020-04-14 at 11:36 +0800, Tianjia Zhang wrote:
>
> On 2020/4/14 5:55, Mimi Zohar wrote:
> > On Thu, 2020-04-09 at 11:39 +0800, Tianjia Zhang wrote:
> >> Support the read and write operations of ima_appraise by adding a
> >> securifyfs file 'appraise_mode'.
> >>
> >> In order to tune appraise mode in runtime, writing a PKCS#7 signature
> >> corresponding the signed content is required. The content should be off,
> >> enforce, log or fix. Given a simple way to archive this:
> >>
> >> $ echo -n off > mode
> >> $ openssl smime -sign -nocerts -noattr -binary \
> >> -in mode -inkey <system_trusted_key> \
> >> -signer <cert> -outform der -out mode.p7s
> >> $ sudo cat mode.p7s \
> >> > /sys/kernel/security/ima/appraise_mode
> >>
> >> Note that the signing key must be a trust key located in
> >> system trusted keyring. So even the root privilege cannot
> >> simply disable the enforcement.
> >
> > There are major problems with disabling IMA appraisal. This patch set
> > proposes disabling IMA appraisal without even providing the motivation
> > for such support.
> >
> > A lot of effort went into preventing custom IMA policies from
> > disabling appraising the kexec or kernel module signatures. In
> > addition, the "lockdown" patch set was upstreamed permitting IMA
> > signature verification. This patch set would break both of these
> > features.
> >
> > IMA relies on its own keyring for verifying file signatures, not the
> > builtin or secondary trusted kernel keyrings.
> >
> > Two methods already exist - xattr and appended signatures - for
> > verifying file signatures. This patch set assumes creating and
> > signing a file, which is then written to a securityfs file. Like for
> > loading a custom IMA policy, instead of cat'ing the file, write the
> > pathname to the securityfs file.
> >
> > If you must define a new IMA method for verifying file signatures,
> > then it needs to be generic and added to ima_appraise_measurement().
> > (Refer to the new IMA appended signature support.)
> >
> > Mimi
> >
> >>
> >> Tianjia Zhang (2):
> >> ima: support to read appraise mode
> >> ima: support to tune appraise mode in runtime
> >>
> >> security/integrity/ima/ima_fs.c | 134 +++++++++++++++++++++++++++++++-
> >> 1 file changed, 133 insertions(+), 1 deletion(-)
> >>
>
> Thanks for your suggestion, the way to close the appraise mode here is
> indeed a bit rude, I will reconsider again according to your suggestions.
>
> In addition, [PATCH 1/2] ima: support to read appraise mode, by the way,
> see if this patch is acceptable.
My comments were not meant as suggestions, but as an explanation as to
how IMA works. More details follow.
IMA is based on policy. That decision was made a long time ago. It
allowed distros to configure IMA, allowing customers to experiment
with it. You have one opportunity to totally change the boot time
policy rules, by loading a custom policy. After that, rules may only
be added.
There is no valid reason for "turning off" the policy once it has been
enabled. It breaks existing expectations.
Mimi
next prev parent reply other threads:[~2020-04-14 13:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 3:39 [PATCH 0/2] support to read and tune appraise mode in runtime Tianjia Zhang
2020-04-09 3:39 ` [PATCH 1/2] ima: support to read appraise mode Tianjia Zhang
2020-04-09 3:39 ` [PATCH 2/2] ima: support to tune appraise mode in runtime Tianjia Zhang
2020-04-09 5:40 ` kbuild test robot
2020-04-13 21:55 ` [PATCH 0/2] support to read and " Mimi Zohar
2020-04-14 3:36 ` Tianjia Zhang
2020-04-14 13:41 ` Mimi Zohar [this message]
2020-04-15 2:49 ` Tianjia Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1586871674.7311.189.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nayna@linux.ibm.com \
--cc=serge@hallyn.com \
--cc=tianjia.zhang@linux.alibaba.com \
--cc=zhangliguang@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).