linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: THOBY Simon <Simon.THOBY@viveris.fr>,
	"dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	BARVAUX Didier <Didier.BARVAUX@viveris.fr>
Subject: Re: [PATCH v4 0/5] IMA: restrict the accepted digest algorithms for
Date: Tue, 27 Jul 2021 13:47:08 -0400	[thread overview]
Message-ID: <3ee0fdf38ca04bee6b58cd043ab5fa9a99dba9c1.camel@linux.ibm.com> (raw)
In-Reply-To: <20210727163330.790010-1-simon.thoby@viveris.fr>

Hi Simon,

On Tue, 2021-07-27 at 16:33 +0000, THOBY Simon wrote:
> IMA protects files by storing a hash (or a signature thereof) of their
> content in the security.ima xattr. While the security.ima xattr itself
> is protected by EVM with either a HMAC or a digital signature, no
> mechanism is currently in place to ensure that the security.ima xattr
> was generated with a strong digest algorithm, as was outlined in
> https://lore.kernel.org/linux-integrity/10dde047d76b447f32ca91356599be679b8a76e5.camel@linux.ibm.com/t/#m0f8127c6982ef94aa42f5cc13ea83b9f9000917e

Discussions should be summarized inline.  A reference to the thread
discussion may be included in a "Link" tag.  When including a "Link"
tag use the "permalink" as listed on the linux-integrity thread.  Once
the discussion is summarized, will a reference to the link really be
necessary?   Maybe fold in the subsequent paragraphs below.  Remember,
the entire cover letter or part of it, may be used as the git merge
text.

> One important point is safeguarding users from mislabelling their
> files when using userland utilities to update their files, as this
> is the kind of behavior one can observe with evmctl (`evmctl ima_hash`
> defaults to sha1). Another group that may be interested is those
> that have deployed IMA years ago, possibly using algorithms that
> was then deemed sufficiently collision-resistant, but that proved
> to be weak with the passage of time (note that this could also
> happen in the future with algorithms considered safe today).
> This patch provides a migration path of sorts for these users.
> 
> This patch series gives users the ability to restrict the algorithms
> accepted by their system, both when writing/updating xattrs, and
> when appraising files, while retaining a permissive behavior by default
> to preserve backward compatibility.
> 
> To provide these features, alter the behavior of setxattr to
> only accept hashes built in the kernel, instead of any hash listed
> in the kernel (complete list crypto/hash_info.c). In addition, the
> user can define in his IMA policy the list of digest algorithms
> allowed for writing to the security.ima xattr. In that case,
> only algorithms present in that list are accepted for writing.
> 
> In addition, users may opt-in to whitelisting the hash
> algorithms accepted when appraising thanks to the new
> "appraise_hash" IMA policy option.
> By default IMA will keep accepting any hash algorithm, but specifying
> that option will make appraisal of files hashed with another algorithm
> fail.
> 
> 
> Even when using this option to restrict accepted hashes, a migration
> to a new algorithm is still possible. Suppose your policy states you
> must migrate from 'old_algo' (e.g. sha1) to 'new_algo' (e.g. one of
> sha256/384/512). You can upgrade without relaxing the hash requirements:
> alter your policy rules from 'appraise_hash=old_algo' to
> 'appraise_hash=old_algo,new_algo', update the "ima_hash" parameter to
> 'new_algo', reboot, relabel all your files with 'new_algo', alter your
> policy_rule from 'appraise_hash=old_algo,new_algo' to
> 'appraise_hash=new_algo', reboot again and you're done.
> Agreed, it's quite a lot of churn - I don't know if this can be reduced -
> but this is technically doable.

Perhaps update the last line?

thanks,

Mimi


      parent reply	other threads:[~2021-07-27 17:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 16:33 THOBY Simon
2021-07-27 16:33 ` [PATCH v4 1/5] IMA: remove the dependency on CRYPTO_MD5 THOBY Simon
2021-07-27 17:57   ` Mimi Zohar
2021-07-27 16:33 ` [PATCH v4 2/5] IMA: block writes of the security.ima xattr with unsupported algorithms THOBY Simon
2021-07-27 20:32   ` Mimi Zohar
2021-07-28  7:00     ` THOBY Simon
2021-07-28 12:43       ` Mimi Zohar
2021-07-28 12:53         ` THOBY Simon
2021-07-28 13:09           ` Mimi Zohar
2021-07-27 16:33 ` [PATCH v4 3/5] IMA: add support to restrict the hash algorithms used for file appraisal THOBY Simon
2021-07-27 20:38   ` Mimi Zohar
2021-07-27 16:33 ` [PATCH v4 4/5] IMA: add a policy option to restrict xattr hash algorithms on appraisal THOBY Simon
2021-07-27 21:07   ` Mimi Zohar
2021-07-27 16:33 ` [PATCH v4 5/5] IMA: introduce a new policy option func=SETXATTR_CHECK THOBY Simon
2021-07-27 17:25   ` Mimi Zohar
2021-07-27 17:58     ` THOBY Simon
2021-07-27 17:47 ` Mimi Zohar [this message]

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=3ee0fdf38ca04bee6b58cd043ab5fa9a99dba9c1.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=Didier.BARVAUX@viveris.fr \
    --cc=Simon.THOBY@viveris.fr \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --subject='Re: [PATCH v4 0/5] IMA: restrict the accepted digest algorithms for' \
    /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

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).