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).
-Topi
