[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

[Ulrich Windl]

>>> Jarkko Sakkinen <jarkko at kernel.org> schrieb am 15.12.2020 um 05:19 in
Nachricht
<20201215041903.GA21875 at kernel.org>:
> On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
>> >>> Topi Miettinen <toiwoton at gmail.com> schrieb am 11.12.2020 um 12:46 in
>> Nachricht
>> <27796c04-249e-6cf0-c3e1-0fd657a82f9c at gmail.com>:
>> > 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