[systemd-devel] Creating executable device nodes in /dev?

[Topi Miettinen]

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