From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
linux-integrity@vger.kernel.org,
Matthew Garrett <mjg59@google.com>
Cc: jamorris@linux.microsoft.com, sashal@kernel.org,
kgoldman@us.ibm.com, "Wiseman, Monty (GE Global Research,
US)" <monty.wiseman@ge.com>,
Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH 0/1] KEYS: Measure keys in trusted keyring
Date: Mon, 09 Sep 2019 09:31:21 -0400 [thread overview]
Message-ID: <1568035881.4614.347.camel@linux.ibm.com> (raw)
In-Reply-To: <2cd27f52-1029-bcea-c73b-7d3d002cf030@linux.microsoft.com>
On Tue, 2019-09-03 at 08:54 -0700, Lakshmi Ramasubramanian wrote:
> On 8/30/19 11:41 AM, Mimi Zohar wrote:
>
> > No, the measurement list ima-sig template record contains both the
> > file hash and signature. There's no need to maintain a white list of
> > either the file hashes or signed hashes. All that is needed is the
> > set of permitted public keys (eg. keys on the trusted IMA keyring).
>
> You are right - Thanks for the info.
>
> > Even though on the local system, files signed by the system owner
> > would be permitted, the attestation server would be able to control
> > access to whatever service. For example, Trusted Network Connect
> > (TNC) could control network access. By measuring the keys on the
> > builtin/secondary keyrings, that control is not based on who signed
> > the software package, but based on who signed the certificate of the
> > key that signed the software package. My concern is how this level of
> > indirection could be abused.
> Since the signer of certificate of the key that signed the software
> package changes much less frequently compared to the certificate of the
> key used to sign the software package, the operational overhead on the
> server side is significantly reduced.
>
> I understand there is another level of indirection here. But I am also
> not clear how this can be abused.
The remote attestation server could gate any service based on the
certificate signer. The first gated service, based on this feature,
will probably be network access (eg. TNC). If/when this feature is
upstreamed, every company, including financial institutes,
organizations, and governments will become THE certificate signer for
their organization, in order to limit access to their network and
systems. Once that happens, how long will it be until the same
feature will be abused and used to limit the individual's ability to
pick and choose which applications may run on their systems.[1]
Mimi
[1] Refer to Richard Stallman's last paragraph https://www.gnu.org/phi
losophy/can-you-trust.en.html
> > All of this would still be true, if you measured the keys on the
> > trusted IMA keyring, but without the level of indirection described
> > above. Depending on your use case scenario, the problem with this
> > approach is maintaining a list of all the certificates that have been
> > signed by keys on the builtin, and if enabled, the secondary keyrings.
>
> Yes - that is the issue we are trying to avoid. Especially since the
> list of signing certificates can grow faster than the signer of those
> certificates (that are present in the builtin/secondary keyrings)
>
> > In the last LSS-NA BoF, Monty suggested, for a different use case, one
> > that needs to seal keys, measuring keys and extending a separate PCR.
> Thanks for the info. I will gather more information on this one.
>
> -lakshmi
>
next prev parent reply other threads:[~2019-09-09 13:31 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
2019-08-30 18:41 ` Mimi Zohar
2019-09-03 15:54 ` Lakshmi Ramasubramanian
2019-09-09 13:31 ` Mimi Zohar [this message]
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=1568035881.4614.347.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=jamorris@linux.microsoft.com \
--cc=kgoldman@us.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@google.com \
--cc=monty.wiseman@ge.com \
--cc=nramas@linux.microsoft.com \
--cc=roberto.sassu@huawei.com \
--cc=sashal@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).