On Thu, Jun 13, 2019 at 05:46:00PM -0700, Sean Christopherson wrote:
Good afternoon, I hope the week is ending well for everyone.
> On Thu, Jun 13, 2019 at 01:02:17PM -0400, Stephen Smalley wrote:
> > Given the complexity tradeoff, what is the clear motivating
> > example for why #1 isn't the obvious choice? That the enclave
> > loader has no way of knowing a priori whether the enclave will
> > require W->X or WX? But aren't we better off requiring enclaves
> > to be explicitly marked as needing such so that we can make a more
> > informed decision about whether to load them in the first place?
> Andy and/or Cedric, can you please weigh in with a concrete (and
> practical) use case that will break if we go with #1? The auditing
> issues for #2/#3 are complex to say the least...
So we are back to choosing door 1, door 2 or door 3.
That brings us back to our previous e-mail, where we suggested that
the most fundamental question to answer with the LSM issue is how much
effective security is being purchased at what complexity cost.
We are practical guys at our company, we direct the development and
deployment of practical SGX systems, including an independent
implementation of SGX runtime/attestation/provisioning et.al. Our
comments, for whatever they are worth, are meant to reflect the real
world deployment of this technology.
Lets start big picture.
One of the clients we are consulting with on this technology is
running well north of 1400 Linux systems. Every one of which has
selinux=0 in /proc/cmdline and will do so until approximately the heat
death of the Universe.
Our AI LSM will use any SGX LSM driver hooks that eventuate from these
discussions, so we support the notion of the LSM getting a look at
permissions of executable code. However, our client isn't unique in
their configuration choice, so we believe this fact calls the question
as to how much SGX specific complexity should be injected into the
LSM.
So, as we noted in our previous e-mail, there are only two relevant
security questions the LSM needs to answer:
1.) Should a page of memory with executable content be allowed into an
enclave?
2.) Should an enclave be allowed to possess one or more pages of
executable memory which will have WX permissions sometime during its
lifetime?
Sean is suggesting the strategy of an ioctl to call out pages that
conform to question 2 (EAUG'ed pages). That doesn't seem like an
onerous requirement, since all of the current enclave loaders already
have all of the metadata infrastructure to map/load page ranges. The
EAUG WX range would simply be another layout type that gets walked
over when the enclave image is built.
Given that, we were somewhat surprised to hear Sean say that he had
been advised that door 1 was a non-starter. Presumably this was
because of the need to delineate a specific cohort of pages that will
be permitted WX. If that is the case, the question that needs to be
called, as Stephen alludes to above, is whether or not WX privileges
should be considered a characterizing feature of the VMA that defines
an enclave rather then a per page attribute.
Do we realistically believe that an LSM will be implemented that
reacts differently when the 357th page of WX memory is added as
opposed to the first? The operative security question is whether or
not the platform owner is willing to allow arbitrary executable code,
that they may have no visibility into, to be executed on their
platform.
We talk to people that, as a technology, SGX is about building
'security archipelagos', islands of trusted execution on potentially
multiple platforms that interact to deliver a service, all of which
consider their surrounding platforms and the network in between them
as adversarial. This model is, by definition, adverserial to the
notion and function of the LSM.
With respect to SGX dynamic code loading, the future for security
concious architectures, will be to pull the code from remotely
attested repository servers over the network. The only relevant
security question that can be answered is whether or not a platform
owner feels comfortable with that model.
Best wishes for a pleasant weekend to everyone.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"My spin on the meeting? I lie somewhere between the individual who
feels that we are all going to join hands and march forward carrying
the organization into the information age and Dr. Wettstein. Who
feels that they are holding secret meetings at 6 o'clock in the
morning plotting strategy on how to replace our system."
-- Paul S. Etzell, M.D.
Medical Director, Roger Maris Cancer Center
