Re: [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation

[Andy Lutomirski]

On Tue, Jun 30, 2020 at 7:20 AM Sean Christopherson
<sean.j.christopherson@xxxxxxxxx> wrote:
>
> On Tue, Jun 30, 2020 at 10:49:56AM +0200, Borislav Petkov wrote:
> > On Mon, Jun 29, 2020 at 03:04:00PM -0700, Sean Christopherson wrote:
> > > /dev/sgx/provision is root-only by default, the expectation is that the admin
> > > will configure the system to grant only specific enclaves access to the
> > > PROVISION_KEY.
> >
> > Uuh, I don't like "the expectation is" - the reality happens to turn
> > differently, more often than not.
>
> Would it help if I worded it as "only root should ever be able to run an
> enclave with access to PROVISION_KEY"?  We obviously can't control what
> admins actually do, hence my wording of it as the expected behavior.
>
> > > In this series, access is fairly binary, i.e. there's no additional kernel
> > > infrastructure to help userspace make per-enclave decisions.  There have been
> > > more than a few proposals on how to extend the kernel to help provide better
> > > granularity, e.g. LSM hooks, but it was generally agreed to punt that stuff
> > > to post-upstreaming to keep things "simple" once we went far enough down
> > > various paths to ensure we weren't painting ourselves into a corner.
> >
> > So this all sounds to me like we should not upstream /dev/sgx/provision
> > now but delay it until the infrastructure for that has been made more
> > concrete. We can always add it then. Changing it after the fact -
> > if we have to and for whatever reason - would be a lot harder for a
> > user-visible interface which someone has started using already.
>
> The userspace and attestation infrastructure is very concrete, i.e. the
> need for userspace to be able to access PROVISION_KEY is there, as is the
> desire to be able to restrict access to PROVISION_KEY, e.g. I believe Andy
> Lutomirski originally requested the ability to restrict access.
>
> The additional infrastructure for per-enclave decisions is somewhat
> orthogonal to the PROVISION_KEY, e.g. they won't necessarily be employed
> by everyone running enclaves, and environments that do have per-enclave
> policies would still likely want the extra layer of restriction for
> PROVISION_KEY.  I only brought the additional policy crud to call out that
> we've done enough path-finding on additional restrictions to have strong
> confidence that adding /dev/sgx/provision won't prevent us from adding more
> fine grained control in the future.

I agree.

I anticipate that most of the nasty fine-grained stuff will end up in
userspace down the road.  Systems can be configured such that
provisioning is done as root, or systems can end up with fancy SELinux
rules or daemons that pass around fds or whatever, but all of this can
be done with the kernel code in this patchset.