linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	linux-integrity@vger.kernel.org,
	Matthew Garrett <mjg59@google.com>
Cc: jamorris@linux.microsoft.com, sashal@kernel.org, kgoldman@us.ibm.com
Subject: Re: [PATCH 0/1] KEYS: Measure keys in trusted keyring
Date: Thu, 29 Aug 2019 19:43:45 -0700	[thread overview]
Message-ID: <ec8d7cd5-a83a-c344-eaa6-9bd2cef08772@linux.microsoft.com> (raw)
In-Reply-To: <1567041083.6115.133.camel@linux.ibm.com>


>> Without this patch set, to attest the clients one needs to maintain
>> an "allowed list" of file hashes of all versions of all client binaries
>> that are deployed on the clients in the enterprise.  That is a huge
>> operational challenge in a large scale environment of clients with
>> heterogenous builds. This also limits scalability and agility of
>> rolling out frequent client binary updates.
> 
> The purpose of the ima-sig template, which includes the file signature
> and header containing the keyid, is to avoid needing to maintain a
> white list as you described.

If the service were to validate the signature in the ima-sig template, 
it needs to have the hash of the file. Using the keyid in ima-sig pick 
the key, calculate the signed hash and compare it with the signed hash 
in the ima-sig template. Correct?

Or, it has to maintain the signed hash of the file and compare it with 
the signed hash in the ima-sig template.

In both the cases, the service needs to have the hash or signed hash for 
all the client files (for all versions of that file). This the 
maintenance overhead we are trying to avoid.

> The concern isn't on the client side, but the server side.  Once the
> ability of including measurements of keys on the builtin and/or
> secondary keyrings on the client side exists, the attestation servers
> can start requiring it.  Providing a means of disabling it on the
> client side doesn't address this problem.

But, wouldn't this problem exist for any new measure we add on the 
client side? Why is it particularly an issue for measuring trusted keys?

> 
> No, there is no need for maintaining a binary hash white list.  The
> attestation server requires a set of trusted keys used to sign
> software.
> 
> The only reason for measuring the keys on the builtin and/or secondary
> keyrings is to prevent system owners from signing and running
> applications on their own systems.
> 
> Since you obviously disagree, I'd really like to hear other people's thoughts.

Actually I am agreeing with you - the reason we want to measure the keys 
in the trusted keyring is to ensure that the system binaries running on 
the client are signed by trusted keys only. Please see below:

We let IMA verify the integrity of the system files on the client using 
IMA key(s). The IMA key(s) are themselves signed by "Trusted Key(s)" - 
unsigned IMA key or IMA key signed by keys not in the trusted keyring 
are not even allowed to be added to the IMA keyring.

And, on the server we validate the "Trusted Keyring" contains only 
known\trusted keys.

Through the above process - the server does not need to know the signed 
file hash. It only needs to keep a list of trusted keys and verify if 
the keys reported by the client is in that trusted keys set.

Please let me know if that answers your questions.

Thanks,
  -lakshmi

  reply	other threads:[~2019-08-30  2:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28  0:27 [PATCH 0/1] KEYS: Measure keys in trusted keyring Lakshmi Ramasubramanian
2019-08-28  0:27 ` [PATCH 1/1] " Lakshmi Ramasubramanian
2019-09-02 22:04   ` Mimi Zohar
2019-08-29  1:11 ` [PATCH 0/1] " Mimi Zohar
2019-08-30  2:43   ` Lakshmi Ramasubramanian [this message]
2019-08-30 18:41     ` Mimi Zohar
2019-09-03 15:54       ` Lakshmi Ramasubramanian
2019-09-09 13:31         ` Mimi Zohar
2019-09-09 21:34           ` James Morris
2019-09-19 13:18           ` Sasha Levin
2019-09-19 17:12             ` Mimi Zohar
2019-10-04 19:29               ` Lakshmi Ramasubramanian
2019-10-04 19:57                 ` Mimi Zohar
2019-10-04 20:10                   ` Lakshmi Ramasubramanian
2019-10-04 21:58                     ` Mimi Zohar
2019-10-05  0:10                       ` Lakshmi Ramasubramanian
2019-10-06 13:17                         ` Mimi Zohar
2019-10-07 15:03                           ` Lakshmi Ramasubramanian

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=ec8d7cd5-a83a-c344-eaa6-9bd2cef08772@linux.microsoft.com \
    --to=nramas@linux.microsoft.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=kgoldman@us.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=sashal@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;
as well as URLs for NNTP newsgroup(s).