On Wed, Nov 18, 2020 at 10:54:46PM +0100, Borislav Petkov wrote: > On Wed, Nov 18, 2020 at 11:37:55PM +0200, Jarkko Sakkinen wrote: > > Just checking that I got this right: you want me to port my anon inode > > changes from March to be applied on top of tip and send them? > > Well, we need to somehow address the issue when some distros map /dev > noexec and that is conflicting with SGX due to it needing to mmap with > executable permissions but /dev/sgx_enclave is noexec... > > I guess the first thing that needs figuring out is why are some distros > mounting /dev noexec. > > I mean, you can always do the easiest thing: somewhere in the SGX > docs say that one of the steps towards running SGX enclaves on such > distros is for the admin to map /dev exec. However, does that have other > security implications which would make such exec mounting a security > hazard? > > If so, then the SGX code would need changing... > > Questions like those. > > HTH. OK I did re-read the whole thing: https://lore.kernel.org/linux-sgx/20200331114432.7593-1-jarkko.sakkinen@xxxxxxxxxxxxxxx/ As Topi (the Debian developer who did this change) stated in the thread, the threat scenario is that someone could create executable files to /dev if it isn't noexec. It's not about the permissions of device files per se. The problem with anonymous inode is that LSM's cannot label it easily like you can a non-anonymous inode. There's a patch set for secure anonymous inodes but it hasn't landed yet and I think it would make the whole security model somewhat more complicated [1]. What I mean is that secure anonymous inodes would make sense in a context where anonymous inodes are used for other reasons to begin with. The route of using sgxfs was discarded because it results static permissions and is also quite big hammer for the purpose [2]. In that thread there were two valid routes to move forward: 1. You can always create a separate tmpfs and create enclave nodes and even bind mount them (proposed by Andy) to /dev. 2. It would be possible (given how Topi described the threat scenario) implement "noexec_dev" mount option that would allow 'x' for dev's but not for anything else (proposed by me). To summarize, I would not change the SGX code for this but apply either (1) and (2) when deploying SGX. > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette [1] https://lore.kernel.org/linux-security-module/20201011082936.4131726-1-lokeshgidra@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-sgx/CALCETrWkaUS2RU61_4KoNhn3RkW-J+SWiCQTZ623wu4b7snJ0w@xxxxxxxxxxxxxx/ /Jarkko
