From: THOBY Simon <Simon.THOBY@viveris.fr>
To: Mimi Zohar <zohar@linux.ibm.com>,
"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 v6 3/5] IMA: add support to restrict the hash algorithms used for file appraisal
Date: Tue, 10 Aug 2021 06:45:00 +0000 [thread overview]
Message-ID: <b746a7c4-2fa1-4182-89ed-e5fec4b009ea@viveris.fr> (raw)
In-Reply-To: <c1dadaa101b041fc7dcde1a5b3b52593a949e992.camel@linux.ibm.com>
Hi Mimi,
On 8/9/21 7:43 PM, Mimi Zohar wrote:
> On Wed, 2021-08-04 at 09:20 +0000, THOBY Simon wrote:
>> The kernel accepts any hash algorithm as a value for the security.ima
>> xattr. Users may wish to restrict the accepted algorithms to only
>> support strong cryptographic ones.
>>
>> Provide the plumbing to restrict the permitted set of hash algorithms
>> used for verifying file hashes and digest algorithms stored in
>> security.ima xattr.
>
> simplify by saying "file hashes and signatures stored ..."
Will fix in the next iteration.
>
>>
>> This do not apply only to IMA in hash mode, it also works with digital
>> signatures, where the hash from which the signature is derived (by
>> signing it with the trusted private key) must obey the same
>> restrictions.
>
> The patch is limited to appraisal. Is the above paragraph needed?
Yes, what I was (badly) trying to say is that the appraisal check work both when
the security.ima xattr contains digital signatures and when it contains hashes, as
digital signatures can also be generated with different algorithms.
Except, as you pointed out, by talking about "hash mode" here, I introduced a confusion
where the reader can believe I'm talking of the "hash" IMA policy action. I will try
to clarify that.
>
>>
>> Signed-off-by: Simon Thoby <simon.thoby@viveris.fr>
>> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
>
> This patch restricts the "hash algorithms". Looking this over again
> after some time, does truncating variable names here, and in the other
> patches, to just "_hash|_hashes" make sense? Perhaps the emphasis
> should not be on "hash", but on "algo".
I will update that (and patch 4/5 consequently).
>
>> @@ -684,8 +695,11 @@ int ima_match_policy(struct user_namespace *mnt_userns, struct inode *inode,
>> action &= ~IMA_HASH;
>> if (ima_fail_unverifiable_sigs)
>> action |= IMA_FAIL_UNVERIFIABLE_SIGS;
>> - }
>>
>> + if (allowed_hashes &&
>> + entry->flags & IMA_VALIDATE_HASH)
>> + *allowed_hashes = entry->allowed_hashes;
>> + }
>>
>> if (entry->action & IMA_DO_MASK)
>> actmask &= ~(entry->action | entry->action << 1);
>
>
> "allowed_hashes" sounds like a set of digests. Instead of
> "allowed_hashes" and "IMA_VALIDATE_HASH", should it be "allowed_algo"
> and "IMA_ALLOWED_ALGO"?
>
> thanks,
>
> Mimi
>
Thanks,
Simon
next prev parent reply other threads:[~2021-08-10 6:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 9:20 [PATCH v6 0/5] IMA: restrict the accepted digest algorithms for the security.ima xattr THOBY Simon
2021-08-04 9:20 ` [PATCH v6 2/5] IMA: block writes of the security.ima xattr with unsupported algorithms THOBY Simon
2021-08-04 17:40 ` Lakshmi Ramasubramanian
2021-08-09 13:32 ` Mimi Zohar
2021-08-09 23:34 ` Mimi Zohar
2021-08-10 6:44 ` THOBY Simon
2021-08-04 9:20 ` [PATCH v6 1/5] IMA: remove the dependency on CRYPTO_MD5 THOBY Simon
2021-08-04 17:41 ` Lakshmi Ramasubramanian
2021-08-09 20:59 ` Mimi Zohar
2021-08-04 9:20 ` [PATCH v6 3/5] IMA: add support to restrict the hash algorithms used for file appraisal THOBY Simon
2021-08-04 17:44 ` Lakshmi Ramasubramanian
2021-08-09 17:43 ` Mimi Zohar
2021-08-10 6:45 ` THOBY Simon [this message]
2021-08-04 9:20 ` [PATCH v6 4/5] IMA: add a policy option to restrict xattr hash algorithms on appraisal THOBY Simon
2021-08-04 20:53 ` Lakshmi Ramasubramanian
2021-08-05 7:42 ` THOBY Simon
2021-08-09 18:05 ` Mimi Zohar
2021-08-04 9:20 ` [PATCH v6 5/5] IMA: introduce a new policy option func=SETXATTR_CHECK THOBY Simon
2021-08-04 18:49 ` Lakshmi Ramasubramanian
2021-08-09 18:12 ` 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=b746a7c4-2fa1-4182-89ed-e5fec4b009ea@viveris.fr \
--to=simon.thoby@viveris.fr \
--cc=Didier.BARVAUX@viveris.fr \
--cc=dmitry.kasatkin@gmail.com \
--cc=linux-integrity@vger.kernel.org \
--cc=zohar@linux.ibm.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