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 5/5] IMA: introduce a new policy option func=SETXATTR_CHECK
Date: Tue, 27 Jul 2021 13:25:16 -0400	[thread overview]
Message-ID: <f042f5df077cdaf50688c7cc3fa8896491abf2bd.camel@linux.ibm.com> (raw)
In-Reply-To: <20210727163330.790010-6-simon.thoby@viveris.fr>

Hi Simon,

On Tue, 2021-07-27 at 16:33 +0000, THOBY Simon wrote:
> While users can restrict the accepted hash algorithms for the
> security.ima xattr file signature when appraising said file, users
> cannot restrict the algorithms that can be set on that attribute:
> any algorithm built in the kernel is accepted on a write.
> 
> Define a new value for the ima policy option 'func' that restricts
> globally the hash algorithms accepted when writing the security.ima
> xattr.
> 
> When a policy contains a rule of the form
> 	appraise func=SETXATTR_CHECK appraise_hash=sha256,sha384,sha512
> only values corresponding to one of these three digest algorithms
> will be accepted for writing the security.ima xattr.
> Attempting to write the attribute using another algorithm (or "free-form"
> data) will be denied with an audit log message.
> In the absence of such a policy rule, the default is still to only
> accept hash algorithms built in the kernel (with all the limitations
> that entails).
> 
> On policy update, the latest SETXATTR_CHECK rule is the only one
> that apply, and other SETXATTR_CHECK rules are deleted.
> 
> Signed-off-by: Simon Thoby <simon.thoby@viveris.fr>

Sorry, I was just getting to this patch, when you re-posted the patch
set.  In the future, I'll make sure the responses are sent in quick
succession.

There are a number of assumptions related to the IMA policy:
- A builtin policy may be replaced by a custom policy.
- Depending on the Kconfig, the policy rules may not change be updated.
- Subsequent to replacing the builtin policy with a custom policy,
rules may only be appended, based on the Kconfig.

The locking around the policy rules is dependent on these assumptions. 
Removing policy rules is a major change that needs to be considered
carefully.  Why should "func=SETXATTR_CHECK"  be treated any
differently than any other policy rule?  How would an attestation
server know which setxattr rule was enabled at the time the file was
appraised?

thanks,

Mimi


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

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 16:33 [PATCH v4 0/5] IMA: restrict the accepted digest algorithms for 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 [this message]
2021-07-27 17:58     ` THOBY Simon
2021-07-27 17:47 ` [PATCH v4 0/5] IMA: restrict the accepted digest algorithms for Mimi Zohar

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=f042f5df077cdaf50688c7cc3fa8896491abf2bd.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 \
    /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).