On 2020-04-07 01:18, Andy Lutomirski wrote:
> On Mon, Apr 6, 2020 at 2:24 PM Jarkko Sakkinen
> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
>>
>> On Mon, Apr 06, 2020 at 12:53:41PM -0700, Andy Lutomirski wrote:
>>>> sgxfs is somewhat trivial to implement and has one stakeholder less to
>>>> worry about. It is not really a huge stretch.
>>>>
>>>> Overally, I think it is something that we could live with. At least it
>>>> is something that does not step on others toes.
>>>>
>>>> Haitao: If we go with sgxfs route, then you can for the moment do what
>>>> Andy suggested: bind mount it to /dev/sgx.
>>>
>>> That also needs userspace support.
>>>
>>> I’ll start a thread on the udev list.
>>
>> Haven't written any code yet but just by drafting the idea I already
>> pinpointed something.
>>
>> You would add roughly this to the existing codebase:
>>
>> * struct file_system_type sgxfs
>> * struct fs_context_operations sgxfs_ctx_ops
>> * int sgxfs_get_tree()
>> * int sgxfs_fill_super()
>> * const struct tree_descr sgxfs_files[]
>>
>> The files would be defined as like this:
>>
>> static const struct tree_descr sgxfs_files[] {
>> [SGXFS_ENCLAVE] = { "enclave", &sgxfs_encl_ops, /* ? */ },
>> [SGXFS_PROVISION] = { "provision", &sgxfs_encl_ops, /* ? */ },
>> };
>>
>> The permissions would need to be completely static, which feels nasty
>> from maintainability viewpoint :-( And I see no gain anywhere.
>>
>> In my opinion udev defining the whole /dev as noexec has zero technical
>> merits. It is same as they would say that "we don't trust our own
>> database". There are no real security benefits as long as dev nodes are
>> configured correctly.
>
> I tend to agree, but it could be seen as a sort-of-valid hardening measure.
Yeah it seems to me `noexec` is overly broad in not allowing mmap(PROT_EXEC). I'd expect it to disallow only execve(), which is fine for /dev.
--
Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
