>>> Jarkko Sakkinen <jarkko@xxxxxxxxxx> schrieb am 15.12.2020 um 05:19 in Nachricht <20201215041903.GA21875@xxxxxxxxxx>: > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: >> >>> Topi Miettinen <toiwoton@xxxxxxxxx> schrieb am 11.12.2020 um 12:46 in >> Nachricht >> <27796c04-249e-6cf0-c3e1-0fd657a82f9c@xxxxxxxxx>: >> > On 11.12.2020 12.46, Jarkko Sakkinen wrote: >> >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote: >> >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote: >> >>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: >> >>>>>>>> As a further argument, I just did this on a Fedora system: >> >>>>>>>> $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l >> >>>>>>>> No results. So making /dev noexec doesn't seem to have any benefit. >> >>>>>>> >> >>>>>>> It's no surprise that there aren't any executables in /dev since >> >>>>>>> removing MAKEDEV ages ago. That's not the issue, which is that >> >>>>>>> /dev is a writable directory (for UID=0 but no capabilities are >> >>>>>>> needed) and thus a potential location for constructing unapproved >> >>>>>>> executables if it is also mounted exec (W^X). >> >>>>>> >> >>>>>> UID 0 can just change mount options, though, unless SELinux or similar >> is >> > used. And SELinux can protect /dev just fine without noexec. >> >>>>> >> >>>>> Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also >> SELinux >> >>>>> is not universal and the policies might not contain all users or >> services. >> >>>>> >> >>>>> ‑Topi >> >>>> >> >>>> What's the data that supports having noexec /dev anyway? With root >> >>>> access I can then just use something else like /dev/shm mount. >> >>>> >> >>>> Has there been out in the wild real world cases that noexec mount >> >>>> of would have prevented? >> >>>> >> >>>> For me this sounds a lot just something that "feels more secure" >> >>>> without any measurable benefit. Can you prove me wrong? >> >>> >> >>> I don't think security works that way. An attacker has various methods to >> >>> choose from, some are more interesting than others. The case where >> rw,exec >> >>> /dev would be interesting would imply that easier or more common avenues >> >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or >> >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP >> approach >> >>> with no need for any file system access is getting more common. It does >> not >> >>> mean that it would not be prudent to block the relatively easy approaches >> >>> too, including /dev. >> >> >> >> What if we add a new mount option "chrexec", which allows exec >> >> for character devices (S_IFCHR). >> > >> > I think devices are a bad match for SGX because devices haven't been >> > executable and SGX is actually an operation for memory. So something >> > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX) >> > would be much more natural. Even better would be something that >> > conceptully also works for AMD version (either with the same flags or >> > MFD_SGX / MFD_whatever_the_AMD_version_is). >> >> +1 > > SGX reserved memory from kernel's point of view is IO memory. > > Mapping SGX to memfd would not be a great idea, as it does not map > into concept of anonymous file backed by regular memory. > > A device file is very natural match actually. We have ioctl API for > uploading enclave pages during the build procedure to the enclave and > custom #PF handler. Conceptually it's a lot like video memory or such > special device specific memory area. > > There's no AMD equivalent of this technology. Hi! Back to "noexec": AFAIR the execute bit does not make sense for device files, and the purpose probably was to avoid execution of non-device files (e.g. regular executables) from inside /dev (where they should not be). So in this view "noexec" makes sense. There were similar arguments for not allowing device files in user directories. Regards, Ulrich > > /Jarkko
