On Fri, Mar 22, 2019 at 11:20:30AM -0700, Andy Lutomirski wrote:
> On Fri, Mar 22, 2019 at 4:43 AM Jarkko Sakkinen
> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Mar 22, 2019 at 01:29:38PM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Mar 21, 2019 at 09:50:41AM -0700, Andy Lutomirski wrote:
> > > > On Sun, Mar 17, 2019 at 2:18 PM Jarkko Sakkinen
> > > > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > In order to provide a mechanism for devilering provisoning rights:
> > > > >
> > > > > 1. Add a new file to the securityfs file called sgx/provision that works
> > > > > as a token for allowing an enclave to have the provisioning privileges.
> > > > > 2. Add a new ioctl called SGX_IOC_ENCLAVE_SET_ATTRIBUTE that accepts the
> > > > > following data structure:
> > > > >
> > > > > struct sgx_enclave_set_attribute {
> > > > > __u64 addr;
> > > > > __u64 token_fd;
> > > > > };
> > > >
> > > > Here's a potential issue:
> > > >
> > > > For container use, is it reasonable for a container manager to
> > > > bind-mount a file into securityfs? Or would something in /dev make
> > > > this easier?
> > >
> > > I guess that is a valid point given that the securityfs contains the LSM
> > > (e.g. SELinux or AppArmor) policy. So yeah, I think your are right what
> > > you say.
> > >
> > > I propose that we create /dev/sgx/enclave to act as the enclave manager
> > > and /dev/sgx/provision for provisioning. Is this sustainable for you?
> >
> > Hmm.. on 2nd thought the LSM policy or even DAC policy would restrict
> > that the container manager can only access specific files inside
> > securityfs. With this conclusion I still think it is probably the best
> > place for seurity policy like things even for SGX. It is meant for that
> > anyway.
> >
>
> LSM or DAC policy can certainly *restrict* it, but I suspect that most
> container runtimes don't mount securityfs at all. OTOH, the runtime
> definitely needs to have a way to pass /dev/sgx/enclave (or whatever
> it's called) through, so using another device node will definitely
> work.
OK, I can cope with this argument. I go with the device names above for
v20.
/Jarkko
