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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 16.12.2020 12.03, Ulrich Windl wrote:
Jarkko Sakkinen <jarkko@xxxxxxxxxx> schrieb am 15.12.2020 um 05:19 in
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
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

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
used. And SELinux can protect /dev just fine without noexec.

Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
is not universal and the policies might not contain all users or


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
choose from, some are more interesting than others. The case where
/dev would be interesting would imply that easier or more common
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
with no need for any file system access is getting more common. It
mean that it would not be prudent to block the relatively easy
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).


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.


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

PR#17940 ( was merged, so /dev will now on be mounted with "exec" by systemd.

I made issue #17942 ( to discuss related hardening options. I'm leaning towards NoExecPaths=/ExecPaths= as it would enable nice hardening by allow-listing of all executable content for system services with simple directives like:

ExecPaths=/usr/sbin/daemon /lib64/ /usr/lib

Then a service infected with malware would not be able to execute a shell present in the system or downloaded later, if that was not explicitly allowed. /dev would also not have "exec" flag by default, but SGX could be allowed with "ExecPaths=/dev/sgx" when needed.


[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     []     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux