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